[OE-core] [PATCH 0/2] useradd.bbclass: new class for managing user/group permissions [v3]
Hi, This pull request should be complete based on Richard's second round of feedback. Thanks, Scott The following changes since commit 1c1372e7eccb01f7c1f682bc0aa989c37f2516f6: bitbake.conf: update PSEUDO_PASSWD variable (2011-07-01 00:13:25 +0100) are available in the git repository at: git://git.pokylinux.org/poky-contrib sgarman/useradd-v3 http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=sgarman/useradd-v3 Scott Garman (2): useradd.bbclass: new class for managing user/group permissions useradd-example: example recipe for using inherit useradd .../recipes-skeleton/useradd/useradd-example.bb| 76 ++ meta/classes/useradd.bbclass | 156 2 files changed, 232 insertions(+), 0 deletions(-) create mode 100644 meta-skeleton/recipes-skeleton/useradd/useradd-example.bb create mode 100644 meta-skeleton/recipes-skeleton/useradd/useradd-example/file1 create mode 100644 meta-skeleton/recipes-skeleton/useradd/useradd-example/file2 create mode 100644 meta-skeleton/recipes-skeleton/useradd/useradd-example/file3 create mode 100644 meta-skeleton/recipes-skeleton/useradd/useradd-example/file4 create mode 100644 meta/classes/useradd.bbclass ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/2] qemu.inc: append to IMAGE_FSTYPES instead of weakly assigning them
Op 1 jul 2011, om 01:09 heeft Saul Wold het volgende geschreven: On 06/30/2011 03:33 PM, Koen Kooi wrote: ping I believe that this has been discussed elsewhere. Let's post the outcome here then, since I still want this patch to go in. Sau! Op 12 jun 2011, om 18:26 heeft Koen Kooi het volgende geschreven: The ext3 format is pretty much mandatory for qemu usage, so always create it. Signed-off-by: Koen Kooik...@dominion.thruhere.net --- meta/conf/machine/include/qemu.inc |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/meta/conf/machine/include/qemu.inc b/meta/conf/machine/include/qemu.inc index 9ef242f..e908f69 100644 --- a/meta/conf/machine/include/qemu.inc +++ b/meta/conf/machine/include/qemu.inc @@ -3,7 +3,7 @@ PREFERRED_PROVIDER_virtual/xserver ?= xserver-kdrive MACHINE_FEATURES = kernel26 apm alsa pcmcia bluetooth irda usbgadget screen -IMAGE_FSTYPES ?= tar.bz2 ext3 +IMAGE_FSTYPES += tar.bz2 ext3 ROOT_FLASH_SIZE = 280 -- 1.6.6.1 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] Updated [PATCH 0/4] SRC_URI Check Updates with Beagleboard updates
Richard,
This address 2 bugs filed by Darren for the Beagleboard, they build
correctly.
It also updates two recipes that Mark Hatle found lacking checksums.
Thanks
Sau!
The following changes since commit 40ecaf6a59ba61e72d29d7e677197ef37c998408:
uclibc: Add default uClibc.machine files (2011-07-01 00:40:10 +0100)
are available in the git repository at:
git://git.openembedded.org/openembedded-core-contrib sgw/fix
http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=sgw/fix
Saul Wold (4):
x-load: Update to 1.5.0
uboot: Update to 2011.06
mpeg2dec: add SRC_URI Checksum
libmad: add SRC_URI Checksum
...Drop-config.h-include-in-tools-imximage.h.patch |0
...ove-LDSCRIPT-processing-to-the-top-level-.patch |0
...kimage_2011.03.bb = u-boot-mkimage_2011.06.bb} | 12 +---
.../uboot/{u-boot_2011.03.bb = u-boot_2011.06.bb} | 10 +-
meta/recipes-bsp/x-load/x-load_git.bb | 11 +--
meta/recipes-multimedia/libmad/libmad_0.15.1b.bb |3 +++
meta/recipes-multimedia/mpeg2dec/mpeg2dec_0.4.1.bb |3 +++
7 files changed, 21 insertions(+), 18 deletions(-)
rename meta/recipes-bsp/uboot/{u-boot-mkimage-2011.03 =
u-boot-mkimage-2011.06}/0001-Drop-config.h-include-in-tools-imximage.h.patch
(100%)
rename meta/recipes-bsp/uboot/{u-boot-mkimage-2011.03 =
u-boot-mkimage-2011.06}/0002-config.mk-move-LDSCRIPT-processing-to-the-top-level-.patch
(100%)
rename meta/recipes-bsp/uboot/{u-boot-mkimage_2011.03.bb =
u-boot-mkimage_2011.06.bb} (51%)
rename meta/recipes-bsp/uboot/{u-boot_2011.03.bb = u-boot_2011.06.bb} (74%)
--
1.7.3.4
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 3/4] mpeg2dec: add SRC_URI Checksum
Signed-off-by: Saul Wold s...@linux.intel.com
---
meta/recipes-multimedia/mpeg2dec/mpeg2dec_0.4.1.bb |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/meta/recipes-multimedia/mpeg2dec/mpeg2dec_0.4.1.bb
b/meta/recipes-multimedia/mpeg2dec/mpeg2dec_0.4.1.bb
index 4aa6f8c..f21d2c3 100644
--- a/meta/recipes-multimedia/mpeg2dec/mpeg2dec_0.4.1.bb
+++ b/meta/recipes-multimedia/mpeg2dec/mpeg2dec_0.4.1.bb
@@ -13,6 +13,9 @@ PR = r1
SRC_URI = http://libmpeg2.sourceforge.net/files/mpeg2dec-${PV}.tar.gz \
file://altivec_h_needed.patch
+SRC_URI[md5sum] = 7631b0a4bcfdd0d78c0bb0083080b0dc
+SRC_URI[sha256sum] =
c74a76068f8ec36d4bb59a03bf1157be44118ca02252180e8b358b0b5e3edeee
+
inherit autotools pkgconfig
EXTRA_OECONF = --enable-shared --disable-sdl --with-x
--
1.7.3.4
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 4/4] libmad: add SRC_URI Checksum
Signed-off-by: Saul Wold s...@linux.intel.com
---
meta/recipes-multimedia/libmad/libmad_0.15.1b.bb |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/meta/recipes-multimedia/libmad/libmad_0.15.1b.bb
b/meta/recipes-multimedia/libmad/libmad_0.15.1b.bb
index acc9df5..ed3efa5 100644
--- a/meta/recipes-multimedia/libmad/libmad_0.15.1b.bb
+++ b/meta/recipes-multimedia/libmad/libmad_0.15.1b.bb
@@ -15,6 +15,9 @@ SRC_URI = ${SOURCEFORGE_MIRROR}/mad/libmad-${PV}.tar.gz \
file://add-pkgconfig.patch \
file://fix_for_mips_with_gcc-4.5.0.patch
+SRC_URI[md5sum] = 1be543bc30c56fb6bea1d7bf6a64e66c
+SRC_URI[sha256sum] =
bbfac3ed6bfbc2823d3775ebb931087371e142bb0e9bb1bee51a76a6e0078690
+
S = ${WORKDIR}/libmad-${PV}
inherit autotools pkgconfig
--
1.7.3.4
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH v4 1/8] Remove support for building 2.4 kernels
Signed-off-by: Anders Darander and...@chargestorm.se
---
meta/classes/kernel.bbclass | 12 ++--
meta/classes/module-base.bbclass |2 +-
2 files changed, 3 insertions(+), 11 deletions(-)
diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index f282a57..25f4855 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -73,9 +73,6 @@ KERNEL_ALT_IMAGETYPE ??=
kernel_do_compile() {
unset CFLAGS CPPFLAGS CXXFLAGS LDFLAGS MACHINE
oe_runmake include/linux/version.h CC=${KERNEL_CC} LD=${KERNEL_LD}
- if [ ${KERNEL_MAJOR_VERSION} != 2.6 ]; then
- oe_runmake dep CC=${KERNEL_CC} LD=${KERNEL_LD}
- fi
oe_runmake ${KERNEL_IMAGETYPE} ${KERNEL_ALT_IMAGETYPE}
CC=${KERNEL_CC} LD=${KERNEL_LD}
}
@@ -111,9 +108,7 @@ kernel_do_install() {
install -m 0644 vmlinux ${D}/boot/vmlinux-${KERNEL_VERSION}
[ -e Module.symvers ] install -m 0644 Module.symvers
${D}/boot/Module.symvers-${KERNEL_VERSION}
install -d ${D}/etc/modutils
- if [ ${KERNEL_MAJOR_VERSION} = 2.6 ]; then
- install -d ${D}/etc/modprobe.d
- fi
+ install -d ${D}/etc/modprobe.d
#
# Support for external module building - create a minimal copy of the
@@ -397,10 +392,7 @@ python populate_packages_prepend () {
# Write out any modconf fragment
modconf = bb.data.getVar('module_conf_%s' % basename, d, 1)
if modconf:
- if bb.data.getVar(KERNEL_MAJOR_VERSION, d, 1) ==
2.6:
- name = '%s/etc/modprobe.d/%s.conf' % (dvar,
basename)
- else:
- name = '%s/etc/modutils/%s.conf' % (dvar,
basename)
+ name = '%s/etc/modprobe.d/%s.conf' % (dvar, basename)
f = open(name, 'w')
f.write(%s\n % modconf)
f.close()
diff --git a/meta/classes/module-base.bbclass b/meta/classes/module-base.bbclass
index c98bace..a7cf233 100644
--- a/meta/classes/module-base.bbclass
+++ b/meta/classes/module-base.bbclass
@@ -7,7 +7,7 @@ export CROSS_COMPILE = ${TARGET_PREFIX}
export KERNEL_VERSION =
${@base_read_file('${STAGING_KERNEL_DIR}/kernel-abiversion')}
export KERNEL_SOURCE =
${@base_read_file('${STAGING_KERNEL_DIR}/kernel-source')}
-KERNEL_OBJECT_SUFFIX = ${@[.o,
.ko][base_read_file('${STAGING_KERNEL_DIR}/kernel-abiversion') 2.6.0]}
+KERNEL_OBJECT_SUFFIX = .ko
KERNEL_CCSUFFIX = ${@base_read_file('${STAGING_KERNEL_DIR}/kernel-ccsuffix')}
KERNEL_LDSUFFIX = ${@base_read_file('${STAGING_KERNEL_DIR}/kernel-ldsuffix')}
KERNEL_ARSUFFIX = ${@base_read_file('${STAGING_KERNEL_DIR}/kernel-arsuffix')}
--
1.7.4.1
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH v4 6/8] modutils: remove modutils
As 2.4 support is being phased out, remove modutils.
Signed-off-by: Anders Darander and...@chargestorm.se
---
meta/recipes-kernel/modutils/files/armeb.patch | 16
meta/recipes-kernel/modutils/files/configure.patch | 34 ---
meta/recipes-kernel/modutils/files/gcc4.patch | 93
meta/recipes-kernel/modutils/files/lex.l.diff | 35
.../modutils/files/modutils-notest.patch | 16
.../modutils/files/program_prefix.patch| 71 ---
.../recipes-kernel/modutils/modutils-collateral.bb | 21 -
.../modutils/modutils-cross/module.h.diff | 35
.../modutils/modutils-cross_2.4.27.bb | 20
meta/recipes-kernel/modutils/modutils_2.4.27.bb| 93
10 files changed, 0 insertions(+), 434 deletions(-)
delete mode 100644 meta/recipes-kernel/modutils/files/armeb.patch
delete mode 100644 meta/recipes-kernel/modutils/files/configure.patch
delete mode 100644 meta/recipes-kernel/modutils/files/gcc4.patch
delete mode 100644 meta/recipes-kernel/modutils/files/lex.l.diff
delete mode 100644 meta/recipes-kernel/modutils/files/modules
delete mode 100644 meta/recipes-kernel/modutils/files/modules.conf
delete mode 100644 meta/recipes-kernel/modutils/files/modutils-notest.patch
delete mode 100644 meta/recipes-kernel/modutils/files/program_prefix.patch
delete mode 100644 meta/recipes-kernel/modutils/modutils-collateral.bb
delete mode 100644 meta/recipes-kernel/modutils/modutils-cross/module.h.diff
delete mode 100644 meta/recipes-kernel/modutils/modutils-cross_2.4.27.bb
delete mode 100644 meta/recipes-kernel/modutils/modutils_2.4.27.bb
diff --git a/meta/recipes-kernel/modutils/files/armeb.patch
b/meta/recipes-kernel/modutils/files/armeb.patch
deleted file mode 100644
index 3198553..000
--- a/meta/recipes-kernel/modutils/files/armeb.patch
+++ /dev/null
@@ -1,16 +0,0 @@
-Upstream-Status: Pending
-
modutils-2.4.27/include/elf_arm.h.orig 2004-09-21 18:37:00.0
-0400
-+++ modutils-2.4.27/include/elf_arm.h 2004-09-21 18:38:18.0 -0400
-@@ -1,7 +1,11 @@
- /* Machine-specific elf macros for ARM. */
-
- #define ELFCLASSM ELFCLASS32
-+#ifdef __ARMEB__
-+#define ELFDATAM ELFDATA2MSB
-+#else
- #define ELFDATAM ELFDATA2LSB
-+#endif
-
- #define MATCH_MACHINE(x) (x == EM_ARM)
-
diff --git a/meta/recipes-kernel/modutils/files/configure.patch
b/meta/recipes-kernel/modutils/files/configure.patch
deleted file mode 100644
index 63e80d7..000
--- a/meta/recipes-kernel/modutils/files/configure.patch
+++ /dev/null
@@ -1,34 +0,0 @@
-Upstream-Status: Pending
-
-#
-# Patch managed by http://www.mn-logistik.de/unsupported/pxa250/patcher
-#
-
modutils-2.4.25/./configure.in~configure
-+++ modutils-2.4.25/./configure.in
-@@ -1,4 +1,5 @@
--AC_INIT(insmod/insmod.c)
-+AC_INIT
-+AC_CONFIG_SRCDIR([insmod/insmod.c])
- AC_PREFIX_DEFAULT(/usr)
-
- # Canonical system uses CC_FOR_BUILD while Linux may use BUILDCC
-@@ -15,7 +16,7 @@
- BUILDCC=$CC_FOR_BUILD
- export CC_FOR_BUILD
-
--AC_CANONICAL_SYSTEM
-+AC_CANONICAL_TARGET([])
-
- # Handle target_cpu for compatibility.
- if test $host_cpu != $target_cpu; then
-@@ -350,6 +351,7 @@
- fi
- fi
-
--AC_OUTPUT(Makefile Makefile.common depmod/Makefile genksyms/Makefile
-+AC_CONFIG_FILES([Makefile Makefile.common depmod/Makefile genksyms/Makefile
- insmod/Makefile $kerneld_Makefiles obj/Makefile util/Makefile
--man/Makefile)
-+man/Makefile])
-+AC_OUTPUT
diff --git a/meta/recipes-kernel/modutils/files/gcc4.patch
b/meta/recipes-kernel/modutils/files/gcc4.patch
deleted file mode 100644
index 4507b03..000
--- a/meta/recipes-kernel/modutils/files/gcc4.patch
+++ /dev/null
@@ -1,93 +0,0 @@
-Upstream-Status: Pending
-
-Index: modutils-2.4.27/depmod/depmod.c
-===
modutils-2.4.27.orig/depmod/depmod.c
-+++ modutils-2.4.27/depmod/depmod.c
-@@ -1133,7 +1133,7 @@ static int addksyms(char *file_syms)
-
- for (ksym = ksyms; so_far nksyms; ++so_far, ksym++) {
- if (strncmp((char *)ksym-name, GPLONLY_, 8) == 0)
-- ((char *)ksym-name) += 8;
-+ ksym-name += 8;
- assert(n_syms MAX_MAP_SYM);
- symtab[n_syms++] = addsym((char *)ksym-name, mod,
SYM_DEFINED, 0);
- }
-Index: modutils-2.4.27/genksyms/genksyms.c
-===
modutils-2.4.27.orig/genksyms/genksyms.c
-+++ modutils-2.4.27/genksyms/genksyms.c
-@@ -45,7 +45,7 @@ char *cur_filename, *output_directory;
- int flag_debug, flag_dump_defs, flag_warnings;
- int checksum_version = 1, kernel_version = version(2,0,0);
-
--static int errors;
-+int errors;
- static int nsyms;
-
- static struct symbol *expansion_trail;
-Index: modutils-2.4.27/insmod/insmod.c
[OE-core] [PATCH v4 5/8] modutils-initscripts: move recipe prior to modutils removal
Signed-off-by: Anders Darander and...@chargestorm.se
---
.../{modutils = module-init-tools}/files/PD.patch |0
.../files/modutils.sh |0
.../modutils-initscripts.bb|0
3 files changed, 0 insertions(+), 0 deletions(-)
rename meta/recipes-kernel/{modutils = module-init-tools}/files/PD.patch
(100%)
rename meta/recipes-kernel/{modutils = module-init-tools}/files/modutils.sh
(100%)
rename meta/recipes-kernel/{modutils =
module-init-tools}/modutils-initscripts.bb (100%)
diff --git a/meta/recipes-kernel/modutils/files/PD.patch
b/meta/recipes-kernel/module-init-tools/files/PD.patch
similarity index 100%
rename from meta/recipes-kernel/modutils/files/PD.patch
rename to meta/recipes-kernel/module-init-tools/files/PD.patch
diff --git a/meta/recipes-kernel/modutils/files/modutils.sh
b/meta/recipes-kernel/module-init-tools/files/modutils.sh
similarity index 100%
rename from meta/recipes-kernel/modutils/files/modutils.sh
rename to meta/recipes-kernel/module-init-tools/files/modutils.sh
diff --git a/meta/recipes-kernel/modutils/modutils-initscripts.bb
b/meta/recipes-kernel/module-init-tools/modutils-initscripts.bb
similarity index 100%
rename from meta/recipes-kernel/modutils/modutils-initscripts.bb
rename to meta/recipes-kernel/module-init-tools/modutils-initscripts.bb
--
1.7.4.1
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH v4 4/8] kernel.bblass: remove get_kernelmajorversion
It is now unused.
Signed-off-by: Anders Darander and...@chargestorm.se
---
meta/classes/linux-kernel-base.bbclass |8
1 files changed, 0 insertions(+), 8 deletions(-)
diff --git a/meta/classes/linux-kernel-base.bbclass
b/meta/classes/linux-kernel-base.bbclass
index 510951a..4f2b0a4 100644
--- a/meta/classes/linux-kernel-base.bbclass
+++ b/meta/classes/linux-kernel-base.bbclass
@@ -24,14 +24,6 @@ def get_kernelversion(p):
return m.group(1)
return None
-def get_kernelmajorversion(p):
- import re
- r = re.compile(([0-9]+\.[0-9]+).*)
- m = r.match(p);
- if m:
- return m.group(1)
- return None
-
def linux_module_packages(s, d):
suffix =
return .join(map(lambda s: kernel-module-%s%s %
(s.lower().replace('_', '-').replace('@', '+'), suffix), s.split()))
--
1.7.4.1
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH v4 7/8] task-base: remove modutils reference.
Also remove the other kernel24 references.
Make everything dependent on kernel26 default.
Signed-off-by: Anders Darander and...@chargestorm.se
---
meta/recipes-core/tasks/task-base.bb | 24
1 files changed, 4 insertions(+), 20 deletions(-)
diff --git a/meta/recipes-core/tasks/task-base.bb
b/meta/recipes-core/tasks/task-base.bb
index 3ff57ff..62432b4 100644
--- a/meta/recipes-core/tasks/task-base.bb
+++ b/meta/recipes-core/tasks/task-base.bb
@@ -45,7 +45,7 @@ PACKAGES = ' \
${@base_contains(DISTRO_FEATURES, raid, task-base-raid,
,d)} \
${@base_contains(DISTRO_FEATURES, zeroconf,
task-base-zeroconf, , d)} \
\
-
${@base_contains(MACHINE_FEATURES,kernel26,task-base-kernel26,task-base-kernel24,d)}
\
+task-base-kernel26 \
'
ALLOW_EMPTY = 1
@@ -58,12 +58,12 @@ PACKAGE_ARCH = ${MACHINE_ARCH}
#
# linux-hotplug or none
#
-HOTPLUG ?= ${@base_contains(MACHINE_FEATURES, kernel24,
linux-hotplug,,d)}
+HOTPLUG ?=
#
# pcmciautils for = 2.6.13-rc1, pcmcia-cs for others
#
-PCMCIA_MANAGER ?= ${@base_contains('MACHINE_FEATURES',
'kernel26','pcmciautils','pcmcia-cs',d)}
+PCMCIA_MANAGER ?= pcmciautils
#
# those ones can be set in machine config to supply packages needed to get
machine booting
@@ -79,7 +79,7 @@ RDEPENDS_task-base = \
task-machine-base \
${HOTPLUG} \
\
-${@base_contains('MACHINE_FEATURES',
'kernel26','task-base-kernel26','task-base-kernel24',d)} \
+task-base-kernel26 \
${@base_contains('MACHINE_FEATURES', 'apm', 'task-base-apm', '',d)} \
${@base_contains('MACHINE_FEATURES', 'acpi', 'task-base-acpi', '',d)} \
${@base_contains('MACHINE_FEATURES', 'keyboard', 'task-base-keyboard',
'',d)} \
@@ -155,17 +155,10 @@ RRECOMMENDS_task-distro-base =
${DISTRO_EXTRA_RRECOMMENDS}
RDEPENDS_task-machine-base = ${MACHINE_EXTRA_RDEPENDS}
RRECOMMENDS_task-machine-base = ${MACHINE_EXTRA_RRECOMMENDS}
-RDEPENDS_task-base-kernel24 = \
-modutils-depmod
-
RDEPENDS_task-base-kernel26 = \
sysfsutils \
module-init-tools
-RRECOMMENDS_task-base-kernel24 = \
-kernel-module-input \
-kernel-module-uinput
-
RRECOMMENDS_task-base-kernel26 = \
kernel-module-nls-utf8 \
kernel-module-input \
@@ -221,21 +214,12 @@ RDEPENDS_task-base-pcmcia = \
RRECOMMENDS_task-base-pcmcia = \
-${@base_contains('MACHINE_FEATURES', 'kernel26', '${task-base-pcmcia26}',
'${task-base-pcmcia24}',d)} \
kernel-module-pcmcia \
kernel-module-airo-cs \
kernel-module-pcnet-cs \
kernel-module-serial-cs \
kernel-module-ide-cs \
kernel-module-ide-disk \
-
-
-task-base-pcmcia24 = \
-${@base_contains('DISTRO_FEATURES', 'wifi', 'hostap-modules-cs', '',d)} \
-${@base_contains('DISTRO_FEATURES', 'wifi', 'orinoco-modules-cs', '',d)} \
-
-
-task-base-pcmcia26 = \
${@base_contains('DISTRO_FEATURES', 'wifi', 'kernel-module-hostap-cs',
'',d)} \
${@base_contains('DISTRO_FEATURES', 'wifi', 'kernel-module-orinoco-cs',
'',d)} \
${@base_contains('DISTRO_FEATURES', 'wifi', 'kernel-module-spectrum-cs',
'',d)}
--
1.7.4.1
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH v4 3/8] modules-init-tools(-cross): update to 3.16
Update to get support for Linux 3.0.
Delete the ignore_arch_directory.patch (as it does not apply to 3.16).
Signed-off-by: Anders Darander and...@chargestorm.se
---
.../files/ignore_arch_directory.patch | 30
...oss_3.12.bb = module-init-tools-cross_3.16.bb} |4 +-
.../module-init-tools/module-init-tools.inc|1 -
...nit-tools_3.12.bb = module-init-tools_3.16.bb} |6 ++--
4 files changed, 5 insertions(+), 36 deletions(-)
delete mode 100644
meta/recipes-kernel/module-init-tools/files/ignore_arch_directory.patch
rename meta/recipes-kernel/module-init-tools/{module-init-tools-cross_3.12.bb
= module-init-tools-cross_3.16.bb} (62%)
rename meta/recipes-kernel/module-init-tools/{module-init-tools_3.12.bb =
module-init-tools_3.16.bb} (87%)
diff --git
a/meta/recipes-kernel/module-init-tools/files/ignore_arch_directory.patch
b/meta/recipes-kernel/module-init-tools/files/ignore_arch_directory.patch
deleted file mode 100644
index d29957d..000
--- a/meta/recipes-kernel/module-init-tools/files/ignore_arch_directory.patch
+++ /dev/null
@@ -1,30 +0,0 @@
-# not sure the reason yet. Keep for a while and verify later.
-#
-# comments added by Kevin Tian kevin.t...@intel.com, 2010-07-21
-
-Upstream-Status: Pending
-
-diff -ruN module-init-tools-3.12.orig/modprobe.8
module-init-tools-3.12/modprobe.8
module-init-tools-3.12/modprobe.8.orig
-+++ module-init-tools-3.12/modprobe.8
-@@ -27,6 +27,7 @@
- (see \fBmodprobe.conf\fR(5)). \fBmodprobe\fR will also use module
- options specified on the kernel command line in the form of
- module\.option\.
-+All files in the \fI/etc/modprobe.d/arch/\fR directory are ignored.
- .PP
- Note that unlike in 2.4 series Linux kernels (which are not supported
- by this tool) this version of \fBmodprobe\fR does not
module-init-tools-3.12/modprobe.c.orig
-+++ module-init-tools-3.12/modprobe.c
-@@ -1052,6 +1052,10 @@
- DIR *dir;
- int ret = 0;
-
-+ /* ignore everything in this directory */
-+ if (streq(filename, /etc/modprobe.d/arch))
-+ return 1;
-+
- dir = opendir(filename);
- if (dir) {
- struct file_entry {
diff --git
a/meta/recipes-kernel/module-init-tools/module-init-tools-cross_3.12.bb
b/meta/recipes-kernel/module-init-tools/module-init-tools-cross_3.16.bb
similarity index 62%
rename from
meta/recipes-kernel/module-init-tools/module-init-tools-cross_3.12.bb
rename to meta/recipes-kernel/module-init-tools/module-init-tools-cross_3.16.bb
index 5cbf9c5..8b3458b 100644
--- a/meta/recipes-kernel/module-init-tools/module-init-tools-cross_3.12.bb
+++ b/meta/recipes-kernel/module-init-tools/module-init-tools-cross_3.16.bb
@@ -1,7 +1,7 @@
require module-init-tools.inc
-PR = r2
+PR = r0
inherit cross
-PROVIDES += virtual/${TARGET_PREFIX}depmod virtual/${TARGET_PREFIX}depmod-2.6
+PROVIDES += virtual/${TARGET_PREFIX}depmod
SRC_URI += file://no-static-binaries.patch
diff --git a/meta/recipes-kernel/module-init-tools/module-init-tools.inc
b/meta/recipes-kernel/module-init-tools/module-init-tools.inc
index 4d96d16..c290c4f 100644
--- a/meta/recipes-kernel/module-init-tools/module-init-tools.inc
+++ b/meta/recipes-kernel/module-init-tools/module-init-tools.inc
@@ -12,7 +12,6 @@ FILES_module-init-tools-depmod = ${sbindir}/depmod.26
FILES_module-init-tools-insmod-static = ${sbindir}/insmod.static
SRC_URI =
${KERNELORG_MIRROR}/linux/utils/kernel/module-init-tools/module-init-tools-${PV}.tar.bz2
\
- file://ignore_arch_directory.patch \
file://modutils_extension.patch \
file://disable_man.patch \
file://grab_module_memset.patch
diff --git a/meta/recipes-kernel/module-init-tools/module-init-tools_3.12.bb
b/meta/recipes-kernel/module-init-tools/module-init-tools_3.16.bb
similarity index 87%
rename from meta/recipes-kernel/module-init-tools/module-init-tools_3.12.bb
rename to meta/recipes-kernel/module-init-tools/module-init-tools_3.16.bb
index 3d7c287..0248b46 100644
--- a/meta/recipes-kernel/module-init-tools/module-init-tools_3.12.bb
+++ b/meta/recipes-kernel/module-init-tools/module-init-tools_3.16.bb
@@ -1,5 +1,5 @@
require module-init-tools.inc
-PR = r1
+PR = r0
# autotools set prefix to /usr, however we want them in /bin and /sbin
bindir = /bin
@@ -38,5 +38,5 @@ pkg_prerm_module-init-tools-depmod() {
update-alternatives --remove depmod /sbin/depmod.26
}
-SRC_URI[md5sum] = 8b2257ce9abef74c4a44d825d23140f3
-SRC_URI[sha256sum] =
d012ab07ea26721467a85a775f34747c1c8897e37f16bec5317d8a72ef8b4f17
+SRC_URI[md5sum] = bc44832c6e41707b8447e2847d2019f5
+SRC_URI[sha256sum] =
e1f2cdcae64a8effc25e545a5e0bdaf312f816ebbcd0916e4e87450755fab64b
--
1.7.4.1
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH v4 8/8] distro_tracking_fields: remove modutils.
Signed-off-by: Anders Darander and...@chargestorm.se --- .../conf/distro/include/distro_tracking_fields.inc |8 +--- 1 files changed, 1 insertions(+), 7 deletions(-) diff --git a/meta/conf/distro/include/distro_tracking_fields.inc b/meta/conf/distro/include/distro_tracking_fields.inc index 2e7996b..ad64581 100644 --- a/meta/conf/distro/include/distro_tracking_fields.inc +++ b/meta/conf/distro/include/distro_tracking_fields.inc @@ -1,5 +1,6 @@ RECIPE_STATUS_pn-diffutils = green RECIPE_LATEST_VERSION_pn-diffutils = 3.0 + RECIPE_LAST_UPDATE_pn-diffutils = Dec 10, 2010 RECIPE_MAINTAINER_pn-diffutils = Mei Lei lei@intel.com @@ -684,13 +685,6 @@ RECIPE_COMMENTS_pn-keymaps = local scripts follow Poky's MIT license, however i RECIPE_LAST_UPDATE_pn-keymaps = Jul 21, 2006 RECIPE_MAINTAINER_pn-keymaps = Yu Ke ke...@intel.com -RECIPE_STATUS_pn-modutils = red -RECIPE_DEPENDENCY_CHECK_pn-modutils-initscripts = not done -RECIPE_LATEST_VERSION_pn-modutils = 2.4.27 -RECIPE_LAST_UPDATE_pn-modutils = Jul 21, 2006 -RECIPE_MAINTAINER_pn-modutils = Yu Ke ke...@intel.com -DISTRO_PN_ALIAS_pn-modutils = Ubuntu=module-init-tools Fedora=module-init-tools - RECIPE_STATUS_pn-modutils-initscripts = green RECIPE_DEPENDENCY_CHECK_pn-modutils-initscripts = not done RECIPE_LATEST_VERSION_pn-modutils-initscripts = 1.0 -- 1.7.4.1 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] It's broken, please revert. Re: [PATCH 0/4 V4] Share gcc work directories
Op 1 jul 2011, om 01:26 heeft Saul Wold het volgende geschreven:
On 06/28/2011 02:05 AM, Robert Yang wrote:
Changes of V4:
* Change the definition of GLIBC_DYNAMIC_LINKER as Richard suggested.
e.g., the entries in the files that look like:
#define GLIBC_DYNAMIC_LINKER64 /lib64/ld-linux-x86-64.so.2
become
#define GLIBC_DYNAMIC_LINKER64 SYSTEMLIBS_DIR/ld-linux-x86-64.so.2
and we define SYSTEMLIBS_DIR in defaults.h.
NOTE, the round brackets:
#define GLIBC_DYNAMIC_LINKER64 (SYSTEMLIBS_DIR /ld-linux-x86-64.so.2)
doesn't work in in the following define:
#define LINUX_DYNAMIC_LINKER \
CHOOSE_DYNAMIC_LINKER (GLIBC_DYNAMIC_LINKER, UCLIBC_DYNAMIC_LINKER)
so use:
#define GLIBC_DYNAMIC_LINKER64 SYSTEMLIBS_DIR/ld-linux-x86-64.so.2
* Compare to V3, reduce two patches which are for gcc-crosssdk.inc and
gcc-cross-canadian which are not needed any more.
* Fix the conflicts(gcc-4.6.0 - gcc-4.6, and the ${BRANCH})
* Both tested 4.5.1 and 4.6:
$ bitbake meta-toolchain core-image-sato
$ runqemu qemurm
Also unpack the sdk to /opt and test to make sure the toolchain works well.
The following changes since commit a1f79a7896b6411669b3ccada6204d2695e80fc5:
runqueue.py: Add umask task control (2011-06-24 12:23:12 +0100)
are available in the git repository at:
git://git.pokylinux.org/poky-contrib robert/share_gcc
http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=robert/share_gcc
Robert Yang (4):
bitbake: share source directory
Share gcc work directories
gcc-4.5.1: share work directories
gcc-4.6: share work directories
bitbake/lib/bb/build.py|4 +-
bitbake/lib/bb/cache.py|3 +
bitbake/lib/bb/runqueue.py | 10 +++
meta/recipes-devtools/gcc/gcc-4.5.1.inc|1 +
.../gcc-4.5.1/use-defaults.h-and-t-oe-in-B.patch | 57 ++
meta/recipes-devtools/gcc/gcc-4.6.inc |5 +-
.../gcc/gcc-4.6/use-defaults.h-and-t-oe-in-B.patch | 80
meta/recipes-devtools/gcc/gcc-common.inc | 32 +++-
meta/recipes-devtools/gcc/gcc-configure-common.inc | 48 +++-
meta/recipes-devtools/gcc/gcc-configure-cross.inc |4 +-
meta/recipes-devtools/gcc/gcc-crosssdk.inc |6 --
11 files changed, 218 insertions(+), 32 deletions(-)
create mode 100644
meta/recipes-devtools/gcc/gcc-4.5.1/use-defaults.h-and-t-oe-in-B.patch
create mode 100644
meta/recipes-devtools/gcc/gcc-4.6/use-defaults.h-and-t-oe-in-B.patch
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Merged into OE-Core
incremental build with rm_work turned on:
ERROR: Function 'do_configure' failed (see
/OE/tentacle/build/tmp-angstrom_2010_x-eglibc/work/armv7a-angstrom-linux-gnueabi/gcc-cross-initial-4.5-r37.0+svnr175127/temp/log.do_configure.27092
for further information)
ERROR: Logfile of failure stored in:
/OE/tentacle/build/tmp-angstrom_2010_x-eglibc/work/armv7a-angstrom-linux-gnueabi/gcc-cross-initial-4.5-r37.0+svnr175127/temp/log.do_configure.27092
Log data follows:
| + cd
/OE/tentacle/build/tmp-angstrom_2010_x-eglibc/work/armv7a-angstrom-linux-gnueabi/gcc-cross-initial-4.5-r37.0+svnr175127/gcc-4.5/build.x86_64-linux.arm-angstrom-linux-gnueabi
| + do_configure
| + sed -i
'/OE/tentacle/build/tmp-angstrom_2010_x-eglibc/work/armv7a-angstrom-linux-gnueabi/gcc-cross-initial-4.5-r37.0+svnr175127/gcc-4_5-branch/gcc/config/*/linux*.h'
-e 's#\(GLIBC_DYNAMIC_LINKER[^ ]*\)\( */lib.*\)#\1 SYSTEMLIBS_DIR\2#'
| sed: can't read
/OE/tentacle/build/tmp-angstrom_2010_x-eglibc/work/armv7a-angstrom-linux-gnueabi/gcc-cross-initial-4.5-r37.0+svnr175127/gcc-4_5-branch/gcc/config/*/linux*.h:
No such file or directory
| ERROR: Function 'do_configure' failed (see
/OE/tentacle/build/tmp-angstrom_2010_x-eglibc/work/armv7a-angstrom-linux-gnueabi/gcc-cross-initial-4.5-r37.0+svnr175127/temp/log.do_configure.27092
for further information)
NOTE: package gcc-cross-initial-4.5-r37.0+svnr175127: task do_configure: Failed
ERROR: Task 764
(/OE/tentacle/sources/meta-openembedded/meta-oe/recipes-devtools/gcc/gcc-cross-initial_4.5.bb,
do_configure) failed with exit code '1'
Can this patchset get reverted please and reapplied when it actually has been
tested to work?
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 2/4] uboot: Update to 2011.06
Op 1 jul 2011, om 08:54 heeft Saul Wold het volgende geschreven:
[YOCTO #1198]
Signed-off-by: Saul Wold s...@linux.intel.com
---
...Drop-config.h-include-in-tools-imximage.h.patch |0
...ove-LDSCRIPT-processing-to-the-top-level-.patch |0
...kimage_2011.03.bb = u-boot-mkimage_2011.06.bb} | 12 +---
.../uboot/{u-boot_2011.03.bb = u-boot_2011.06.bb} | 10 +-
You do realize that people .bbappending 2011.03 are now left out in the cold,
right?
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v4 7/8] task-base: remove modutils reference.
Op 1 jul 2011, om 09:06 heeft Anders Darander het volgende geschreven:
Also remove the other kernel24 references.
Make everything dependent on kernel26 default.
Since there will be only one of each, can we just completely scrap there
variables and put the items directly in the tasks?
regards,
Koen
Signed-off-by: Anders Darander and...@chargestorm.se
---
meta/recipes-core/tasks/task-base.bb | 24
1 files changed, 4 insertions(+), 20 deletions(-)
diff --git a/meta/recipes-core/tasks/task-base.bb
b/meta/recipes-core/tasks/task-base.bb
index 3ff57ff..62432b4 100644
--- a/meta/recipes-core/tasks/task-base.bb
+++ b/meta/recipes-core/tasks/task-base.bb
@@ -45,7 +45,7 @@ PACKAGES = ' \
${@base_contains(DISTRO_FEATURES, raid, task-base-raid,
,d)} \
${@base_contains(DISTRO_FEATURES, zeroconf,
task-base-zeroconf, , d)} \
\
-
${@base_contains(MACHINE_FEATURES,kernel26,task-base-kernel26,task-base-kernel24,d)}
\
+task-base-kernel26 \
'
ALLOW_EMPTY = 1
@@ -58,12 +58,12 @@ PACKAGE_ARCH = ${MACHINE_ARCH}
#
# linux-hotplug or none
#
-HOTPLUG ?= ${@base_contains(MACHINE_FEATURES, kernel24,
linux-hotplug,,d)}
+HOTPLUG ?=
#
# pcmciautils for = 2.6.13-rc1, pcmcia-cs for others
#
-PCMCIA_MANAGER ?= ${@base_contains('MACHINE_FEATURES',
'kernel26','pcmciautils','pcmcia-cs',d)}
+PCMCIA_MANAGER ?= pcmciautils
#
# those ones can be set in machine config to supply packages needed to get
machine booting
@@ -79,7 +79,7 @@ RDEPENDS_task-base = \
task-machine-base \
${HOTPLUG} \
\
-${@base_contains('MACHINE_FEATURES',
'kernel26','task-base-kernel26','task-base-kernel24',d)} \
+task-base-kernel26 \
${@base_contains('MACHINE_FEATURES', 'apm', 'task-base-apm', '',d)} \
${@base_contains('MACHINE_FEATURES', 'acpi', 'task-base-acpi', '',d)} \
${@base_contains('MACHINE_FEATURES', 'keyboard', 'task-base-keyboard',
'',d)} \
@@ -155,17 +155,10 @@ RRECOMMENDS_task-distro-base =
${DISTRO_EXTRA_RRECOMMENDS}
RDEPENDS_task-machine-base = ${MACHINE_EXTRA_RDEPENDS}
RRECOMMENDS_task-machine-base = ${MACHINE_EXTRA_RRECOMMENDS}
-RDEPENDS_task-base-kernel24 = \
-modutils-depmod
-
RDEPENDS_task-base-kernel26 = \
sysfsutils \
module-init-tools
-RRECOMMENDS_task-base-kernel24 = \
-kernel-module-input \
-kernel-module-uinput
-
RRECOMMENDS_task-base-kernel26 = \
kernel-module-nls-utf8 \
kernel-module-input \
@@ -221,21 +214,12 @@ RDEPENDS_task-base-pcmcia = \
RRECOMMENDS_task-base-pcmcia = \
-${@base_contains('MACHINE_FEATURES', 'kernel26',
'${task-base-pcmcia26}', '${task-base-pcmcia24}',d)} \
kernel-module-pcmcia \
kernel-module-airo-cs \
kernel-module-pcnet-cs \
kernel-module-serial-cs \
kernel-module-ide-cs \
kernel-module-ide-disk \
-
-
-task-base-pcmcia24 = \
-${@base_contains('DISTRO_FEATURES', 'wifi', 'hostap-modules-cs', '',d)} \
-${@base_contains('DISTRO_FEATURES', 'wifi', 'orinoco-modules-cs', '',d)}
\
-
-
-task-base-pcmcia26 = \
${@base_contains('DISTRO_FEATURES', 'wifi', 'kernel-module-hostap-cs',
'',d)} \
${@base_contains('DISTRO_FEATURES', 'wifi', 'kernel-module-orinoco-cs',
'',d)} \
${@base_contains('DISTRO_FEATURES', 'wifi', 'kernel-module-spectrum-cs',
'',d)}
--
1.7.4.1
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] It's broken, please revert. Re: [PATCH 0/4 V4] Share gcc work directories
On Fri, 2011-07-01 at 09:15 +0200, Koen Kooi wrote:
Op 1 jul 2011, om 01:26 heeft Saul Wold het volgende geschreven:
On 06/28/2011 02:05 AM, Robert Yang wrote:
Changes of V4:
* Change the definition of GLIBC_DYNAMIC_LINKER as Richard suggested.
e.g., the entries in the files that look like:
#define GLIBC_DYNAMIC_LINKER64 /lib64/ld-linux-x86-64.so.2
become
#define GLIBC_DYNAMIC_LINKER64 SYSTEMLIBS_DIR/ld-linux-x86-64.so.2
and we define SYSTEMLIBS_DIR in defaults.h.
NOTE, the round brackets:
#define GLIBC_DYNAMIC_LINKER64 (SYSTEMLIBS_DIR /ld-linux-x86-64.so.2)
doesn't work in in the following define:
#define LINUX_DYNAMIC_LINKER \
CHOOSE_DYNAMIC_LINKER (GLIBC_DYNAMIC_LINKER,
UCLIBC_DYNAMIC_LINKER)
so use:
#define GLIBC_DYNAMIC_LINKER64 SYSTEMLIBS_DIR/ld-linux-x86-64.so.2
* Compare to V3, reduce two patches which are for gcc-crosssdk.inc and
gcc-cross-canadian which are not needed any more.
* Fix the conflicts(gcc-4.6.0 - gcc-4.6, and the ${BRANCH})
* Both tested 4.5.1 and 4.6:
$ bitbake meta-toolchain core-image-sato
$ runqemu qemurm
Also unpack the sdk to /opt and test to make sure the toolchain works
well.
The following changes since commit
a1f79a7896b6411669b3ccada6204d2695e80fc5:
runqueue.py: Add umask task control (2011-06-24 12:23:12 +0100)
are available in the git repository at:
git://git.pokylinux.org/poky-contrib robert/share_gcc
http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=robert/share_gcc
Robert Yang (4):
bitbake: share source directory
Share gcc work directories
gcc-4.5.1: share work directories
gcc-4.6: share work directories
bitbake/lib/bb/build.py|4 +-
bitbake/lib/bb/cache.py|3 +
bitbake/lib/bb/runqueue.py | 10 +++
meta/recipes-devtools/gcc/gcc-4.5.1.inc|1 +
.../gcc-4.5.1/use-defaults.h-and-t-oe-in-B.patch | 57 ++
meta/recipes-devtools/gcc/gcc-4.6.inc |5 +-
.../gcc/gcc-4.6/use-defaults.h-and-t-oe-in-B.patch | 80
meta/recipes-devtools/gcc/gcc-common.inc | 32 +++-
meta/recipes-devtools/gcc/gcc-configure-common.inc | 48 +++-
meta/recipes-devtools/gcc/gcc-configure-cross.inc |4 +-
meta/recipes-devtools/gcc/gcc-crosssdk.inc |6 --
11 files changed, 218 insertions(+), 32 deletions(-)
create mode 100644
meta/recipes-devtools/gcc/gcc-4.5.1/use-defaults.h-and-t-oe-in-B.patch
create mode 100644
meta/recipes-devtools/gcc/gcc-4.6/use-defaults.h-and-t-oe-in-B.patch
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Merged into OE-Core
incremental build with rm_work turned on:
ERROR: Function 'do_configure' failed (see
/OE/tentacle/build/tmp-angstrom_2010_x-eglibc/work/armv7a-angstrom-linux-gnueabi/gcc-cross-initial-4.5-r37.0+svnr175127/temp/log.do_configure.27092
for further information)
ERROR: Logfile of failure stored in:
/OE/tentacle/build/tmp-angstrom_2010_x-eglibc/work/armv7a-angstrom-linux-gnueabi/gcc-cross-initial-4.5-r37.0+svnr175127/temp/log.do_configure.27092
Log data follows:
| + cd
/OE/tentacle/build/tmp-angstrom_2010_x-eglibc/work/armv7a-angstrom-linux-gnueabi/gcc-cross-initial-4.5-r37.0+svnr175127/gcc-4.5/build.x86_64-linux.arm-angstrom-linux-gnueabi
| + do_configure
| + sed -i
'/OE/tentacle/build/tmp-angstrom_2010_x-eglibc/work/armv7a-angstrom-linux-gnueabi/gcc-cross-initial-4.5-r37.0+svnr175127/gcc-4_5-branch/gcc/config/*/linux*.h'
-e 's#\(GLIBC_DYNAMIC_LINKER[^ ]*\)\( */lib.*\)#\1 SYSTEMLIBS_DIR\2#'
| sed: can't read
/OE/tentacle/build/tmp-angstrom_2010_x-eglibc/work/armv7a-angstrom-linux-gnueabi/gcc-cross-initial-4.5-r37.0+svnr175127/gcc-4_5-branch/gcc/config/*/linux*.h:
No such file or directory
| ERROR: Function 'do_configure' failed (see
/OE/tentacle/build/tmp-angstrom_2010_x-eglibc/work/armv7a-angstrom-linux-gnueabi/gcc-cross-initial-4.5-r37.0+svnr175127/temp/log.do_configure.27092
for further information)
NOTE: package gcc-cross-initial-4.5-r37.0+svnr175127: task do_configure:
Failed
ERROR: Task 764
(/OE/tentacle/sources/meta-openembedded/meta-oe/recipes-devtools/gcc/gcc-cross-initial_4.5.bb,
do_configure) failed with exit code '1'
Can this patchset get reverted please and reapplied when it actually has been
tested to work?
Testing patches is not the sole responsibility of myself and Saul. This
gcc patchset was on the mailing list for a considerable time and has
been tested in a variety of ways. Various breakage was identified found
and those breakages were fixed. The fact there looks to be some
incremental build issue with rm_work is
Re: [OE-core] It's broken, please revert. Re: [PATCH 0/4 V4] Share gcc work directories
On Fri, 2011-07-01 at 09:15 +0200, Koen Kooi wrote:
incremental build with rm_work turned on:
ERROR: Function 'do_configure' failed (see
/OE/tentacle/build/tmp-angstrom_2010_x-eglibc/work/armv7a-angstrom-linux-gnueabi/gcc-cross-initial-4.5-r37.0+svnr175127/temp/log.do_configure.27092
for further information)
ERROR: Logfile of failure stored in:
/OE/tentacle/build/tmp-angstrom_2010_x-eglibc/work/armv7a-angstrom-linux-gnueabi/gcc-cross-initial-4.5-r37.0+svnr175127/temp/log.do_configure.27092
Log data follows:
| + cd
/OE/tentacle/build/tmp-angstrom_2010_x-eglibc/work/armv7a-angstrom-linux-gnueabi/gcc-cross-initial-4.5-r37.0+svnr175127/gcc-4.5/build.x86_64-linux.arm-angstrom-linux-gnueabi
| + do_configure
| + sed -i
'/OE/tentacle/build/tmp-angstrom_2010_x-eglibc/work/armv7a-angstrom-linux-gnueabi/gcc-cross-initial-4.5-r37.0+svnr175127/gcc-4_5-branch/gcc/config/*/linux*.h'
-e 's#\(GLIBC_DYNAMIC_LINKER[^ ]*\)\( */lib.*\)#\1 SYSTEMLIBS_DIR\2#'
| sed: can't read
/OE/tentacle/build/tmp-angstrom_2010_x-eglibc/work/armv7a-angstrom-linux-gnueabi/gcc-cross-initial-4.5-r37.0+svnr175127/gcc-4_5-branch/gcc/config/*/linux*.h:
No such file or directory
| ERROR: Function 'do_configure' failed (see
/OE/tentacle/build/tmp-angstrom_2010_x-eglibc/work/armv7a-angstrom-linux-gnueabi/gcc-cross-initial-4.5-r37.0+svnr175127/temp/log.do_configure.27092
for further information)
NOTE: package gcc-cross-initial-4.5-r37.0+svnr175127: task do_configure:
Failed
ERROR: Task 764
(/OE/tentacle/sources/meta-openembedded/meta-oe/recipes-devtools/gcc/gcc-cross-initial_4.5.bb,
do_configure) failed with exit code '1'
Can this patchset get reverted please and reapplied when it actually has been
tested to work?
I checked and everything is fine with rm_work.
Looking at this error, something is changing ${S} as there is no mention
of work-shared in the sed command yet there should be.
At a guess this is coming from:
http://git.angstrom-distribution.org/cgi-bin/cgit.cgi/meta-openembedded/tree/meta-oe/recipes-devtools/gcc/gcc-4.5.inc
where it says:
S = ${WORKDIR}/${BRANCH}
and if that is changed to
S_append = /${BRANCH}
or removed it will likely work better.
Cheers,
Richard
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] Proposal: recipe feature switches
2011/7/1 Richard Purdie richard.pur...@linuxfoundation.org
On Thu, 2011-06-30 at 18:10 +0100, Chris Elston wrote:
We're looking to base an embedded development on oe-core in the near
future, and one of the things we must have is the ability to configure
features in/out of recipes per distro.
At the moment some recipes have a configuration / set of dependencies
baked in to the recipe. For example, gstreamer has theora, ogg and
vorbis hard-coded in to it's EXTRA_OECONF and DEPENDS. Currently, you'd
have to override the DEPENDS and EXTRA_OECONF for the recipe in the
distro layer - which means moving knowledge about what EXTRA_OECONF
flags bring in which dependencies outside of the recipe. It seems that
this metadata is better contained in the recipe.
I'm proposing something along the lines of the following:
This is actually along the lines of what I've been thinking too!
diff --git a/meta/classes/utils.bbclass b/meta/classes/utils.bbclass
index 9930a24..4f1c54f 100644
--- a/meta/classes/utils.bbclass
+++ b/meta/classes/utils.bbclass
@@ -84,6 +84,15 @@ def oe_system(d, cmd, **kwargs):
kwargs[shell] = True
return oe_popen(d, cmd, **kwargs).wait()
+def oe_package_feature_switch(feature, switch_on, switch_off,
dependencies, d):
+oeconf = d.getVar(EXTRA_OECONF, True)
+if feature in d.getVar(PACKAGE_FEATURES, True).split():
+d.setVar(EXTRA_OECONF, oeconf + + switch_on)
+depends = d.getVar(DEPENDS, True)
+d.setVar(DEPENDS, depends + + dependencies)
+else:
+d.setVar(EXTRA_OECONF, oeconf + + switch_off)
+
oe_soinstall() {
# Purpose: Install shared library file and
# create the necessary links
diff --git
a/meta/recipes-multimedia/gstreamer/gst-plugins-base_0.10.32.bb
b/meta/recipes-multimedia/gstreamer/gst-plugins-base_0.10.32.bb
index f81011f..6fc6405 100644
--- a/meta/recipes-multimedia/gstreamer/gst-plugins-base_0.10.32.bb
+++ b/meta/recipes-multimedia/gstreamer/gst-plugins-base_0.10.32.bb
@@ -6,10 +6,12 @@ LIC_FILES_CHKSUM =
file://COPYING;md5=0636e73ff0215e8d672dc4c32c317bb3 \
file://COPYING.LIB;md5=55ca817ccb7d5b5b66355690e9abc605 \
file://gst/ffmpegcolorspace/utils.c;beginline=1;endline=20;md5=9c83a200b8e597b26ca29df20fc6ecd0
-DEPENDS += virtual/libx11 alsa-lib freetype gnome-vfs liboil libogg
libvorbis libxv libtheora avahi util-linux tremor
+DEPENDS += virtual/libx11 alsa-lib freetype gnome-vfs liboil libxv
avahi util-linux tremor
RDEPENDS_${PN} += gnome-vfs-plugin-file gnome-vfs-plugin-http
gnome-vfs-plugin-ftp \
gnome-vfs-plugin-sftp
+PACKAGE_FEATURES ?= ogg vorbis theora
+
SRC_URI += file://gst-plugins-base-tremor.patch
SRC_URI[md5sum] = 2920af2b3162f3d9fbaa7fabc8ed4d38
@@ -21,6 +23,12 @@ inherit gettext
EXTRA_OECONF += --disable-freetypetest --disable-pango
+python () {
+ oe_package_feature_switch(ogg, --enable-ogg, --disable-ogg,
libogg, d)
+ oe_package_feature_switch(vorbis, --enable-vorbis,
--disable-vorbis, libvorbis, d)
+ oe_package_feature_switch(theora, --enable-theora,
--disable-theora, libtheora, d)
+}
+
do_configure_prepend() {
# This m4 file contains nastiness which conflicts with libtool
2.2.2
rm -f ${S}/m4/lib-link.m4
Then in your layer, you could configure which plugins gstreamer should
be built with like this:
PACKAGE_FEATURES_pn-gst-plugins-base = ogg theora
Or just filter out the package features that you don't want.
With a little extra work, it would also be possible to check the list of
package features a distro layer requests against those the recipe
actually implements. Then we could get an early warning when we pull
oe-core and a recipe has stopped implementing a feature.
How about something like the syntax for the recipe:
PACKAGECONFIG[ogg] = --enable-ogg, --disable-ogg, libogg
PACKAGECONFIG[vorbis] = --enable-vorbis, --disable-vorbis, libvorbis
PACKAGECONFIG[theora] = --enable-theora, --disable-theora, libtheora
and then in base.bbclass we can simply:
for flag in (d.getVarFlags(PACKAGECONFIG) or {}):
manipulate DEPENDS/EXTRA_OECONF
I'm also strongly tempted to tie this into the DISTRO_FEATURES variable
instead of individual PACKAGE_FEATURES variables to make it clear how
this is intended to be used.
If we do this, we are going to need to exercise some measure of control
as someone is going to want an enable/disable option for every config
option for every package. How do we decide which make sense and which
don't?
Note that the more options you have, the more combinations there are to
test and the less testing the system likely gets. I would therefore like
to see some kind of natural pressure to only add very useful
DISTRO_FEATURES. Maybe a criteria like it affecting 5 or more recipes?
Good idea.
Personally I'd like to also bring footprint
Re: [OE-core] [PATCH] Add support for BAD_RECOMMENDATIONS to rootfs_ipk
On Thu, 2011-06-30 at 16:13 -0700, Saul Wold wrote:
On 06/30/2011 04:10 AM, Chris Elston wrote:
As discussed on IRC on 30/06/11, this patch adds support for
BAD_RECOMMENDATIONS to rootfs_ipk, which is a list of packages NOT to
install if suggested or recommended by a recipe. Taken from
http://thread.gmane.org/gmane.comp.handhelds.openembedded/30417.
Note that current support for this in oe.dev may also be broken,
depending on the version of opkg in use.
This patch does not seem to apply cleanly, could you please rebase and
resend.
Thanks
Sau!
Saul,
Apologies, mail client formatting issue. The following should work:
As discussed on IRC on 30/06/11, this patch adds support for
BAD_RECOMMENDATIONS to rootfs_ipk, which is a list of packages NOT to
install if suggested or recommended by a recipe. Taken from
http://thread.gmane.org/gmane.comp.handhelds.openembedded/30417.
Note that current support for this in oe.dev may also be broken,
depending on the version of opkg in use.
Signed-off-by: Chris Elston cels...@katalix.com
---
meta/classes/rootfs_ipk.bbclass | 18 ++
1 files changed, 18 insertions(+), 0 deletions(-)
diff --git a/meta/classes/rootfs_ipk.bbclass b/meta/classes/rootfs_ipk.bbclass
index edd84fb..bf15f4c 100644
--- a/meta/classes/rootfs_ipk.bbclass
+++ b/meta/classes/rootfs_ipk.bbclass
@@ -20,6 +20,9 @@ OPKG_POSTPROCESS_COMMANDS = ipk_insert_feed_uris
opkglibdir = ${localstatedir}/lib/opkg
+# Which packages to not install on the basis of a recommendation
+BAD_RECOMMENDATIONS ?=
+
fakeroot rootfs_ipk_do_rootfs () {
set -x
@@ -30,6 +33,21 @@ fakeroot rootfs_ipk_do_rootfs () {
mkdir -p ${T}/
+ STATUS=${IMAGE_ROOTFS}/var/lib/opkg/status
+ mkdir -p `dirname ${STATUS}`
+
+ opkg-cl ${IPKG_ARGS} update
+
+ # prime the status file with bits that we don't want
+ for i in ${BAD_RECOMMENDATIONS}; do
+ infln=`opkg-cl ${IPKG_ARGS} info $i | grep -e '^Package:' -e
'^Architecture:' -e '^Version:'`
+ if [ ! -z $infln ]; then
+ echo $infln $STATUS
+ echo Status: deinstall ok not-installed $STATUS
+ echo $STATUS
+ fi
+ done
+
#install
export INSTALL_PACKAGES_ATTEMPTONLY_IPK=${PACKAGE_INSTALL_ATTEMPTONLY}
export INSTALL_PACKAGES_LINGUAS_IPK=${LINGUAS_INSTALL}
--
1.6.2.5
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] It's broken, please revert. Re: [PATCH 0/4 V4] Share gcc work directories
Op 1 jul 2011, om 10:10 heeft Richard Purdie het volgende geschreven:
On Fri, 2011-07-01 at 09:15 +0200, Koen Kooi wrote:
Op 1 jul 2011, om 01:26 heeft Saul Wold het volgende geschreven:
On 06/28/2011 02:05 AM, Robert Yang wrote:
Changes of V4:
* Change the definition of GLIBC_DYNAMIC_LINKER as Richard suggested.
e.g., the entries in the files that look like:
#define GLIBC_DYNAMIC_LINKER64 /lib64/ld-linux-x86-64.so.2
become
#define GLIBC_DYNAMIC_LINKER64 SYSTEMLIBS_DIR/ld-linux-x86-64.so.2
and we define SYSTEMLIBS_DIR in defaults.h.
NOTE, the round brackets:
#define GLIBC_DYNAMIC_LINKER64 (SYSTEMLIBS_DIR /ld-linux-x86-64.so.2)
doesn't work in in the following define:
#define LINUX_DYNAMIC_LINKER \
CHOOSE_DYNAMIC_LINKER (GLIBC_DYNAMIC_LINKER,
UCLIBC_DYNAMIC_LINKER)
so use:
#define GLIBC_DYNAMIC_LINKER64 SYSTEMLIBS_DIR/ld-linux-x86-64.so.2
* Compare to V3, reduce two patches which are for gcc-crosssdk.inc and
gcc-cross-canadian which are not needed any more.
* Fix the conflicts(gcc-4.6.0 - gcc-4.6, and the ${BRANCH})
* Both tested 4.5.1 and 4.6:
$ bitbake meta-toolchain core-image-sato
$ runqemu qemurm
Also unpack the sdk to /opt and test to make sure the toolchain works
well.
The following changes since commit
a1f79a7896b6411669b3ccada6204d2695e80fc5:
runqueue.py: Add umask task control (2011-06-24 12:23:12 +0100)
are available in the git repository at:
git://git.pokylinux.org/poky-contrib robert/share_gcc
http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=robert/share_gcc
Robert Yang (4):
bitbake: share source directory
Share gcc work directories
gcc-4.5.1: share work directories
gcc-4.6: share work directories
bitbake/lib/bb/build.py|4 +-
bitbake/lib/bb/cache.py|3 +
bitbake/lib/bb/runqueue.py | 10 +++
meta/recipes-devtools/gcc/gcc-4.5.1.inc|1 +
.../gcc-4.5.1/use-defaults.h-and-t-oe-in-B.patch | 57 ++
meta/recipes-devtools/gcc/gcc-4.6.inc |5 +-
.../gcc/gcc-4.6/use-defaults.h-and-t-oe-in-B.patch | 80
meta/recipes-devtools/gcc/gcc-common.inc | 32 +++-
meta/recipes-devtools/gcc/gcc-configure-common.inc | 48 +++-
meta/recipes-devtools/gcc/gcc-configure-cross.inc |4 +-
meta/recipes-devtools/gcc/gcc-crosssdk.inc |6 --
11 files changed, 218 insertions(+), 32 deletions(-)
create mode 100644
meta/recipes-devtools/gcc/gcc-4.5.1/use-defaults.h-and-t-oe-in-B.patch
create mode 100644
meta/recipes-devtools/gcc/gcc-4.6/use-defaults.h-and-t-oe-in-B.patch
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Merged into OE-Core
incremental build with rm_work turned on:
ERROR: Function 'do_configure' failed (see
/OE/tentacle/build/tmp-angstrom_2010_x-eglibc/work/armv7a-angstrom-linux-gnueabi/gcc-cross-initial-4.5-r37.0+svnr175127/temp/log.do_configure.27092
for further information)
ERROR: Logfile of failure stored in:
/OE/tentacle/build/tmp-angstrom_2010_x-eglibc/work/armv7a-angstrom-linux-gnueabi/gcc-cross-initial-4.5-r37.0+svnr175127/temp/log.do_configure.27092
Log data follows:
| + cd
/OE/tentacle/build/tmp-angstrom_2010_x-eglibc/work/armv7a-angstrom-linux-gnueabi/gcc-cross-initial-4.5-r37.0+svnr175127/gcc-4.5/build.x86_64-linux.arm-angstrom-linux-gnueabi
| + do_configure
| + sed -i
'/OE/tentacle/build/tmp-angstrom_2010_x-eglibc/work/armv7a-angstrom-linux-gnueabi/gcc-cross-initial-4.5-r37.0+svnr175127/gcc-4_5-branch/gcc/config/*/linux*.h'
-e 's#\(GLIBC_DYNAMIC_LINKER[^ ]*\)\( */lib.*\)#\1 SYSTEMLIBS_DIR\2#'
| sed: can't read
/OE/tentacle/build/tmp-angstrom_2010_x-eglibc/work/armv7a-angstrom-linux-gnueabi/gcc-cross-initial-4.5-r37.0+svnr175127/gcc-4_5-branch/gcc/config/*/linux*.h:
No such file or directory
| ERROR: Function 'do_configure' failed (see
/OE/tentacle/build/tmp-angstrom_2010_x-eglibc/work/armv7a-angstrom-linux-gnueabi/gcc-cross-initial-4.5-r37.0+svnr175127/temp/log.do_configure.27092
for further information)
NOTE: package gcc-cross-initial-4.5-r37.0+svnr175127: task do_configure:
Failed
ERROR: Task 764
(/OE/tentacle/sources/meta-openembedded/meta-oe/recipes-devtools/gcc/gcc-cross-initial_4.5.bb,
do_configure) failed with exit code '1'
Can this patchset get reverted please and reapplied when it actually has
been tested to work?
Testing patches is not the sole responsibility of myself and Saul. This
gcc patchset was on the mailing list for a considerable time and has
been tested in a variety of ways. Various breakage was identified found
and those breakages were fixed. The fact there looks to be some
incremental build issue with rm_work is unfortunate and likely easy to
fix so
Re: [OE-core] Proposal: recipe feature switches
Op 1 jul 2011, om 10:55 heeft Frans Meulenbroeks het volgende geschreven:
2011/7/1 Richard Purdie richard.pur...@linuxfoundation.org
On Thu, 2011-06-30 at 18:10 +0100, Chris Elston wrote:
We're looking to base an embedded development on oe-core in the near
future, and one of the things we must have is the ability to configure
features in/out of recipes per distro.
At the moment some recipes have a configuration / set of dependencies
baked in to the recipe. For example, gstreamer has theora, ogg and
vorbis hard-coded in to it's EXTRA_OECONF and DEPENDS. Currently, you'd
have to override the DEPENDS and EXTRA_OECONF for the recipe in the
distro layer - which means moving knowledge about what EXTRA_OECONF
flags bring in which dependencies outside of the recipe. It seems that
this metadata is better contained in the recipe.
I'm proposing something along the lines of the following:
This is actually along the lines of what I've been thinking too!
diff --git a/meta/classes/utils.bbclass b/meta/classes/utils.bbclass
index 9930a24..4f1c54f 100644
--- a/meta/classes/utils.bbclass
+++ b/meta/classes/utils.bbclass
@@ -84,6 +84,15 @@ def oe_system(d, cmd, **kwargs):
kwargs[shell] = True
return oe_popen(d, cmd, **kwargs).wait()
+def oe_package_feature_switch(feature, switch_on, switch_off,
dependencies, d):
+oeconf = d.getVar(EXTRA_OECONF, True)
+if feature in d.getVar(PACKAGE_FEATURES, True).split():
+d.setVar(EXTRA_OECONF, oeconf + + switch_on)
+depends = d.getVar(DEPENDS, True)
+d.setVar(DEPENDS, depends + + dependencies)
+else:
+d.setVar(EXTRA_OECONF, oeconf + + switch_off)
+
oe_soinstall() {
# Purpose: Install shared library file and
# create the necessary links
diff --git
a/meta/recipes-multimedia/gstreamer/gst-plugins-base_0.10.32.bb
b/meta/recipes-multimedia/gstreamer/gst-plugins-base_0.10.32.bb
index f81011f..6fc6405 100644
--- a/meta/recipes-multimedia/gstreamer/gst-plugins-base_0.10.32.bb
+++ b/meta/recipes-multimedia/gstreamer/gst-plugins-base_0.10.32.bb
@@ -6,10 +6,12 @@ LIC_FILES_CHKSUM =
file://COPYING;md5=0636e73ff0215e8d672dc4c32c317bb3 \
file://COPYING.LIB;md5=55ca817ccb7d5b5b66355690e9abc605 \
file://gst/ffmpegcolorspace/utils.c;beginline=1;endline=20;md5=9c83a200b8e597b26ca29df20fc6ecd0
-DEPENDS += virtual/libx11 alsa-lib freetype gnome-vfs liboil libogg
libvorbis libxv libtheora avahi util-linux tremor
+DEPENDS += virtual/libx11 alsa-lib freetype gnome-vfs liboil libxv
avahi util-linux tremor
RDEPENDS_${PN} += gnome-vfs-plugin-file gnome-vfs-plugin-http
gnome-vfs-plugin-ftp \
gnome-vfs-plugin-sftp
+PACKAGE_FEATURES ?= ogg vorbis theora
+
SRC_URI += file://gst-plugins-base-tremor.patch
SRC_URI[md5sum] = 2920af2b3162f3d9fbaa7fabc8ed4d38
@@ -21,6 +23,12 @@ inherit gettext
EXTRA_OECONF += --disable-freetypetest --disable-pango
+python () {
+ oe_package_feature_switch(ogg, --enable-ogg, --disable-ogg,
libogg, d)
+ oe_package_feature_switch(vorbis, --enable-vorbis,
--disable-vorbis, libvorbis, d)
+ oe_package_feature_switch(theora, --enable-theora,
--disable-theora, libtheora, d)
+}
+
do_configure_prepend() {
# This m4 file contains nastiness which conflicts with libtool 2.2.2
rm -f ${S}/m4/lib-link.m4
Then in your layer, you could configure which plugins gstreamer should
be built with like this:
PACKAGE_FEATURES_pn-gst-plugins-base = ogg theora
Or just filter out the package features that you don't want.
With a little extra work, it would also be possible to check the list of
package features a distro layer requests against those the recipe
actually implements. Then we could get an early warning when we pull
oe-core and a recipe has stopped implementing a feature.
How about something like the syntax for the recipe:
PACKAGECONFIG[ogg] = --enable-ogg, --disable-ogg, libogg
PACKAGECONFIG[vorbis] = --enable-vorbis, --disable-vorbis, libvorbis
PACKAGECONFIG[theora] = --enable-theora, --disable-theora, libtheora
and then in base.bbclass we can simply:
for flag in (d.getVarFlags(PACKAGECONFIG) or {}):
manipulate DEPENDS/EXTRA_OECONF
I'm also strongly tempted to tie this into the DISTRO_FEATURES variable
instead of individual PACKAGE_FEATURES variables to make it clear how
this is intended to be used.
If we do this, we are going to need to exercise some measure of control
as someone is going to want an enable/disable option for every config
option for every package. How do we decide which make sense and which
don't?
Note that the more options you have, the more combinations there are to
test and the less testing the system likely gets. I would therefore like
to see some kind of natural pressure to only add very useful
DISTRO_FEATURES. Maybe a criteria like it
Re: [OE-core] [PATCH] Add support for BAD_RECOMMENDATIONS to rootfs_ipk
On Fri, 2011-07-01 at 10:06 +0100, Chris Elston wrote:
+ STATUS=${IMAGE_ROOTFS}/var/lib/opkg/status
Please make that use ${opkglibdir} like the rest of the class does.
Otherwise this patch looks pretty good to me.
p.
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] Proposal: recipe feature switches
2011/7/1 Koen Kooi k...@dominion.thruhere.net Op 1 jul 2011, om 10:55 heeft Frans Meulenbroeks het volgende geschreven: Good idea. Personally I'd like to also bring footprint into the equation. If a feature drags in lots of additional packages, it is interesting to make it configurable. My favourite example: bluez dragging in all kind of rendering stuff (through DEPENDS) even though the hardware functionality might not be there (e.g. you have BT but not audio). Which is a great example, since that doesn't impact footprint at all, it's an alsa *plugin* that will get produced. bluez.inc:DEPENDS = gstreamer gst-plugins-base dbus glib-2.0 I don't think gstreamer is really needed or desired if you e.g. just want to do some tethering over bluetooth, or in my case, connect to a BT HID, and they do contribute to both the build time and the footprint. Frans. ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] Proposal: recipe feature switches
Oh by the way, and the message you might be see saying: This message may not have been sent by: fransmeulenbro...@gmail.com Learn more Report phishing This is really google not having their stuff properly configured. I'm sending email from their web client (https://mail.google.com/) And yes, it is me :-) Frans ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] cairo: Clean up packaging and fix warnings
On Fri, 2011-07-01 at 10:15 +0100, Richard Purdie wrote:
+PACKAGES =+ libcairo-gobject2 libcairo-script-interpreter2 cairo-perf-utils
I guess those can/should just be libcairo-gobject and
libcairo-script-interpreter now as well.
SUMMARY_libcairo2 = The Cairo 2D vector graphics library
DESCRIPTION_libcairo2 = Cairo is a multi-platform library providing
anti-aliased \
Presumably those also want changing to ${PN} or some such.
p.
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] PRIORITY
We had some discussion of this a few weeks ago but I'm not sure it ever reached a firm conclusion. Is everyone agreed that the PRIORITY variable does not serve any useful purpose in oe-core and can/should be removed from the recipes? p. ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] Proposal: recipe feature switches
Op 1 jul 2011, om 11:26 heeft Frans Meulenbroeks het volgende geschreven: 2011/7/1 Koen Kooi k...@dominion.thruhere.net Op 1 jul 2011, om 10:55 heeft Frans Meulenbroeks het volgende geschreven: Good idea. Personally I'd like to also bring footprint into the equation. If a feature drags in lots of additional packages, it is interesting to make it configurable. My favourite example: bluez dragging in all kind of rendering stuff (through DEPENDS) even though the hardware functionality might not be there (e.g. you have BT but not audio). Which is a great example, since that doesn't impact footprint at all, it's an alsa *plugin* that will get produced. bluez.inc:DEPENDS = gstreamer gst-plugins-base dbus glib-2.0 I don't think gstreamer is really needed or desired if you e.g. just want to do some tethering over bluetooth, or in my case, connect to a BT HID, and they do contribute to both the build time and the footprint. Again, a plugin, so no footprint issues. ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/2] uclibc: Add support for execvpe and update scheduler functions
On Thu, 2011-06-30 at 22:24 -0700, Khem Raj wrote: Enable utmpx These changes are required for systemd to work Can we make those be DISTRO_LIBC_FEATURES? p. ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 0/1] busybox: bump PR to enable largefile support
The following changes since commit 4d60d32a60ae0fae1002b27cd7d20c28532f4932: poky.conf: add largefile support into DISTRO_FEATURES (2011-07-01 17:35:26 +0800) Dexuan Cui (1): busybox: bump PR to enable largefile support are available in the git repository at: git://git.pokylinux.org/poky-contrib dcui/mkswap http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=dcui/mkswap meta/recipes-core/busybox/busybox_1.18.4.bb |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) -- 1.7.6 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/1] busybox: bump PR to enable largefile support
[YOCTO #1205 ]
In the previous commit we enable largefile setting in
meta-yocto/conf/distro/poky.conf, so we need to re-build busybox to
actually enable it.
Signed-off-by: Dexuan Cui dexuan@intel.com
---
meta/recipes-core/busybox/busybox_1.18.4.bb |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/meta/recipes-core/busybox/busybox_1.18.4.bb
b/meta/recipes-core/busybox/busybox_1.18.4.bb
index cb41ac6..5883cc6 100644
--- a/meta/recipes-core/busybox/busybox_1.18.4.bb
+++ b/meta/recipes-core/busybox/busybox_1.18.4.bb
@@ -1,5 +1,5 @@
require busybox.inc
-PR = r4
+PR = r5
SRC_URI = http://www.busybox.net/downloads/busybox-${PV}.tar.bz2;name=tarball
\
file://udhcpscript.patch \
--
1.7.6
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 0/1] busybox: bump PR to enable largefile support
Cui, Dexuan wrote: The following changes since commit 4d60d32a60ae0fae1002b27cd7d20c28532f4932: poky.conf: add largefile support into DISTRO_FEATURES (2011-07-01 17:35:26 +0800) Dexuan Cui (1): busybox: bump PR to enable largefile support are available in the git repository at: git://git.pokylinux.org/poky-contrib dcui/mkswap http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=dcui/mkswap meta/recipes-core/busybox/busybox_1.18.4.bb |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) BTW: please see my first commit in p...@yoctoproject.org. Thanks, -- Dexuan ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/1] busybox: bump PR to enable largefile support
On Fri, 2011-07-01 at 17:53 +0800, Dexuan Cui wrote: In the previous commit we enable largefile setting in meta-yocto/conf/distro/poky.conf, so we need to re-build busybox to actually enable it. I guess this would be a good case for using something like OE .dev's DISTRO_PR. It would be a bit sad if we end up having to bump PRs all over the place in oe-core whenever some random layer changes its DISTRO_FEATURES or whatever. Also, just on a stylistic issue, it's a bit confusing to talk about the previous commit if the commit in question was to a different file and in a different repo. If you want to refer to a specific commit it's best to mention the actual hash and, if necessary, the repo where it can be found. p. ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH] gettext: fix ERROR: QA Issue: gettext rdepends on gettext-dev
This was fixed in 2008 already, see
http://dominion.thruhere.net/koen/cms/the-testlab-strikes-again but regressed
during the 0.16.x - 0.18.x update. Strangely enough the comment was kept.
Signed-off-by: Koen Kooi k...@dominion.thruhere.net
---
meta/recipes-core/gettext/gettext_0.18.1.1.bb |8 +++-
1 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/meta/recipes-core/gettext/gettext_0.18.1.1.bb
b/meta/recipes-core/gettext/gettext_0.18.1.1.bb
index b64fbdb..323346f 100644
--- a/meta/recipes-core/gettext/gettext_0.18.1.1.bb
+++ b/meta/recipes-core/gettext/gettext_0.18.1.1.bb
@@ -5,7 +5,8 @@ SECTION = libs
LICENSE = GPLv3
LIC_FILES_CHKSUM = file://COPYING;md5=d32239bcb673463ab874e80d47fae504
-PR = r0
+PR = r1
+
DEPENDS = gettext-native virtual/libiconv ncurses expat git-native
DEPENDS_virtclass-native = git-native
PROVIDES = virtual/libintl virtual/gettext
@@ -50,6 +51,11 @@ acpaths = '-I ${S}/gettext-runtime/m4 \
# 1300KiB /ep93xx/uclibc-dev_0.9.29-r8_ep93xx.ipk
# 140 KiB /armv4t/gettext-dev_0.14.1-r6_armv4t.ipk
# 4 KiB /ep93xx/libgcc-s-dev_4.2.2-r2_ep93xx.ipk
+
+PACKAGES =+ libgettextlib libgettextsrc
+FILES_libgettextlib = ${libdir}/libgettextlib-*.so*
+FILES_libgettextsrc = ${libdir}/libgettextsrc-*.so*
+
PACKAGES =+ gettext-runtime gettext-runtime-dev gettext-runtime-doc
FILES_gettext-runtime = ${bindir}/gettext \
--
1.6.6.1
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] PRIORITY
Op 1 jul 2011, om 11:41 heeft Phil Blundell het volgende geschreven: We had some discussion of this a few weeks ago but I'm not sure it ever reached a firm conclusion. Is everyone agreed that the PRIORITY variable does not serve any useful purpose in oe-core and can/should be removed from the recipes? I have no use for that field, so removing it would be fine by me. regards, Koen ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] PRIORITY
On Fri, 2011-07-01 at 10:41 +0100, Phil Blundell wrote: We had some discussion of this a few weeks ago but I'm not sure it ever reached a firm conclusion. Is everyone agreed that the PRIORITY variable does not serve any useful purpose in oe-core and can/should be removed from the recipes? I think that was the conclusion, yes. I'll take a patch (or a commandline I guess). Cheers, Richard ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] Proposal: recipe feature switches
2011/7/1 Koen Kooi k...@dominion.thruhere.net Op 1 jul 2011, om 11:26 heeft Frans Meulenbroeks het volgende geschreven: 2011/7/1 Koen Kooi k...@dominion.thruhere.net Op 1 jul 2011, om 10:55 heeft Frans Meulenbroeks het volgende geschreven: Good idea. Personally I'd like to also bring footprint into the equation. If a feature drags in lots of additional packages, it is interesting to make it configurable. My favourite example: bluez dragging in all kind of rendering stuff (through DEPENDS) even though the hardware functionality might not be there (e.g. you have BT but not audio). Which is a great example, since that doesn't impact footprint at all, it's an alsa *plugin* that will get produced. bluez.inc:DEPENDS = gstreamer gst-plugins-base dbus glib-2.0 I don't think gstreamer is really needed or desired if you e.g. just want to do some tethering over bluetooth, or in my case, connect to a BT HID, and they do contribute to both the build time and the footprint. Again, a plugin, so no footprint issues. Well, as far as I know if it is in DEPENDS it will implicitly end up in RDEPENDS and will become part of the image that contains bluez, unless special precautions are taken, so it seems to me the image will grow as plugins do consume space. Anyway, my current project does not use or need bluez and I use a hand crafted image picking only the things that I need so haven't really been bitten by this recently. Frans ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] PRIORITY
On Fri, 2011-07-01 at 11:15 +0100, Richard Purdie wrote: On Fri, 2011-07-01 at 10:41 +0100, Phil Blundell wrote: We had some discussion of this a few weeks ago but I'm not sure it ever reached a firm conclusion. Is everyone agreed that the PRIORITY variable does not serve any useful purpose in oe-core and can/should be removed from the recipes? I think that was the conclusion, yes. I'll take a patch (or a commandline I guess). I did: $ find . -regex .*\.\(bb\|inc\)$ | xargs sed -i '/^PRIORITY = .*$/d' which seemed to produce the desired results. I can send a patch if you like but it would be somewhat large and fairly uninteresting. p. ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] Proposal: recipe feature switches
On Fri, 2011-07-01 at 12:19 +0200, Frans Meulenbroeks wrote: Well, as far as I know if it is in DEPENDS it will implicitly end up in RDEPENDS No, you've got it backwards. Items appearing in RDEPENDS are (to a first approximation) treated as if they are also in DEPENDS, but not the converse. p. ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] Proposal: recipe feature switches
I'm proposing something along the lines of the following:
This is actually along the lines of what I've been thinking too!
Cool, I'm glad I'm not alone on this one :)
How about something like the syntax for the recipe:
PACKAGECONFIG[ogg] = --enable-ogg, --disable-ogg, libogg
PACKAGECONFIG[vorbis] = --enable-vorbis, --disable-vorbis, libvorbis
PACKAGECONFIG[theora] = --enable-theora, --disable-theora, libtheora
and then in base.bbclass we can simply:
for flag in (d.getVarFlags(PACKAGECONFIG) or {}):
manipulate DEPENDS/EXTRA_OECONF
This is much neater than having to have an anonymous function in the
recipe to call oe_package_feature_switch.
I'm also strongly tempted to tie this into the DISTRO_FEATURES variable
instead of individual PACKAGE_FEATURES variables to make it clear how
this is intended to be used.
I'd imagined that there were some cases which weren't covered by things
implemented as DISTRO_FEATURES. To stick with the gstreamer example -
it's possible that the distribution might have a feature, but you don't
want gstreamer plugin support for that feature. For example if the
distro needs 'theora', but you don't want the gstreamer theora plugin
building. When you're trying to slim your embedded platform down, these
things can really make a difference. It makes sense to me to provide
consistent and intuitive ways to do this, otherwise people building
platforms on oe-core end up with fragile hacks in their own layers that
break when you pull a later oe-core.
Some worthwhile configuration can't be expressed in terms of high-level
distro features (i.e.: usb, bluetooth, alsa etc...). What about I want
SSL support, but NOT in library foo. That case can't be covered by
distro feature 'ssl'.
If we do this, we are going to need to exercise some measure of control
as someone is going to want an enable/disable option for every config
option for every package. How do we decide which make sense and which
don't?
How could we tell what oe users are likely to want to configure?
Note that the more options you have, the more combinations there are to
test and the less testing the system likely gets. I would therefore like
to see some kind of natural pressure to only add very useful
DISTRO_FEATURES. Maybe a criteria like it affecting 5 or more recipes?
Agreed - this is where the default set of package features comes in. If
you're not using the default set of features specified by oe-core, then
you're on your own (similar to using a tainted kernel). This doesn't
seem like a reason to prevent configuration.
Embedded developers are going to need to configure packages for their
own application, if we provide an interface to do it, then that has to
be better than everyone inventing their own methods. It would even be
possible to implement something which detects that a layer is adding
non-standard package config, and warn about it (perhaps in the sanity
check?).
Cheers,
Chris.
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] Proposal: recipe feature switches
On Fri, 2011-07-01 at 12:53 +0200, Andrea Adami wrote: Now, the detractors have argued that those flags would be a nightmare for people packaging feeds, with no way for the package manager to detect those different recipes with the same name. That does indeed come up frequently but I think this objection is misplaced. The people building the feeds just need to make sure that their particular DISTRO is using a consistent set of flags and refrain from changing them capriciously in places like local.conf. Or, to look at it from another perspective, there are already plenty of ways in which you can generate two .ipk files with the same name but different/incompatible contents by changing the contents of your configuration files. (For example, a DISTRO can already clobber EXTRA_OECONF_pn-foo in any way that it wants by using an override.) It's not at all obvious that introducing per-recipe USE flags would make things any worse in that respect. I think Chris's proposal is basically a good one. In one sense it's just syntactic sugar, since (as above) it doesn't actually allow you to do anything that you couldn't already achieve by other means, but it certainly makes it neater. p. ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] It's broken, please revert. Re: [PATCH 0/4 V4] Share gcc work directories
On Fri, 2011-07-01 at 11:08 +0200, Koen Kooi wrote: Op 1 jul 2011, om 10:10 heeft Richard Purdie het volgende geschreven: On Fri, 2011-07-01 at 09:15 +0200, Koen Kooi wrote: Op 1 jul 2011, om 01:26 heeft Saul Wold het volgende geschreven: Testing patches is not the sole responsibility of myself and Saul. This gcc patchset was on the mailing list for a considerable time and has been tested in a variety of ways. Various breakage was identified found and those breakages were fixed. The fact there looks to be some incremental build issue with rm_work is unfortunate and likely easy to fix so I think this request is a little out of proportion. If someone had reported the problem before it merged it would have waited until it was fixed before merging. They will therefore merge and I'm happy with them but it will be a few more days before that happens. I was under the impression that I still had a few more days to test them now that the eglibc problems have been solved. I don't think you can blame people for not testing gcc when eglibc was still blowing up in their faces. I balanced a few different factors in the timing. Merging code like this on a Friday with 4th July and the US going on holiday next week didn't seem like a better time to do this so I went for something slightly earlier. I was working on the assumption we had the eglibc issues resolved. I find it ironic you're one of the people asking to turn the autobuilder red, make warnings fatal and break things for everyone as 'its the only way to get people to look at and fix them; but on the other hand you're unhappy if testing of patches doesn't happen on every single combination of usages and something does break :/. I was actually planning to test them today, now that eglibc works again. Ok, sorry I wasn't aware of that. Cheers, Richard ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v4 7/8] task-base: remove modutils reference.
* Anders Darander Anders Darander and...@chargestorm.se [07/01/11 01:52 PM]: from task-base.bb? Should that part just be new, general RRECOMMENDS = \ kernel-module-nls-utf8 \ I should have written: RRECOMMENDS_task-base = \ kernel-module-nls-utf8 \ Regards, Anders -- Anders Darander ChargeStorm AB ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] PRIORITY
2011/7/1 Phil Blundell p...@pbcl.net On Fri, 2011-07-01 at 11:15 +0100, Richard Purdie wrote: On Fri, 2011-07-01 at 10:41 +0100, Phil Blundell wrote: We had some discussion of this a few weeks ago but I'm not sure it ever reached a firm conclusion. Is everyone agreed that the PRIORITY variable does not serve any useful purpose in oe-core and can/should be removed from the recipes? I think that was the conclusion, yes. I'll take a patch (or a commandline I guess). I did: $ find . -regex .*\.\(bb\|inc\)$ | xargs sed -i '/^PRIORITY = .*$/d' which seemed to produce the desired results. I can send a patch if you like but it would be somewhat large and fairly uninteresting. I'd suggest a regex that matches for any whitespace in order also to catch things like: ./libgpevtype/libgpevtype_0.50.bb:PRIORITY= optional Have fun! Frans ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v4 7/8] task-base: remove modutils reference.
Op 1 jul 2011, om 13:52 heeft Anders Darander het volgende geschreven: * Koen Kooi Koen Kooi k...@dominion.thruhere.net [07/01/11 09:20 AM]: Op 1 jul 2011, om 09:06 heeft Anders Darander het volgende geschreven: Also remove the other kernel24 references. Make everything dependent on kernel26 default. Since there will be only one of each, can we just completely scrap there variables and put the items directly in the tasks? Sure, we could do that. One question though, how should I treat RRECOMMENDS_task-base-kernel26 = \ kernel-module-nls-utf8 \ kernel-module-input \ kernel-module-uinput \ kernel-module-rtc-dev \ kernel-module-rtc-proc \ kernel-module-rtc-sysfs \ kernel-module-rtc-sa1100 \ kernel-module-unix from task-base.bb? Should that part just be new, general RRECOMMENDS = \ kernel-module-nls-utf8 \ kernel-module-input \ kernel-module-uinput \ kernel-module-rtc-dev \ kernel-module-rtc-proc \ kernel-module-rtc-sysfs \ kernel-module-rtc-sa1100 \ kernel-module-unix? I guess that's the right thing, and I'll create a new pull request with that merged into the last patch. The above is what I had in mind, but I do question the need for rtc-sa1100 in task-base, that should be in the machine.conf as MACHINE_EXTRA_RRECOMMENDS or so. But that is outside the scope of this patch I guess. regards, Koen ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH v5 0/8] Linux 3.0 build support
v5: - task-base.bb: Move the RDEPENDS- and RRECOMMENDS_task-base-kernel26
to *_task-base.
v4: Removed the RFC in patch subject.
- Merge the patches 2 and 4 from v3.
- Bump PR in patch 2.
- Delete the ignore*.patch from module-init-tools. In v2, the
patch was just disabled.
v3: - task-base.bb: fix a problem that *pcmia26 couldn't be found.
v2: Probably some more patches could be squashed together. There might also
be more places that should be addressed in these patches.
- Whitespace fixes
- Updated module-init-tools to 3.16. I'm not applying the ignore*.patch
(it didn't apply).
- Do not provide virtual/*/depmod-2.6; just provide virtual/*/depmod.
- Do only install as depmod.
- Rearrange the order of some patches.
- Added patches to clean up (partly) task-base, distro_tracking_fields.
A few of the patches might be ready to pull, but the majority will need
to be revised.
===
This work is unfinished and incomplete...
It is published in its current form both to get feedback, but also to aid
anyone else who is working on 3.0-support. If some of the patches are found to
be OK, it's fine to cherrypick them.
The kernel-related classes has been modified to build a 3.0 kernel. The
patches has been simplified by removing support for the 2.4-series. (The
latter was suggested in an older mail thread:
http://www.mail-archive.com/openembedded-core@lists.openembedded.org/msg02682.html
).
The patches has been tested on linux-yocto_2.6.37 and a hacked version using
the linux-yocto-dev repository (using a 3.0-rcX). The latest versions has only
been built for qemuarm, prior iterations has also been built for qemux86.
Finally, no work has been done on the libc-linux-headers classes and recipes.
/Anders
The following changes since commit 40ecaf6a59ba61e72d29d7e677197ef37c998408:
uclibc: Add default uClibc.machine files (2011-07-01 00:40:10 +0100)
are available in the git repository at:
git://github.com/darander/oe-core kernel-3.0
https://github.com/darander/oe-core/tree/kernel-3.0
Anders Darander (8):
Remove support for building 2.4 kernels
image¡kernel.bblass module-init-tools: do not use depmod-2.6
modules-init-tools(-cross): update to 3.16
kernel.bblass: remove get_kernelmajorversion
modutils-initscripts: move recipe prior to modutils removal
modutils: remove modutils
task-base: remove modutils reference.
distro_tracking_fields: remove modutils.
meta/classes/image.bbclass |2 +-
meta/classes/kernel.bbclass| 22 ++
meta/classes/linux-kernel-base.bbclass |8 --
meta/classes/module-base.bbclass |2 +-
.../conf/distro/include/distro_tracking_fields.inc |8 +--
meta/recipes-core/tasks/task-base.bb | 49 +++---
.../{modutils = module-init-tools}/files/PD.patch |0
.../files/ignore_arch_directory.patch | 30 --
.../files/modutils.sh |0
.../module-init-tools-cross_3.12.bb| 12 ---
.../module-init-tools-cross_3.16.bb|8 ++
.../module-init-tools/module-init-tools.inc|1 -
...nit-tools_3.12.bb = module-init-tools_3.16.bb} |6 +-
.../modutils-initscripts.bb|0
meta/recipes-kernel/modutils/files/armeb.patch | 16
meta/recipes-kernel/modutils/files/configure.patch | 34 ---
meta/recipes-kernel/modutils/files/gcc4.patch | 93
meta/recipes-kernel/modutils/files/lex.l.diff | 35
.../modutils/files/modutils-notest.patch | 16
.../modutils/files/program_prefix.patch| 71 ---
.../recipes-kernel/modutils/modutils-collateral.bb | 21 -
.../modutils/modutils-cross/module.h.diff | 35
.../modutils/modutils-cross_2.4.27.bb | 20
meta/recipes-kernel/modutils/modutils_2.4.27.bb| 93
24 files changed, 35 insertions(+), 547 deletions(-)
rename meta/recipes-kernel/{modutils = module-init-tools}/files/PD.patch
(100%)
delete mode 100644
meta/recipes-kernel/module-init-tools/files/ignore_arch_directory.patch
rename meta/recipes-kernel/{modutils = module-init-tools}/files/modutils.sh
(100%)
delete mode 100644
meta/recipes-kernel/module-init-tools/module-init-tools-cross_3.12.bb
create mode 100644
meta/recipes-kernel/module-init-tools/module-init-tools-cross_3.16.bb
rename meta/recipes-kernel/module-init-tools/{module-init-tools_3.12.bb =
module-init-tools_3.16.bb} (87%)
rename meta/recipes-kernel/{modutils =
module-init-tools}/modutils-initscripts.bb (100%)
delete mode 100644 meta/recipes-kernel/modutils/files/armeb.patch
delete mode 100644 meta/recipes-kernel/modutils/files/configure.patch
delete mode 100644 meta/recipes-kernel/modutils/files/gcc4.patch
delete mode 100644
[OE-core] [PATCH v5 2/8] image¡kernel.bblass module-init-tools: do not use depmod-2.6
Change to only depend on virtual/*/depmod.
Change all calls to only use depmod.
Do not install depmod as depmod-2.6
Bump PR in module-init-tools-cross.
Signed-off-by: Anders Darander and...@chargestorm.se
---
meta/classes/image.bbclass |2 +-
meta/classes/kernel.bbclass| 10 --
.../module-init-tools-cross_3.12.bb|6 +-
3 files changed, 6 insertions(+), 12 deletions(-)
diff --git a/meta/classes/image.bbclass b/meta/classes/image.bbclass
index e77ec42..1768a0b 100644
--- a/meta/classes/image.bbclass
+++ b/meta/classes/image.bbclass
@@ -116,7 +116,7 @@ fakeroot do_rootfs () {
KERNEL_VERSION=`cat ${STAGING_KERNEL_DIR}/kernel-abiversion`
mkdir -p ${IMAGE_ROOTFS}/lib/modules/$KERNEL_VERSION
- ${TARGET_SYS}-depmod-2.6 -a -b ${IMAGE_ROOTFS} -F
${STAGING_KERNEL_DIR}/System.map-$KERNEL_VERSION $KERNEL_VERSION
+ ${TARGET_SYS}-depmod -a -b ${IMAGE_ROOTFS} -F
${STAGING_KERNEL_DIR}/System.map-$KERNEL_VERSION $KERNEL_VERSION
fi
${IMAGE_PREPROCESS_COMMAND}
diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index 25f4855..c6fb465 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -1,7 +1,7 @@
inherit linux-kernel-base module_strip
PROVIDES += virtual/kernel
-DEPENDS += virtual/${TARGET_PREFIX}gcc
virtual/${TARGET_PREFIX}depmod-${@get_kernelmajorversion('${PV}')}
virtual/${TARGET_PREFIX}gcc${KERNEL_CCSUFFIX} update-modules
+DEPENDS += virtual/${TARGET_PREFIX}gcc virtual/${TARGET_PREFIX}depmod
virtual/${TARGET_PREFIX}gcc${KERNEL_CCSUFFIX} update-modules
# we include gcc above, we dont need virtual/libc
INHIBIT_DEFAULT_DEPS = 1
@@ -53,7 +53,6 @@ KERNEL_IMAGEDEST = boot
export CMDLINE_CONSOLE = console=${@bb.data.getVar(KERNEL_CONSOLE,d,1) or
ttyS0}
KERNEL_VERSION = ${@get_kernelversion('${B}')}
-KERNEL_MAJOR_VERSION = ${@get_kernelmajorversion('${KERNEL_VERSION}')}
KERNEL_LOCALVERSION ?=
@@ -232,7 +231,7 @@ if [ ! -e $D/lib/modules/${KERNEL_VERSION} ]; then
mkdir -p $D/lib/modules/${KERNEL_VERSION}
fi
if [ -n $D ]; then
- ${HOST_PREFIX}depmod-${KERNEL_MAJOR_VERSION} -A -b $D -F
${STAGING_KERNEL_DIR}/System.map-${KERNEL_VERSION} ${KERNEL_VERSION}
+ ${HOST_PREFIX}depmod -A -b $D -F
${STAGING_KERNEL_DIR}/System.map-${KERNEL_VERSION} ${KERNEL_VERSION}
else
depmod -a
fi
@@ -240,7 +239,7 @@ fi
pkg_postinst_modules () {
if [ -n $D ]; then
- ${HOST_PREFIX}depmod-${KERNEL_MAJOR_VERSION} -A -b $D -F
${STAGING_KERNEL_DIR}/System.map-${KERNEL_VERSION} ${KERNEL_VERSION}
+ ${HOST_PREFIX}depmod -A -b $D -F
${STAGING_KERNEL_DIR}/System.map-${KERNEL_VERSION} ${KERNEL_VERSION}
else
depmod -a
update-modules || true
@@ -313,9 +312,8 @@ python populate_packages_prepend () {
kernelver_stripped = m.group(1)
path = bb.data.getVar(PATH, d, 1)
host_prefix = bb.data.getVar(HOST_PREFIX, d, 1) or
- major_version = bb.data.getVar('KERNEL_MAJOR_VERSION', d, 1)
- cmd = PATH=\%s\ %sdepmod-%s -n -a -r -b %s -F
%s/boot/System.map-%s %s % (path, host_prefix, major_version, dvar, dvar,
kernelver, kernelver_stripped)
+ cmd = PATH=\%s\ %sdepmod -n -a -r -b %s -F
%s/boot/System.map-%s %s % (path, host_prefix, dvar, dvar, kernelver,
kernelver_stripped)
f = os.popen(cmd, 'r')
deps = {}
diff --git
a/meta/recipes-kernel/module-init-tools/module-init-tools-cross_3.12.bb
b/meta/recipes-kernel/module-init-tools/module-init-tools-cross_3.12.bb
index 08bf1a9..5cbf9c5 100644
--- a/meta/recipes-kernel/module-init-tools/module-init-tools-cross_3.12.bb
+++ b/meta/recipes-kernel/module-init-tools/module-init-tools-cross_3.12.bb
@@ -1,12 +1,8 @@
require module-init-tools.inc
-PR = r1
+PR = r2
inherit cross
PROVIDES += virtual/${TARGET_PREFIX}depmod virtual/${TARGET_PREFIX}depmod-2.6
SRC_URI += file://no-static-binaries.patch
EXTRA_OECONF_append = --program-prefix=${TARGET_PREFIX}
-
-do_install_append () {
-mv ${D}${bindir}/${TARGET_PREFIX}depmod
${D}${bindir}/${TARGET_PREFIX}depmod-2.6
-}
--
1.7.4.1
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH v5 1/8] Remove support for building 2.4 kernels
Signed-off-by: Anders Darander and...@chargestorm.se
---
meta/classes/kernel.bbclass | 12 ++--
meta/classes/module-base.bbclass |2 +-
2 files changed, 3 insertions(+), 11 deletions(-)
diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index f282a57..25f4855 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -73,9 +73,6 @@ KERNEL_ALT_IMAGETYPE ??=
kernel_do_compile() {
unset CFLAGS CPPFLAGS CXXFLAGS LDFLAGS MACHINE
oe_runmake include/linux/version.h CC=${KERNEL_CC} LD=${KERNEL_LD}
- if [ ${KERNEL_MAJOR_VERSION} != 2.6 ]; then
- oe_runmake dep CC=${KERNEL_CC} LD=${KERNEL_LD}
- fi
oe_runmake ${KERNEL_IMAGETYPE} ${KERNEL_ALT_IMAGETYPE}
CC=${KERNEL_CC} LD=${KERNEL_LD}
}
@@ -111,9 +108,7 @@ kernel_do_install() {
install -m 0644 vmlinux ${D}/boot/vmlinux-${KERNEL_VERSION}
[ -e Module.symvers ] install -m 0644 Module.symvers
${D}/boot/Module.symvers-${KERNEL_VERSION}
install -d ${D}/etc/modutils
- if [ ${KERNEL_MAJOR_VERSION} = 2.6 ]; then
- install -d ${D}/etc/modprobe.d
- fi
+ install -d ${D}/etc/modprobe.d
#
# Support for external module building - create a minimal copy of the
@@ -397,10 +392,7 @@ python populate_packages_prepend () {
# Write out any modconf fragment
modconf = bb.data.getVar('module_conf_%s' % basename, d, 1)
if modconf:
- if bb.data.getVar(KERNEL_MAJOR_VERSION, d, 1) ==
2.6:
- name = '%s/etc/modprobe.d/%s.conf' % (dvar,
basename)
- else:
- name = '%s/etc/modutils/%s.conf' % (dvar,
basename)
+ name = '%s/etc/modprobe.d/%s.conf' % (dvar, basename)
f = open(name, 'w')
f.write(%s\n % modconf)
f.close()
diff --git a/meta/classes/module-base.bbclass b/meta/classes/module-base.bbclass
index c98bace..a7cf233 100644
--- a/meta/classes/module-base.bbclass
+++ b/meta/classes/module-base.bbclass
@@ -7,7 +7,7 @@ export CROSS_COMPILE = ${TARGET_PREFIX}
export KERNEL_VERSION =
${@base_read_file('${STAGING_KERNEL_DIR}/kernel-abiversion')}
export KERNEL_SOURCE =
${@base_read_file('${STAGING_KERNEL_DIR}/kernel-source')}
-KERNEL_OBJECT_SUFFIX = ${@[.o,
.ko][base_read_file('${STAGING_KERNEL_DIR}/kernel-abiversion') 2.6.0]}
+KERNEL_OBJECT_SUFFIX = .ko
KERNEL_CCSUFFIX = ${@base_read_file('${STAGING_KERNEL_DIR}/kernel-ccsuffix')}
KERNEL_LDSUFFIX = ${@base_read_file('${STAGING_KERNEL_DIR}/kernel-ldsuffix')}
KERNEL_ARSUFFIX = ${@base_read_file('${STAGING_KERNEL_DIR}/kernel-arsuffix')}
--
1.7.4.1
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH v5 5/8] modutils-initscripts: move recipe prior to modutils removal
Signed-off-by: Anders Darander and...@chargestorm.se
---
.../{modutils = module-init-tools}/files/PD.patch |0
.../files/modutils.sh |0
.../modutils-initscripts.bb|0
3 files changed, 0 insertions(+), 0 deletions(-)
rename meta/recipes-kernel/{modutils = module-init-tools}/files/PD.patch
(100%)
rename meta/recipes-kernel/{modutils = module-init-tools}/files/modutils.sh
(100%)
rename meta/recipes-kernel/{modutils =
module-init-tools}/modutils-initscripts.bb (100%)
diff --git a/meta/recipes-kernel/modutils/files/PD.patch
b/meta/recipes-kernel/module-init-tools/files/PD.patch
similarity index 100%
rename from meta/recipes-kernel/modutils/files/PD.patch
rename to meta/recipes-kernel/module-init-tools/files/PD.patch
diff --git a/meta/recipes-kernel/modutils/files/modutils.sh
b/meta/recipes-kernel/module-init-tools/files/modutils.sh
similarity index 100%
rename from meta/recipes-kernel/modutils/files/modutils.sh
rename to meta/recipes-kernel/module-init-tools/files/modutils.sh
diff --git a/meta/recipes-kernel/modutils/modutils-initscripts.bb
b/meta/recipes-kernel/module-init-tools/modutils-initscripts.bb
similarity index 100%
rename from meta/recipes-kernel/modutils/modutils-initscripts.bb
rename to meta/recipes-kernel/module-init-tools/modutils-initscripts.bb
--
1.7.4.1
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH v5 3/8] modules-init-tools(-cross): update to 3.16
Update to get support for Linux 3.0.
Delete the ignore_arch_directory.patch (as it does not apply to 3.16).
Signed-off-by: Anders Darander and...@chargestorm.se
---
.../files/ignore_arch_directory.patch | 30
...oss_3.12.bb = module-init-tools-cross_3.16.bb} |4 +-
.../module-init-tools/module-init-tools.inc|1 -
...nit-tools_3.12.bb = module-init-tools_3.16.bb} |6 ++--
4 files changed, 5 insertions(+), 36 deletions(-)
delete mode 100644
meta/recipes-kernel/module-init-tools/files/ignore_arch_directory.patch
rename meta/recipes-kernel/module-init-tools/{module-init-tools-cross_3.12.bb
= module-init-tools-cross_3.16.bb} (62%)
rename meta/recipes-kernel/module-init-tools/{module-init-tools_3.12.bb =
module-init-tools_3.16.bb} (87%)
diff --git
a/meta/recipes-kernel/module-init-tools/files/ignore_arch_directory.patch
b/meta/recipes-kernel/module-init-tools/files/ignore_arch_directory.patch
deleted file mode 100644
index d29957d..000
--- a/meta/recipes-kernel/module-init-tools/files/ignore_arch_directory.patch
+++ /dev/null
@@ -1,30 +0,0 @@
-# not sure the reason yet. Keep for a while and verify later.
-#
-# comments added by Kevin Tian kevin.t...@intel.com, 2010-07-21
-
-Upstream-Status: Pending
-
-diff -ruN module-init-tools-3.12.orig/modprobe.8
module-init-tools-3.12/modprobe.8
module-init-tools-3.12/modprobe.8.orig
-+++ module-init-tools-3.12/modprobe.8
-@@ -27,6 +27,7 @@
- (see \fBmodprobe.conf\fR(5)). \fBmodprobe\fR will also use module
- options specified on the kernel command line in the form of
- module\.option\.
-+All files in the \fI/etc/modprobe.d/arch/\fR directory are ignored.
- .PP
- Note that unlike in 2.4 series Linux kernels (which are not supported
- by this tool) this version of \fBmodprobe\fR does not
module-init-tools-3.12/modprobe.c.orig
-+++ module-init-tools-3.12/modprobe.c
-@@ -1052,6 +1052,10 @@
- DIR *dir;
- int ret = 0;
-
-+ /* ignore everything in this directory */
-+ if (streq(filename, /etc/modprobe.d/arch))
-+ return 1;
-+
- dir = opendir(filename);
- if (dir) {
- struct file_entry {
diff --git
a/meta/recipes-kernel/module-init-tools/module-init-tools-cross_3.12.bb
b/meta/recipes-kernel/module-init-tools/module-init-tools-cross_3.16.bb
similarity index 62%
rename from
meta/recipes-kernel/module-init-tools/module-init-tools-cross_3.12.bb
rename to meta/recipes-kernel/module-init-tools/module-init-tools-cross_3.16.bb
index 5cbf9c5..8b3458b 100644
--- a/meta/recipes-kernel/module-init-tools/module-init-tools-cross_3.12.bb
+++ b/meta/recipes-kernel/module-init-tools/module-init-tools-cross_3.16.bb
@@ -1,7 +1,7 @@
require module-init-tools.inc
-PR = r2
+PR = r0
inherit cross
-PROVIDES += virtual/${TARGET_PREFIX}depmod virtual/${TARGET_PREFIX}depmod-2.6
+PROVIDES += virtual/${TARGET_PREFIX}depmod
SRC_URI += file://no-static-binaries.patch
diff --git a/meta/recipes-kernel/module-init-tools/module-init-tools.inc
b/meta/recipes-kernel/module-init-tools/module-init-tools.inc
index 4d96d16..c290c4f 100644
--- a/meta/recipes-kernel/module-init-tools/module-init-tools.inc
+++ b/meta/recipes-kernel/module-init-tools/module-init-tools.inc
@@ -12,7 +12,6 @@ FILES_module-init-tools-depmod = ${sbindir}/depmod.26
FILES_module-init-tools-insmod-static = ${sbindir}/insmod.static
SRC_URI =
${KERNELORG_MIRROR}/linux/utils/kernel/module-init-tools/module-init-tools-${PV}.tar.bz2
\
- file://ignore_arch_directory.patch \
file://modutils_extension.patch \
file://disable_man.patch \
file://grab_module_memset.patch
diff --git a/meta/recipes-kernel/module-init-tools/module-init-tools_3.12.bb
b/meta/recipes-kernel/module-init-tools/module-init-tools_3.16.bb
similarity index 87%
rename from meta/recipes-kernel/module-init-tools/module-init-tools_3.12.bb
rename to meta/recipes-kernel/module-init-tools/module-init-tools_3.16.bb
index 3d7c287..0248b46 100644
--- a/meta/recipes-kernel/module-init-tools/module-init-tools_3.12.bb
+++ b/meta/recipes-kernel/module-init-tools/module-init-tools_3.16.bb
@@ -1,5 +1,5 @@
require module-init-tools.inc
-PR = r1
+PR = r0
# autotools set prefix to /usr, however we want them in /bin and /sbin
bindir = /bin
@@ -38,5 +38,5 @@ pkg_prerm_module-init-tools-depmod() {
update-alternatives --remove depmod /sbin/depmod.26
}
-SRC_URI[md5sum] = 8b2257ce9abef74c4a44d825d23140f3
-SRC_URI[sha256sum] =
d012ab07ea26721467a85a775f34747c1c8897e37f16bec5317d8a72ef8b4f17
+SRC_URI[md5sum] = bc44832c6e41707b8447e2847d2019f5
+SRC_URI[sha256sum] =
e1f2cdcae64a8effc25e545a5e0bdaf312f816ebbcd0916e4e87450755fab64b
--
1.7.4.1
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] Add support for remote layering.
Hi Jeremy Have looked at this further and I really think this needs to be a separate utility, but one still written in python using bitbake's infrastructure (like bitbake-layers). The advantages of this approach: 1) Avoids reworking bitbake's initialisation and avoids possible re-execution. A separate utility can take advantage of a full parse and utilise all of the user's configuration. 2) Fetching/updating layers should be (able to be) a conscious action rather than something that happens implicitly as part of the build process I'm trying to put something together that does this at the moment, with a view to there being components that allow integration with the content tools you posted earlier. Will keep you posted. Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] It's broken, please revert. Re: [PATCH 0/4 V4] Share gcc work directories
On Jul 1, 2011, at 4:00 AM, Koen Kooi k...@dominion.thruhere.net wrote:
Op 1 jul 2011, om 10:32 heeft Richard Purdie het volgende geschreven:
On Fri, 2011-07-01 at 09:15 +0200, Koen Kooi wrote:
incremental build with rm_work turned on:
ERROR: Function 'do_configure' failed (see
/OE/tentacle/build/tmp-angstrom_2010_x-eglibc/work/armv7a-angstrom-linux-gnueabi/gcc-cross-initial-4.5-r37.0+svnr175127/temp/log.do_configure.27092
for further information)
ERROR: Logfile of failure stored in:
/OE/tentacle/build/tmp-angstrom_2010_x-eglibc/work/armv7a-angstrom-linux-gnueabi/gcc-cross-initial-4.5-r37.0+svnr175127/temp/log.do_configure.27092
Log data follows:
| + cd
/OE/tentacle/build/tmp-angstrom_2010_x-eglibc/work/armv7a-angstrom-linux-gnueabi/gcc-cross-initial-4.5-r37.0+svnr175127/gcc-4.5/build.x86_64-linux.arm-angstrom-linux-gnueabi
| + do_configure
| + sed -i
'/OE/tentacle/build/tmp-angstrom_2010_x-eglibc/work/armv7a-angstrom-linux-gnueabi/gcc-cross-initial-4.5-r37.0+svnr175127/gcc-4_5-branch/gcc/config/*/linux*.h'
-e 's#\(GLIBC_DYNAMIC_LINKER[^ ]*\)\( */lib.*\)#\1 SYSTEMLIBS_DIR\2#'
| sed: can't read
/OE/tentacle/build/tmp-angstrom_2010_x-eglibc/work/armv7a-angstrom-linux-gnueabi/gcc-cross-initial-4.5-r37.0+svnr175127/gcc-4_5-branch/gcc/config/*/linux*.h:
No such file or directory
| ERROR: Function 'do_configure' failed (see
/OE/tentacle/build/tmp-angstrom_2010_x-eglibc/work/armv7a-angstrom-linux-gnueabi/gcc-cross-initial-4.5-r37.0+svnr175127/temp/log.do_configure.27092
for further information)
NOTE: package gcc-cross-initial-4.5-r37.0+svnr175127: task do_configure:
Failed
ERROR: Task 764
(/OE/tentacle/sources/meta-openembedded/meta-oe/recipes-devtools/gcc/gcc-cross-initial_4.5.bb,
do_configure) failed with exit code '1'
Can this patchset get reverted please and reapplied when it actually has
been tested to work?
I checked and everything is fine with rm_work.
Looking at this error, something is changing ${S} as there is no mention
of work-shared in the sed command yet there should be.
At a guess this is coming from:
http://git.angstrom-distribution.org/cgi-bin/cgit.cgi/meta-openembedded/tree/meta-oe/recipes-devtools/gcc/gcc-4.5.inc
where it says:
S = ${WORKDIR}/${BRANCH}
and if that is changed to
S_append = /${BRANCH}
or removed it will likely work better.
It was indeed a bug in meta-oe and the following fixed it:
https://github.com/koenkooi/meta-oe/commit/8a917caaa5506fa0f875202243658a1c2fe60c40
Additionally you would need to port the patch which mucks makefile fragment I
think
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] insane bbclass: turn fatal errors back into fatal errors
On Thu, 2011-06-30 at 17:49 +0200, Koen Kooi wrote: It's a white list, so: # 0 - non dev contains .so # 5 - .la contains installed=yes or reference to the workdir # 7 - the desktop file is not valid # 8 - .la contains reference to the workdir # 9 - LDFLAGS ignored Are warnings and # 1 - package contains a dangerous RPATH # 2 - package depends on debug package # 3 - non dbg contains .so # 4 - wrong architecture # 6 - .pc contains reference to /usr/include or workdir # 10 - Build paths in binaries # 11 - package depends on devel package Are fatal errors. The splits seems arbitrary to me, but it that's how it was last year before RP disabled all fatal errors. I guess the split does make some sense as it is, although I can't see any reason for #8 not to be in the fatal set. #5 also seems like it would belong there except that, as far as I can tell, that test doesn't actually exist in the code so it's a bit academic how the results are treated. #7 is, in the scheme of things, a relatively minor infringement (and usually an upstream bug anyway) so probably oughtn't to make a package unshippable. #9 is potentially a nuisance but in most cases doesn't cause any actual problems, so again I think it's fair for this to be a warning. Incidentally, it seems that the description for #6 is a bit wrong: it doesn't actually do any checking for /usr/include. And #3 should obviously be talking about .debug not .so. p. ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 2/6] kernel.bbclass: Ensure kernel/* internal sysroot working directory don't get packaged
From: Richard Purdie richard.pur...@linuxfoundation.org
This removes a couple of megabytes of QA warnings!
Signed-off-by: Richard Purdie richard.pur...@linuxfoundation.org
---
meta/classes/kernel.bbclass |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index f282a57..6700d0e 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -168,6 +168,12 @@ kernel_do_install() {
done
}
+PACKAGE_PREPROCESS_FUNCS += kernel_package_preprocess
+
+kernel_package_preprocess () {
+ rm -rf ${PKGD}/kernel
+}
+
sysroot_stage_all_append() {
sysroot_stage_dir ${D}/kernel ${SYSROOT_DESTDIR}/kernel
}
--
1.7.4.1
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/6] cairo: Clean up packaging and fix warnings
From: Richard Purdie richard.pur...@linuxfoundation.org
There were a number of QA errors being reported when packaging cairo. This patch
ensures the debug files go in the -dbg package, the .so development links go
into
the -dev package, .a files into -staticdev.
It also switches back to relying on debian package naming for the library name.
Since this is working correctly now the files are in the correct packages, we
can simplify the recipe and there is no change in the resulting package names
from a package feed perspective.
Signed-off-by: Richard Purdie richard.pur...@linuxfoundation.org
---
meta/recipes-graphics/cairo/cairo_1.10.2.bb | 44 +-
1 files changed, 15 insertions(+), 29 deletions(-)
diff --git a/meta/recipes-graphics/cairo/cairo_1.10.2.bb
b/meta/recipes-graphics/cairo/cairo_1.10.2.bb
index 572e1f6..d2cadd2 100644
--- a/meta/recipes-graphics/cairo/cairo_1.10.2.bb
+++ b/meta/recipes-graphics/cairo/cairo_1.10.2.bb
@@ -2,31 +2,17 @@ require cairo.inc
LIC_FILES_CHKSUM = file://COPYING;md5=e73e999e0c72b5ac9012424fa157ad77
-PR = r0
+PR = r1
SRC_URI = http://cairographics.org/releases/cairo-${PV}.tar.gz;
SRC_URI[md5sum] = f101a9e88b783337b20b2e26dfd26d5f
SRC_URI[sha256sum] =
32018c7998358eebc2ad578ff8d8559d34fc80252095f110a572ed23d989fc41
-RDEPENDS_${PN} += libcairo2 libcairo-gobject2 libcairo-script-interpreter2 \
- cairo-perf-utils
+PACKAGES =+ cairo-gobject cairo-script-interpreter cairo-perf-utils
-ALLOW_EMPTY = 1
-
-#
-# Old version (1.8.10 or below) is automatically named as libcairo2 by
-# debian_package_name_hook. To keep backword compatibility,
-# it is necessary to explicitly name the package as libcairo2 here
-#
-PACKAGES =+ libcairo2 libcairo2-dev libcairo2-dbg \
-libcairo-gobject2 \
-libcairo-script-interpreter2 \
-cairo-perf-utils \
-
-
-SUMMARY_libcairo2 = The Cairo 2D vector graphics library
-DESCRIPTION_libcairo2 = Cairo is a multi-platform library providing
anti-aliased \
+SUMMARY_${PN} = The Cairo 2D vector graphics library
+DESCRIPTION_${PN} = Cairo is a multi-platform library providing anti-aliased \
vector-based rendering for multiple target backends. Paths consist \
of line segments and cubic splines and can be rendered at any width \
with various join and cap styles. All colors may be specified with \
@@ -34,20 +20,20 @@ optional translucence (opacity/alpha) and combined using
the \
extended Porter/Duff compositing algebra as found in the X Render \
Extension.
-SUMMARY_libcairo-gobject2 = The Cairo library GObject wrapper library
-DESCRIPTION_libcairo-gobject2 = A GObject wrapper library for the Cairo API.
+SUMMARY_cairo-gobject = The Cairo library GObject wrapper library
+DESCRIPTION_cairo-gobject = A GObject wrapper library for the Cairo API.
-SUMMARY_libcairo-script-interpreter2 = The Cairo library script interpreter
-DESCRIPTION_libcairo-script-interpreter2 = The Cairo script interpreter
implements \
+SUMMARY_cairo-script-interpreter = The Cairo library script interpreter
+DESCRIPTION_cairo-script-interpreter = The Cairo script interpreter
implements \
CairoScript. CairoScript is used by tracing utilities to enable the ability \
to replay rendering.
DESCRIPTION_cairo-perf-utils = The Cairo library performance utilities
-FILES_libcairo2 = ${libdir}/libcairo.so*
-FILES_libcairo2-dev = ${includedir} ${libdir}/*.la ${libdir}/*.a \
- ${libdir}/*.o ${libdir}/pkgconfig
-FILES_libcairo2-dbg = ${libdir}/.debug ${libdir}/cairo/.debug
-FILES_libcairo-gobject2 = ${libdir}/libcairo-gobject.so*
-FILES_libcairo-script-interpreter2 =
${libdir}/libcairo-script-interpreter.so*
-FILES_cairo-perf-utils = ${bindir}/cairo-trace
${libdir}/cairo/libcairo-trace.*
+FILES_${PN} = ${libdir}/libcairo.so.*
+FILES_${PN}-dev += ${libdir}/cairo/*.la ${libdir}/cairo/*.so
+FILES_${PN}-dbg += ${libdir}/cairo/.debug
+FILES_${PN}-staticdev += ${libdir}/cairo/*.a
+FILES_cairo-gobject = ${libdir}/libcairo-gobject.so.*
+FILES_cairo-script-interpreter = ${libdir}/libcairo-script-interpreter.so.*
+FILES_cairo-perf-utils = ${bindir}/cairo-trace
${libdir}/cairo/libcairo-trace.so.*
--
1.7.4.1
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 3/6] libpcre: Fix QA warnings
From: Richard Purdie richard.pur...@linuxfoundation.org
This drops the split -dev packaging since it was broken and overcomplex. It
ensures .so
symlinks end up in the correct package.
Signed-off-by: Richard Purdie richard.pur...@linuxfoundation.org
---
meta/recipes-support/libpcre/libpcre_8.12.bb |8 ++--
1 files changed, 2 insertions(+), 6 deletions(-)
diff --git a/meta/recipes-support/libpcre/libpcre_8.12.bb
b/meta/recipes-support/libpcre/libpcre_8.12.bb
index 0301ddb..33003c5 100644
--- a/meta/recipes-support/libpcre/libpcre_8.12.bb
+++ b/meta/recipes-support/libpcre/libpcre_8.12.bb
@@ -5,7 +5,7 @@ provides a POSIX calling interface to PCRE; the regular
expressions \
themselves still follow Perl syntax and semantics. The header file for \
the POSIX-style functions is called pcreposix.h.
SECTION = devel
-PR = r0
+PR = r1
LICENSE = BSD
LIC_FILES_CHKSUM = file://LICENCE;md5=77f9b14fe707d0376d89bc162e6c54ff
SRC_URI = ${SOURCEFORGE_MIRROR}/pcre/pcre-${PV}.tar.bz2 \
@@ -45,11 +45,7 @@ do_compile () {
python populate_packages_prepend () {
pcre_libdir = bb.data.expand('${libdir}', d)
- pcre_libdir_dbg = bb.data.expand('${libdir}/.debug', d)
- do_split_packages(d, pcre_libdir, '^lib(.*)\.so$', 'lib%s-dev',
'libpcre %s development package', extra_depends='${PN}-dev', allow_links=True)
- do_split_packages(d, pcre_libdir, '^lib(.*)\.la$', 'lib%s-dev',
'libpcre %s development package', extra_depends='${PN}-dev')
- do_split_packages(d, pcre_libdir, '^lib(.*)\.a$', 'lib%s-dev', 'libpcre
%s development package', extra_depends='${PN}-dev')
- do_split_packages(d, pcre_libdir, '^lib(.*)\.so\.*', 'lib%s', 'libpcre
%s library', extra_depends='', allow_links=True)
+ do_split_packages(d, pcre_libdir, '^lib(.*)\.so\.+', 'lib%s', 'libpcre
%s library', extra_depends='', allow_links=True)
}
FILES_${PN} = ${libdir}/libpcre.so.*
--
1.7.4.1
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 6/6] insane.bbclass: Start to rework this so specific checks can be easily made warnings/errors
From: Richard Purdie richard.pur...@linuxfoundation.org
This patch means the warning/error handling can be controlled from local.conf
and/or from the distro level and no longer uses numbers but strings instead.
The system becomes extensible so that other classes can extend the path QA
checks at least.
It also removes all th duplicate error message code, we should have *one*
good error message.
Much work remains including making INSANE_SKIP take the classes of QA test
to skip but its a start.
Signed-off-by: Richard Purdie richard.pur...@linuxfoundation.org
---
meta/classes/insane.bbclass | 216 +--
1 files changed, 83 insertions(+), 133 deletions(-)
diff --git a/meta/classes/insane.bbclass b/meta/classes/insane.bbclass
index 35809b9..a6f9c1e 100644
--- a/meta/classes/insane.bbclass
+++ b/meta/classes/insane.bbclass
@@ -91,83 +91,39 @@ def package_qa_get_machine_dict():
}
-# Known Error classes
-# 0 - non dev contains .so
-# 1 - package contains a dangerous RPATH
-# 2 - package depends on debug package
-# 3 - non dbg contains .so
-# 4 - wrong architecture
-# 5 - .la contains installed=yes or reference to the workdir
-# 6 - .pc contains reference to /usr/include or workdir
-# 7 - the desktop file is not valid
-# 8 - .la contains reference to the workdir
-# 9 - LDFLAGS ignored
-# 10 - Build paths in binaries
+WARN_QA ?= dev-so rpaths debug-deps debug-files arch la2 pkgconfig desktop la
ldflags perms
+ERROR_QA ?=
+#ERROR_QA ?= rpaths debug-deps debug-files arch pkgconfig perms
def package_qa_clean_path(path,d):
Remove the common prefix from the path. In this case it is the
TMPDIR
return path.replace(bb.data.getVar('TMPDIR',d,True),)
-def package_qa_make_fatal_error(error_class, name, path,d):
-
-decide if an error is fatal
-
-TODO: Load a whitelist of known errors
-
-return False
-return not error_class in [0, 5, 7, 8, 9]
-
-def package_qa_write_error(error_class, name, path, d):
-
-Log the error
-
-
-ERROR_NAMES =[
-non dev contains .so,
-package contains RPATH,
-package depends on debug package,
-non dbg contains .debug,
-wrong architecture,
-evil hides inside the .la,
-evil hides inside the .pc,
-the desktop file is not valid,
-.la contains reference to the workdir,
-LDFLAGS ignored,
-package contains reference to tmpdir paths,
-]
-
-log_path = os.path.join( bb.data.getVar('T', d, True), log.qa_package )
-f = file( log_path, a+)
-print f, %s, %s, %s % \
- (ERROR_NAMES[error_class], name, package_qa_clean_path(path,d))
-f.close()
-
-logfile = bb.data.getVar('QA_LOGFILE', d, True)
+def package_qa_write_error(error, d):
+logfile = d.getVar('QA_LOGFILE', True)
if logfile:
-p = bb.data.getVar('P', d, True)
+p = d.getVar('P', True)
f = file( logfile, a+)
-print f, %s, %s, %s, %s % \
- (p, ERROR_NAMES[error_class], name, package_qa_clean_path(path,d))
+print f, %s: %s % (p, error)
f.close()
-def package_qa_handle_error(error_class, error_msg, name, path, d):
-fatal = package_qa_make_fatal_error(error_class, name, path, d)
-if fatal:
+def package_qa_handle_error(error_class, error_msg, d):
+package_qa_write_error(error_msg, d)
+if error_class in (d.getVar(ERROR_QA, True) or ).split():
bb.error(QA Issue: %s % error_msg)
+return True
else:
bb.warn(QA Issue: %s % error_msg)
-package_qa_write_error(error_class, name, path, d)
-
-return not fatal
+return False
-def package_qa_check_rpath(file,name,d, elf):
+QAPATHTEST[rpaths] = package_qa_check_rpath
+def package_qa_check_rpath(file,name, d, elf, messages):
Check for dangerous RPATHs
if not elf:
-return True
+return
-sane = True
scanelf =
os.path.join(bb.data.getVar('STAGING_BINDIR_NATIVE',d,True),'scanelf')
bad_dirs = [bb.data.getVar('TMPDIR', d, True) + /work,
bb.data.getVar('STAGING_DIR_TARGET', d, True)]
bad_dir_test = bb.data.getVar('TMPDIR', d, True)
@@ -182,67 +138,56 @@ def package_qa_check_rpath(file,name,d, elf):
for line in txt:
for dir in bad_dirs:
if dir in line:
-error_msg = package %s contains bad RPATH %s in file %s %
(name, line, file)
-sane = sane + package_qa_handle_error(1, error_msg, name,
file, d)
+messages.append(package %s contains bad RPATH %s in file %s
% (name, line, file))
-return sane
-
-def package_qa_check_dev(path, name,d, elf):
+QAPATHTEST[dev-so] = package_qa_check_dev
+def package_qa_check_dev(path, name, d, elf, messages):
Check for .so library symlinks in non-dev packages
-sane = True
-
if not name.endswith(-dev) and not name.endswith(-dbg) and
path.endswith(.so) and
Re: [OE-core] [PATCH 5/6] beecrypt: Fix up packaging QA warnings
On Fri, 2011-07-01 at 16:17 +0100, Richard Purdie wrote:
+FILES_${PN} = ${sysconfdir} ${libdir}/*.so.* ${libdir}/${BPN}/*.so.*
You can use ${SOLIBS} there...
+FILES_${PN}-dev += ${libdir}/${BPN}/*.so ${libdir}/${BPN}/*.la
... and ${SOLIBSDEV} there.
p.
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [oe] Any reasons not to use newer ppp?
On 30.06.2011 12:15, Phil Blundell wrote:
On Thu, 2011-06-30 at 12:12 +0200, Steffen Sledz wrote:
The current oe-dev master contains recipes for 2.4.4 and 2.4.5, but both are
DEFAULT_PREFERENCE = -1, so 2.4.3 is used by default.
We hit a problem in LCP open/close handling which is fixed in the newer
versions.
Is there any reason *not* to go to 2.4.5?
Oe-core is using 2.4.5 and presumably it works OK there. Judging from
the commit messages there is no good reason for 2.4.5 to have been set
D_P=-1 in oe.dev, so I think you should be safe to upgrade.
While making some investingations in this i hit another problem.
The recipe *ppp_2.4.5.bb* in *oe-core* contains lines like these:
--snip---
FILES_${PN}-dbg += ${libdir}/pppd/2.4.3/.debug
FILES_ppp-oa = /usr/lib/pppd/2.4.3/pppoatm.so
FILES_ppp-oe = /usr/sbin/pppoe-discovery /usr/lib/pppd/2.4.3/rp-pppoe.so
FILES_ppp-radius = /usr/lib/pppd/2.4.3/radius.so
/usr/lib/pppd/2.4.3/radattr.so /usr/lib/pppd/2.4.3/radrealms.so
FILES_ppp-winbind = /usr/lib/pppd/2.4.3/winbind.so
FILES_ppp-minconn = /usr/lib/pppd/2.4.3/minconn.so
FILES_ppp-password = /usr/lib/pppd/2.4.3/pass*.so
--snip---
I can't imagine that it is intentionally to have hardcoded pathes with *2.4.3*
in it here.
The ppp_2.4.5.bb recipe in oe-dev looks much cleaner. Is there someone who
feels as a maintainer of ppp and can do some housekeeping here?
Regards,
Steffen
PS: Fup set to the original thread in openembedded-devel list.
--
DResearch Fahrzeugelektronik GmbH
Otto-Schmirgal-Str. 3, 10319 Berlin, Germany
Tel: +49 30 515932-237 mailto:sl...@dresearch-fe.de
Fax: +49 30 515932-299
Geschäftsführer: Dr. Michael Weber, Werner Mögle;
Amtsgericht Berlin Charlottenburg; HRB 130120 B;
Ust.-IDNr. DE273952058
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] insane bbclass: turn fatal errors back into fatal errors
On Thu, 2011-06-30 at 16:59 +0100, Paul Eggleton wrote: OK, comprehension fail on my part, sorry. Good to have them listed out explicitly though, thanks for that. The fatal errors are definitely not good things to be allowing through if we can avoid it. Without checking, do you have a handle on how many of these we would have to fix in OE-core to make it build without fatal errors? For a world build of OE-Core/Poky on qemux86 (on a 64 bit machine so it is cross) and ignoring desktop errors and things I've posted fixes for: db-5.1.19, non dev contains .so, db, /work/i586-poky-linux/db-5.1.19-r3/packages-split/db/usr/lib/libdb-5.so perl-5.12.3, package contains RPATH, perl-module-compress, /work/i586-poky-linux/perl-5.12.3-r1/packages-split/perl-module-compress/usr/lib/perl/5.12.3/auto/Compress/Raw/Zlib/Zlib.so libxml-parser-perl-2.40, package contains RPATH, libxml-parser-perl, /work/i586-poky-linux/libxml-parser-perl-2.40-r2/packages-split/libxml-parser-perl/usr/lib/perl/vendor_perl/5.12.3/auto/XML/Parser/Expat/Expat.so oprofile-0.9.6, non dev contains .so, oprofile, /work/i586-poky-linux/oprofile-0.9.6-r1/packages-split/oprofile/usr/lib/oprofile/libopagent.so lttng-viewer-0.12.38, non dev contains .so, lttng-viewer, /work/i586-poky-linux/lttng-viewer-0.12.38-r1/packages-split/lttng-viewer/usr/lib/liblttvtraceread.so gcc-4.6.0+svnr175150, non dev contains .so, gcc, /work/i586-poky-linux/gcc-4.6.0+svnr175150-r4/packages-split/gcc/usr/libexec/gcc/i586-poky-linux/4.6.1/liblto_plugin.so libgsmd-0.1+svnr5394, non dev contains .so, gsmd-plugin-machine-generic, /work/i586-poky-linux/libgsmd-0.1+svnr5394-r2/packages-split/gsmd-plugin-machine-generic/usr/lib/gsmd/libgsmd-machine_generic.so libgsmd-0.1+svnr5394, non dev contains .so, gsmd-plugin-machine-tihtc, /work/i586-poky-linux/libgsmd-0.1+svnr5394-r2/packages-split/gsmd-plugin-machine-tihtc/usr/lib/gsmd/libgsmd-machine_tihtc.so libgsmd-0.1+svnr5394, non dev contains .so, gsmd-plugin-machine-gta01, /work/i586-poky-linux/libgsmd-0.1+svnr5394-r2/packages-split/gsmd-plugin-machine-gta01/usr/lib/gsmd/libgsmd-machine_gta01.so libgsmd-0.1+svnr5394, non dev contains .so, gsmd-plugin-vendor-bcm, /work/i586-poky-linux/libgsmd-0.1+svnr5394-r2/packages-split/gsmd-plugin-vendor-bcm/usr/lib/gsmd/libgsmd-vendor_bcm.so libgsmd-0.1+svnr5394, non dev contains .so, gsmd-plugin-vendor-qc, /work/i586-poky-linux/libgsmd-0.1+svnr5394-r2/packages-split/gsmd-plugin-vendor-qc/usr/lib/gsmd/libgsmd-vendor_qc.so libgsmd-0.1+svnr5394, non dev contains .so, gsmd-plugin-vendor-ti, /work/i586-poky-linux/libgsmd-0.1+svnr5394-r2/packages-split/gsmd-plugin-vendor-ti/usr/lib/gsmd/libgsmd-vendor_ti.so libgsmd-0.1+svnr5394, non dev contains .so, gsmd-plugin-vendor-tihtc, /work/i586-poky-linux/libgsmd-0.1+svnr5394-r2/packages-split/gsmd-plugin-vendor-tihtc/usr/lib/gsmd/libgsmd-vendor_tihtc.so qemu-0.14.0, wrong architecture, qemu, /work/i586-poky-linux/qemu-0.14.0-r2/packages-split/qemu/usr/share/qemu/openbios-ppc qemu-0.14.0, wrong architecture, qemu, /work/i586-poky-linux/qemu-0.14.0-r2/packages-split/qemu/usr/share/qemu/openbios-sparc32 qemu-0.14.0, wrong architecture, qemu, /work/i586-poky-linux/qemu-0.14.0-r2/packages-split/qemu/usr/share/qemu/openbios-sparc64 qt4-x11-free-4.7.3, wrong architecture, qt4-tools-dbg, /work/i586-poky-linux/qt4-x11-free-4.7.3-r23.1/packages-split/qt4-tools-dbg/usr/bin/.debug/uic qt4-x11-free-4.7.3, wrong architecture, qt4-tools-dbg, /work/i586-poky-linux/qt4-x11-free-4.7.3-r23.1/packages-split/qt4-tools-dbg/usr/bin/.debug/rcc qt4-x11-free-4.7.3, wrong architecture, qt4-tools-dbg, /work/i586-poky-linux/qt4-x11-free-4.7.3-r23.1/packages-split/qt4-tools-dbg/usr/bin/.debug/moc qt4-x11-free-4.7.3, wrong architecture, qt4-tools, /work/i586-poky-linux/qt4-x11-free-4.7.3-r23.1/packages-split/qt4-tools/usr/bin/uic qt4-x11-free-4.7.3, wrong architecture, qt4-tools, /work/i586-poky-linux/qt4-x11-free-4.7.3-r23.1/packages-split/qt4-tools/usr/bin/rcc qt4-x11-free-4.7.3, wrong architecture, qt4-tools, /work/i586-poky-linux/qt4-x11-free-4.7.3-r23.1/packages-split/qt4-tools/usr/bin/moc qt4-x11-free-4.7.3, wrong architecture, qt4-linguist, /work/i586-poky-linux/qt4-x11-free-4.7.3-r23.1/packages-split/qt4-linguist/usr/bin/lrelease The qemu ones are false positives, the qt ones are nasty as are the libxml-parser-perl and perl ones. The .so errors are hard to get excited about but should get looked at and resolved. In the meantime I'll run a world build for mips or ppc and see if that shows anything different up. Cheers, Richard ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] It's broken, please revert. Re: [PATCH 0/4 V4] Share gcc work directories
On 07/01/2011 07:01 AM, Koen Kooi wrote:
Op 1 jul 2011, om 15:57 heeft Khem Raj het volgende geschreven:
On Jul 1, 2011, at 4:00 AM, Koen Kooik...@dominion.thruhere.net wrote:
Op 1 jul 2011, om 10:32 heeft Richard Purdie het volgende geschreven:
On Fri, 2011-07-01 at 09:15 +0200, Koen Kooi wrote:
incremental build with rm_work turned on:
ERROR: Function 'do_configure' failed (see
/OE/tentacle/build/tmp-angstrom_2010_x-eglibc/work/armv7a-angstrom-linux-gnueabi/gcc-cross-initial-4.5-r37.0+svnr175127/temp/log.do_configure.27092
for further information)
ERROR: Logfile of failure stored in:
/OE/tentacle/build/tmp-angstrom_2010_x-eglibc/work/armv7a-angstrom-linux-gnueabi/gcc-cross-initial-4.5-r37.0+svnr175127/temp/log.do_configure.27092
Log data follows:
| + cd
/OE/tentacle/build/tmp-angstrom_2010_x-eglibc/work/armv7a-angstrom-linux-gnueabi/gcc-cross-initial-4.5-r37.0+svnr175127/gcc-4.5/build.x86_64-linux.arm-angstrom-linux-gnueabi
| + do_configure
| + sed -i
'/OE/tentacle/build/tmp-angstrom_2010_x-eglibc/work/armv7a-angstrom-linux-gnueabi/gcc-cross-initial-4.5-r37.0+svnr175127/gcc-4_5-branch/gcc/config/*/linux*.h'
-e 's#\(GLIBC_DYNAMIC_LINKER[^ ]*\)\( */lib.*\)#\1 SYSTEMLIBS_DIR\2#'
| sed: can't read
/OE/tentacle/build/tmp-angstrom_2010_x-eglibc/work/armv7a-angstrom-linux-gnueabi/gcc-cross-initial-4.5-r37.0+svnr175127/gcc-4_5-branch/gcc/config/*/linux*.h:
No such file or directory
| ERROR: Function 'do_configure' failed (see
/OE/tentacle/build/tmp-angstrom_2010_x-eglibc/work/armv7a-angstrom-linux-gnueabi/gcc-cross-initial-4.5-r37.0+svnr175127/temp/log.do_configure.27092
for further information)
NOTE: package gcc-cross-initial-4.5-r37.0+svnr175127: task do_configure: Failed
ERROR: Task 764
(/OE/tentacle/sources/meta-openembedded/meta-oe/recipes-devtools/gcc/gcc-cross-initial_4.5.bb,
do_configure) failed with exit code '1'
Can this patchset get reverted please and reapplied when it actually has been
tested to work?
I checked and everything is fine with rm_work.
Looking at this error, something is changing ${S} as there is no mention
of work-shared in the sed command yet there should be.
At a guess this is coming from:
http://git.angstrom-distribution.org/cgi-bin/cgit.cgi/meta-openembedded/tree/meta-oe/recipes-devtools/gcc/gcc-4.5.inc
where it says:
S = ${WORKDIR}/${BRANCH}
and if that is changed to
S_append = /${BRANCH}
or removed it will likely work better.
It was indeed a bug in meta-oe and the following fixed it:
https://github.com/koenkooi/meta-oe/commit/8a917caaa5506fa0f875202243658a1c2fe60c40
Additionally you would need to port the patch which mucks makefile fragment I
think
Any volunteers for that? My incremental build seems to work now, haven't tried
a from scratch yet.
I had a patch for it half of which you already have. Once it builds
through I will post.
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] Add support for remote layering.
On 7/1/2011 6:24 AM, Paul Eggleton wrote: Hi Jeremy Have looked at this further and I really think this needs to be a separate utility, but one still written in python using bitbake's infrastructure (like bitbake-layers). The advantages of this approach: 1) Avoids reworking bitbake's initialisation and avoids possible re-execution. Neither of those are issues in the current patch. Setting up the fetchers so they work, inside a local copy of the data is hardly reworking the initialization. A separate utility can take advantage of a full parse and utilise all of the user's configuration. This is certainly the case, however in the time that we have used this type of structure we have never needed all of the config data because you are always more less very early in the process. More or less you could create a bitbake-layers style utilty with the current patch. In the current patch, there is only a single line of code in the cooker, everything else is competely isolated. 2) Fetching/updating layers should be (able to be) a conscious action rather than something that happens implicitly as part of the build process This seems rather arbitrary. As noted this is not some theoretical process that I am proposing. We have tons of customers already use, and have used this type of model for a very long time. While I can certainly see the advantages of an external tool, why is it an either or? the reality is with the current patch, we already have bitbake-layers style utility. Its called bitbake. :) Run it with no argument and the first thing it does is fetch everything. I'm trying to put something together that does this at the moment, with a view to there being components that allow integration with the content tools you posted earlier. Will keep you posted. For what it is worth, I would still like to see something like the patch get integrated. The single line in the cooker could be surrounnded by a BB_ var, and you more or less wouldn't know the difference. Also if BBLAYERS is just directories like it is now, every line is more or less ignored and passed back untouched. -- Jeremy Puhlman Montavista Sofware, LLC. ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] insane bbclass: turn fatal errors back into fatal errors
On 7/1/11 12:16 PM, Khem Raj wrote: On 07/01/2011 10:12 AM, Richard Purdie wrote: gcc-4.6.0+svnr175150, non dev contains .so, gcc, /work/i586-poky-linux/gcc-4.6.0+svnr175150-r4/packages-split/gcc/usr/libexec/gcc/i586-poky-linux/4.6.1/liblto_plugin.so This should be packages with gcc itself. May be adding to FILES will get rid of this warning The warning above indicates that it -is- being packaged in the 'gcc' package. The check verified that no files of the name .so exit and they are not symlinks: if not name.endswith(-dev) and not name.endswith(-dbg) and path.endswith(.so) and os.path.islink(path): In this case, I believe that the file is likely supposed to be there. Is there a way to selectively disable insane checks on a per-recipe basis when we know they are wrong? --Mark ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] insane bbclass: turn fatal errors back into fatal errors
Op 1 jul 2011, om 19:25 heeft Mark Hatle het volgende geschreven: On 7/1/11 12:16 PM, Khem Raj wrote: On 07/01/2011 10:12 AM, Richard Purdie wrote: gcc-4.6.0+svnr175150, non dev contains .so, gcc, /work/i586-poky-linux/gcc-4.6.0+svnr175150-r4/packages-split/gcc/usr/libexec/gcc/i586-poky-linux/4.6.1/liblto_plugin.so This should be packages with gcc itself. May be adding to FILES will get rid of this warning The warning above indicates that it -is- being packaged in the 'gcc' package. The check verified that no files of the name .so exit and they are not symlinks: if not name.endswith(-dev) and not name.endswith(-dbg) and path.endswith(.so) and os.path.islink(path): In this case, I believe that the file is likely supposed to be there. Is there a way to selectively disable insane checks on a per-recipe basis when we know they are wrong? We only have the big INSANE_SKIP_gcc = True hammer ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH] consolekit: Add glib-2.0 to DEPENDS
Otherwise it ends up with this error
| configure: error: Package requirements (dbus-glib-1 = 0.82
| gobject-2.0 = 2.14
| gthread-2.0 = 2.14
| ) were not met:
|
| No package 'gobject-2.0' found
| No package 'gthread-2.0' found
|
| Consider adjusting the PKG_CONFIG_PATH environment variable if you
| installed software in a non-standard prefix.
Signed-off-by: Khem Raj raj.k...@gmail.com
---
.../recipes-support/consolekit/consolekit_0.4.5.bb |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/meta/recipes-support/consolekit/consolekit_0.4.5.bb
b/meta/recipes-support/consolekit/consolekit_0.4.5.bb
index c934d0f..661cca6 100644
--- a/meta/recipes-support/consolekit/consolekit_0.4.5.bb
+++ b/meta/recipes-support/consolekit/consolekit_0.4.5.bb
@@ -2,13 +2,13 @@ DESCRIPTION = ConsoleKit is a framework for defining and
tracking users, login
HOMEPAGE=http://www.freedesktop.org/wiki/Software/ConsoleKit;
BUGTRACKER=https://bugs.freedesktop.org/buglist.cgi?query_format=specificproduct=ConsoleKit;
-PR = r3
+PR = r4
LICENSE = GPLv2+
LIC_FILES_CHKSUM = file://COPYING;md5=59530bdf33659b29e73d4adb9f9f6552 \
file://src/main.c;endline=21;md5=0a994e09769780220163255d8f9071c3
-DEPENDS = dbus polkit ${@base_contains('DISTRO_FEATURES', 'pam', 'libpam',
'', d)}
+DEPENDS = glib-2.0 dbus polkit ${@base_contains('DISTRO_FEATURES', 'pam',
'libpam', '', d)}
inherit gnome
--
1.7.4.1
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH] ppp: sync packaging with OE .dev
This fixes the QA errors and the 2.4.3 vs 2.4.5 copy/paste mistake
Signed-off-by: Koen Kooi k...@dominion.thruhere.net
---
meta/recipes-connectivity/ppp/ppp_2.4.5.bb | 26 ++
1 files changed, 14 insertions(+), 12 deletions(-)
diff --git a/meta/recipes-connectivity/ppp/ppp_2.4.5.bb
b/meta/recipes-connectivity/ppp/ppp_2.4.5.bb
index b865afd..72464bf 100644
--- a/meta/recipes-connectivity/ppp/ppp_2.4.5.bb
+++ b/meta/recipes-connectivity/ppp/ppp_2.4.5.bb
@@ -10,7 +10,7 @@ LIC_FILES_CHKSUM =
file://pppd/ccp.c;beginline=1;endline=29;md5=e2c43fe6e81ff77
file://pppd/plugins/passprompt.c;beginline=1;endline=10;md5=3bcbcdbf0e369c9a3e0b8c8275b065d8
\
file://pppd/tdb.c;beginline=1;endline=27;md5=4ca3a9991b011038d085d6675ae7c4e6 \
file://chat/chat.c;beginline=1;endline=15;md5=0d374b8545ee5c62d7aff1acbd38add2
-PR = r1
+PR = r2
SRC_URI = http://ppp.samba.org/ftp/ppp/ppp-${PV}.tar.gz \
file://makefile.patch \
@@ -31,7 +31,8 @@ SRC_URI[sha256sum] =
43317afec9299f9920b96f840414c977f0385410202d48e56d2fdb8230
inherit autotools
-EXTRA_OEMAKE = STRIPPROG=${STRIP} MANDIR=${D}${datadir}/man/man8
INCDIR=${D}/usr/include LIBDIR=${D}/usr/lib/pppd/${PV} BINDIR=${D}/usr/sbin
+TARGET_CC_ARCH += ${LDFLAGS}
+EXTRA_OEMAKE = STRIPPROG=${STRIP} MANDIR=${D}${datadir}/man/man8
INCDIR=${D}${includedir} LIBDIR=${D}${libdir}/pppd/${PV} BINDIR=${D}${sbindir}
EXTRA_OECONF = --disable-strip
do_install_append () {
@@ -50,16 +51,17 @@ do_install_append () {
}
CONFFILES_${PN} = ${sysconfdir}/ppp/pap-secrets
${sysconfdir}/ppp/chap-secrets ${sysconfdir}/ppp/options
-PACKAGES += ppp-oa ppp-oe ppp-radius ppp-winbind ppp-minconn ppp-password
ppp-tools
-FILES_${PN}= /etc /usr/bin /usr/sbin/chat /usr/sbin/pppd
-FILES_${PN}-dbg += ${libdir}/pppd/2.4.3/.debug
-FILES_ppp-oa = /usr/lib/pppd/2.4.3/pppoatm.so
-FILES_ppp-oe = /usr/sbin/pppoe-discovery
/usr/lib/pppd/2.4.3/rp-pppoe.so
-FILES_ppp-radius = /usr/lib/pppd/2.4.3/radius.so
/usr/lib/pppd/2.4.3/radattr.so /usr/lib/pppd/2.4.3/radrealms.so
-FILES_ppp-winbind = /usr/lib/pppd/2.4.3/winbind.so
-FILES_ppp-minconn = /usr/lib/pppd/2.4.3/minconn.so
-FILES_ppp-password = /usr/lib/pppd/2.4.3/pass*.so
-FILES_ppp-tools= /usr/sbin/pppstats /usr/sbin/pppdump
+PACKAGES =+ ppp-oa ppp-oe ppp-radius ppp-winbind ppp-minconn ppp-password
ppp-tools
+FILES_${PN}= ${sysconfdir} ${bindir} ${sbindir}/chat ${sbindir}/pppd
+FILES_${PN}_nylon = ${sysconfdir} ${bindir} ${sbindir}/chat ${sbindir}/pppd
${sbindir}/tdbread
+FILES_${PN}-dbg += ${libdir}/pppd/${PV}/.debug
+FILES_${PN}-oa = ${libdir}/pppd/${PV}/pppoatm.so
+FILES_${PN}-oe = ${sbindir}/pppoe-discovery
${libdir}/pppd/${PV}/rp-pppoe.so
+FILES_${PN}-radius = ${libdir}/pppd/${PV}/radius.so
${libdir}/pppd/${PV}/radattr.so ${libdir}/pppd/${PV}/radrealms.so
+FILES_${PN}-winbind = ${libdir}/pppd/${PV}/winbind.so
+FILES_${PN}-minconn = ${libdir}/pppd/${PV}/minconn.so
+FILES_${PN}-password = ${libdir}/pppd/${PV}/pass*.so
+FILES_${PN}-tools= ${sbindir}/pppstats ${sbindir}/pppdump
DESCRIPTION_ppp-oa = Plugin for PPP needed for PPP-over-ATM
DESCRIPTION_ppp-oe = Plugin for PPP needed for PPP-over-Ethernet
DESCRIPTION_ppp-radius = Plugin for PPP that are related to RADIUS
--
1.6.6.1
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] insane bbclass: turn fatal errors back into fatal errors
On Fri, 2011-07-01 at 19:33 +0200, Koen Kooi wrote: Op 1 jul 2011, om 19:25 heeft Mark Hatle het volgende geschreven: On 7/1/11 12:16 PM, Khem Raj wrote: On 07/01/2011 10:12 AM, Richard Purdie wrote: gcc-4.6.0+svnr175150, non dev contains .so, gcc, /work/i586-poky-linux/gcc-4.6.0+svnr175150-r4/packages-split/gcc/usr/libexec/gcc/i586-poky-linux/4.6.1/liblto_plugin.so This should be packages with gcc itself. May be adding to FILES will get rid of this warning The warning above indicates that it -is- being packaged in the 'gcc' package. The check verified that no files of the name .so exit and they are not symlinks: if not name.endswith(-dev) and not name.endswith(-dbg) and path.endswith(.so) and os.path.islink(path): In this case, I believe that the file is likely supposed to be there. Is there a way to selectively disable insane checks on a per-recipe basis when we know they are wrong? We only have the big INSANE_SKIP_gcc = True hammer Although as I hint at in my insane.bbclass patch, I just made it much easier to implement skipping specific checks. Its not there yet but shouldn't be too difficult from where the code it at now... Cheers, Richard ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/1] perl: Fix package qa rpath warnings.
From: Nitin A Kamble nitin.a.kam...@intel.com
Fix these kinds of Package QA warnings before they are converted into fetal
errors:
WARNING: QA Issue: package perl-module-compress contains bad RPATH
/build_disk/poky_build/build0/tmp/sysroots/qemux86/usr/lib in file
/build_disk/poky_build/build0/tmp/work/i586-poky-linux/perl-5.12.3-r1/packages-split/perl-module-compress/usr/lib/perl/5.12.3/auto/Compress/Raw/Zlib/Zlib.so
This fixes this warning for perl recipe as well as libxml-parser-perl recipe.
It is a fix to MakeMaker within perl, so all such perl recipes will get
fixed with this perl fix.
Signed-off-by: Nitin A Kamble nitin.a.kam...@intel.com
---
.../perl/perl-5.12.3/fix_bad_rpath.patch | 25
meta/recipes-devtools/perl/perl_5.12.3.bb |6 +++-
2 files changed, 29 insertions(+), 2 deletions(-)
create mode 100644 meta/recipes-devtools/perl/perl-5.12.3/fix_bad_rpath.patch
diff --git a/meta/recipes-devtools/perl/perl-5.12.3/fix_bad_rpath.patch
b/meta/recipes-devtools/perl/perl-5.12.3/fix_bad_rpath.patch
new file mode 100644
index 000..7b99857
--- /dev/null
+++ b/meta/recipes-devtools/perl/perl-5.12.3/fix_bad_rpath.patch
@@ -0,0 +1,25 @@
+Upstream-Status:Inappropriate [embedded specific]
+Signed-Off-By: Nitin A Kamble nitin.a.kam...@intel.com
+2011/07/01
+
+Fix these Package QA warnings before they are converted into fetal errors:
+
+WARNING: QA Issue: package perl-module-compress contains bad RPATH
/build_disk/poky_build/build0/tmp/sysroots/qemux86/usr/lib in file
/build_disk/poky_build/build0/tmp/work/i586-poky-linux/perl-5.12.3-r1/packages-split/perl-module-compress/usr/lib/perl/5.12.3/auto/Compress/Raw/Zlib/Zlib.so
+
+This fixes this warning for perl recipe as well as libxml-parser-perl recipe.
+It is a fix to MakeMaker within perl, so all such perl recipes will get
+fixed with this perl fix.
+
+Index: perl-5.12.3/cpan/ExtUtils-MakeMaker/lib/ExtUtils/Liblist/Kid.pm
+===
+--- perl-5.12.3.orig/cpan/ExtUtils-MakeMaker/lib/ExtUtils/Liblist/Kid.pm
perl-5.12.3/cpan/ExtUtils-MakeMaker/lib/ExtUtils/Liblist/Kid.pm
+@@ -54,7 +54,7 @@ sub _unix_os2_ext {
+ my($found) = 0;
+
+ # Debian-specific: don't use LD_RUN_PATH for standard dirs
+-$ld_run_path_seen{$_}++ for qw(/lib /usr/lib /usr/X11R6/lib);
++$ld_run_path_seen{$_}++ for qw(/lib /usr/lib /usr/X11R6/lib SYSROOTLIB);
+
+ foreach my $thislib (split ' ', $potential_libs) {
+
diff --git a/meta/recipes-devtools/perl/perl_5.12.3.bb
b/meta/recipes-devtools/perl/perl_5.12.3.bb
index b053482..850eef2 100644
--- a/meta/recipes-devtools/perl/perl_5.12.3.bb
+++ b/meta/recipes-devtools/perl/perl_5.12.3.bb
@@ -8,7 +8,7 @@ PRIORITY = optional
# We need gnugrep (for -I)
DEPENDS = virtual/db grep-native
DEPENDS += gdbm zlib
-PR = r1
+PR = r2
# 5.10.1 has Module::Build built-in
PROVIDES += libmodule-build-perl
@@ -68,6 +68,7 @@ SRC_URI = http://www.cpan.org/src/5.0/perl-${PV}.tar.gz \
file://native-perlinc.patch \
file://perl-enable-gdbm.patch \
file://cross-generate_uudmap.patch \
+ file://fix_bad_rpath.patch \
\
file://config.sh \
file://config.sh-32 \
@@ -178,7 +179,8 @@ do_configure() {
do_compile() {
sed -i -e 's|/usr/include|${STAGING_INCDIR}|g' ext/Errno/Errno_pm.PL
sed -i -e 's|/usr/include|${STAGING_INCDIR}|g'
cpan/Compress-Raw-Zlib/config.in
-sed -i -e 's|/usr/lib|${STAGING_LIBDIR}|g'
cpan/Compress-Raw-Zlib/config.in
+sed -i -e 's|/usr/lib||g' cpan/Compress-Raw-Zlib/config.in
+sed -i -e 's|SYSROOTLIB|${STAGING_LIBDIR}|g'
cpan/ExtUtils-MakeMaker/lib/ExtUtils/Liblist/Kid.pm
cd Cross
oe_runmake perl LD=${CCLD}
--
1.7.4.4
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
[OE-core] [PATCH 0/1] perl recipes fix package qa rpath warnings
From: Nitin A Kamble nitin.a.kam...@intel.com The following changes since commit ea518846b889a1bad2263d1cb49cb238a295a8e7: bitbake: Add missing bracket, somehow lost by sync scripts (2011-07-01 17:44:12 +0100) are available in the git repository at: git://git.pokylinux.org/poky-contrib nitin/misc http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=nitin/misc Nitin A Kamble (1): perl: Fix package qa rpath warnings. .../perl/perl-5.12.3/fix_bad_rpath.patch | 25 meta/recipes-devtools/perl/perl_5.12.3.bb |6 +++- 2 files changed, 29 insertions(+), 2 deletions(-) create mode 100644 meta/recipes-devtools/perl/perl-5.12.3/fix_bad_rpath.patch -- 1.7.4.4 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] Add support for remote layering.
On Fri, 2011-07-01 at 11:43 -0700, Jeremy Puhlman wrote: Just a quick follow up, the part of this statement that to me is wrong, is it appears you are dictating work flow. While, imho, the layer management code which is above this level, is the place to dicate workflow. The patch is to core bitbake and isolated at that. This patch adds an additional work flow, and can be used in either state(the results of a current BBLAYERS setting is exactly the same today as it as after the patch). More or less the patch is useful in a scope larger then just layer-tooling. Let me try and convey at least one of the things I'm worrying about with this patch. We're looking at establishing layer tooling which operate outside of or above bitbake. There are a variety of reasons for that, rightly or wrongly but this patch implies we're going to reverse that. If we go forward with the patch and don't reverse that decision it means that layers can sometimes be a thing that are above bitbake, sometimes not depending on the circumstances. I'm trying hard to avoid that kind of interwoven complexity as it makes code changes very hard to make in the future and leads to frequent breakage where multiple usage methods exist. As an example consider the case someone calls a script asking for new commits in layer Y to be added to flattened layer Z. We then have to add code checking if layer Y or layer X is a bitbake remote layer and then handle the updating of the layer accordingly. Can something external to the bitbake code do that? When we extend the later tooling are we expected to extend this code to match functionality? The abstraction in the remote layers code isn't strong enough to cope with that kind of interaction in its own right and I'm not sure its possible to do that simply with a line in a bblayers.conf file and still be readable. So I guess my question is how do you see this moving forwards? Are you planning to use external layer tooling at all or are you wanting anything that external tooling can do exposed also by the bblayers.conf URI? If this is some kind of stopgap solution for compatibility and is a single blocking issue for Montavista that might be reasonable. If its the start of a move to reverse the order of the stack and put bitbake at the top and layer tooling secondary, I'm worried. Also looking at the patch at a technical level, is there any reason to use _layerUnpack() instead of the fetch2 unpack method? The patch is much cleaner than it was, that much is good but needing to set so many fetcher variables like that is a sign that worries me a little. I guess the solution there is to code them as fallback defaults into the fetchers themselves. Cheers, Richard ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] ppp: sync packaging with OE .dev
On Fri, 2011-07-01 at 20:17 +0200, Koen Kooi wrote: This fixes the QA errors and the 2.4.3 vs 2.4.5 copy/paste mistake Merged to master, thanks. Richard ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 0/1] perl recipes fix package qa rpath warnings
On Fri, 2011-07-01 at 13:54 -0700, nitin.a.kam...@intel.com wrote: From: Nitin A Kamble nitin.a.kam...@intel.com The following changes since commit ea518846b889a1bad2263d1cb49cb238a295a8e7: bitbake: Add missing bracket, somehow lost by sync scripts (2011-07-01 17:44:12 +0100) are available in the git repository at: git://git.pokylinux.org/poky-contrib nitin/misc http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=nitin/misc Nitin A Kamble (1): perl: Fix package qa rpath warnings. Merged to master, thanks for the quick fix! Cheers, Richard ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] PRIORITY
On Fri, 2011-07-01 at 11:24 +0100, Phil Blundell wrote: On Fri, 2011-07-01 at 11:15 +0100, Richard Purdie wrote: On Fri, 2011-07-01 at 10:41 +0100, Phil Blundell wrote: We had some discussion of this a few weeks ago but I'm not sure it ever reached a firm conclusion. Is everyone agreed that the PRIORITY variable does not serve any useful purpose in oe-core and can/should be removed from the recipes? I think that was the conclusion, yes. I'll take a patch (or a commandline I guess). I did: $ find . -regex .*\.\(bb\|inc\)$ | xargs sed -i '/^PRIORITY = .*$/d' which seemed to produce the desired results. I can send a patch if you like but it would be somewhat large and fairly uninteresting. I've gone ahead and pushed such a commit, thanks! Richard ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 0/6] QA Warnings Cleanup
On Fri, 2011-07-01 at 16:17 +0100, Richard Purdie wrote: The following changes since commit 40ecaf6a59ba61e72d29d7e677197ef37c998408: uclibc: Add default uClibc.machine files (2011-07-01 00:40:10 +0100) are available in the git repository at: git://git.openembedded.org/openembedded-core-contrib rpurdie/master http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=rpurdie/master and clean up a variety of different QA warning issues Richard Purdie (6): cairo: Clean up packaging and fix warnings kernel.bbclass: Ensure kernel/* internal sysroot working directory don't get packaged libpcre: Fix QA warnings python: Ensure libpython.so ends up in the .dev package beecrypt: Fix up packaging QA warnings insane.bbclass: Start to rework this so specific checks can be easily made warnings/errors I've merged these to master since the work well with the other QA cleanups we're merging. The SOLIBS variable discussion can happen and be followed up on later. Cheers, Richard ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v5 0/8] Linux 3.0 build support
On Fri, 2011-07-01 at 15:07 +0200, Anders Darander wrote: v5: - task-base.bb: Move the RDEPENDS- and RRECOMMENDS_task-base-kernel26 to *_task-base. v4: Removed the RFC in patch subject. - Merge the patches 2 and 4 from v3. - Bump PR in patch 2. - Delete the ignore*.patch from module-init-tools. In v2, the patch was just disabled. v3: - task-base.bb: fix a problem that *pcmia26 couldn't be found. v2: Probably some more patches could be squashed together. There might also be more places that should be addressed in these patches. - Whitespace fixes - Updated module-init-tools to 3.16. I'm not applying the ignore*.patch (it didn't apply). - Do not provide virtual/*/depmod-2.6; just provide virtual/*/depmod. - Do only install as depmod. - Rearrange the order of some patches. - Added patches to clean up (partly) task-base, distro_tracking_fields. A few of the patches might be ready to pull, but the majority will need to be revised. === This work is unfinished and incomplete... It is published in its current form both to get feedback, but also to aid anyone else who is working on 3.0-support. If some of the patches are found to be OK, it's fine to cherrypick them. The kernel-related classes has been modified to build a 3.0 kernel. The patches has been simplified by removing support for the 2.4-series. (The latter was suggested in an older mail thread: http://www.mail-archive.com/openembedded-core@lists.openembedded.org/msg02682.html ). The patches has been tested on linux-yocto_2.6.37 and a hacked version using the linux-yocto-dev repository (using a 3.0-rcX). The latest versions has only been built for qemuarm, prior iterations has also been built for qemux86. Finally, no work has been done on the libc-linux-headers classes and recipes. /Anders The following changes since commit 40ecaf6a59ba61e72d29d7e677197ef37c998408: uclibc: Add default uClibc.machine files (2011-07-01 00:40:10 +0100) are available in the git repository at: git://github.com/darander/oe-core kernel-3.0 https://github.com/darander/oe-core/tree/kernel-3.0 Anders Darander (8): Remove support for building 2.4 kernels image¡kernel.bblass module-init-tools: do not use depmod-2.6 modules-init-tools(-cross): update to 3.16 kernel.bblass: remove get_kernelmajorversion modutils-initscripts: move recipe prior to modutils removal modutils: remove modutils task-base: remove modutils reference. distro_tracking_fields: remove modutils. Thanks for these, I merged them to master. Cheers, Richard ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v4 7/8] task-base: remove modutils reference.
On Fri, 2011-07-01 at 14:05 +0200, Koen Kooi wrote: Op 1 jul 2011, om 13:52 heeft Anders Darander het volgende geschreven: * Koen Kooi Koen Kooi k...@dominion.thruhere.net [07/01/11 09:20 AM]: Op 1 jul 2011, om 09:06 heeft Anders Darander het volgende geschreven: Also remove the other kernel24 references. Make everything dependent on kernel26 default. Since there will be only one of each, can we just completely scrap there variables and put the items directly in the tasks? Sure, we could do that. One question though, how should I treat RRECOMMENDS_task-base-kernel26 = \ kernel-module-nls-utf8 \ kernel-module-input \ kernel-module-uinput \ kernel-module-rtc-dev \ kernel-module-rtc-proc \ kernel-module-rtc-sysfs \ kernel-module-rtc-sa1100 \ kernel-module-unix from task-base.bb? Should that part just be new, general RRECOMMENDS = \ kernel-module-nls-utf8 \ kernel-module-input \ kernel-module-uinput \ kernel-module-rtc-dev \ kernel-module-rtc-proc \ kernel-module-rtc-sysfs \ kernel-module-rtc-sa1100 \ kernel-module-unix? I guess that's the right thing, and I'll create a new pull request with that merged into the last patch. The above is what I had in mind, but I do question the need for rtc-sa1100 in task-base, that should be in the machine.conf as MACHINE_EXTRA_RRECOMMENDS or so. But that is outside the scope of this patch I guess. Agreed, rtc-sa1100 shouldn't be there and I don't know how that happened :/. I'll take patches to resolve that. Cheers, Richard ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v5 7/8] task-base: remove modutils reference.
On Fri, 2011-07-01 at 15:32 +0200, Koen Kooi wrote:
Op 1 jul 2011, om 15:08 heeft Anders Darander het volgende geschreven:
Also remove the other kernel24 references.
Make everything dependent on kernel26 default.
Move the RDEPENDS- and RRECOMMENDS_task-base-kernel26 to _task-base.
Signed-off-by: Anders Darander and...@chargestorm.se
---
meta/recipes-core/tasks/task-base.bb | 49
++---
1 files changed, 15 insertions(+), 34 deletions(-)
#
# linux-hotplug or none
#
-HOTPLUG ?= ${@base_contains(MACHINE_FEATURES, kernel24,
linux-hotplug,,d)}
+HOTPLUG ?=
I think this one can go completely
#
# pcmciautils for = 2.6.13-rc1, pcmcia-cs for others
#
-PCMCIA_MANAGER ?= ${@base_contains('MACHINE_FEATURES',
'kernel26','pcmciautils','pcmcia-cs',d)}
+PCMCIA_MANAGER ?= pcmciautils
This one can get folded into the task directly
Agreed but I didn't feel it warranted not merging the patches so far.
Please send a follow up patch :)
Cheers,
Richard
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 5/6] beecrypt: Fix up packaging QA warnings
On Fri, 2011-07-01 at 16:19 +0100, Phil Blundell wrote:
On Fri, 2011-07-01 at 16:17 +0100, Richard Purdie wrote:
+FILES_${PN} = ${sysconfdir} ${libdir}/*.so.* ${libdir}/${BPN}/*.so.*
You can use ${SOLIBS} there...
+FILES_${PN}-dev += ${libdir}/${BPN}/*.so ${libdir}/${BPN}/*.la
... and ${SOLIBSDEV} there.
I'm in two minds on these. On the one hand they do make sense and have
allowed us to build darwin targets in the past (and would extend to
windows too). On the other hand nobody is using them outside the core
metadata.
I think a global search and replace would likely be the best move if we
decide they're a good thing...
Cheers,
Richard
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] Add support for remote layering.
On 7/1/2011 2:37 PM, Richard Purdie wrote: On Fri, 2011-07-01 at 11:43 -0700, Jeremy Puhlman wrote: Just a quick follow up, the part of this statement that to me is wrong, is it appears you are dictating work flow. While, imho, the layer management code which is above this level, is the place to dicate workflow. The patch is to core bitbake and isolated at that. This patch adds an additional work flow, and can be used in either state(the results of a current BBLAYERS setting is exactly the same today as it as after the patch). More or less the patch is useful in a scope larger then just layer-tooling. Let me try and convey at least one of the things I'm worrying about with this patch. We're looking at establishing layer tooling which operate outside of or above bitbake. There are a variety of reasons for that, rightly or wrongly but this patch implies we're going to reverse that. I think that only is true if you view the patch in the scope of the only purpose for the patch is an element of the layer tooling. Being able to specify a uri as a layer is in and of it self a useful ability, irrespective of whether there exists higher order tools to create that list. If we go forward with the patch and don't reverse that decision it means that layers can sometimes be a thing that are above bitbake, sometimes not depending on the circumstances. This kind of goes back to work flow issue. Unless you plan to make it so you cannot use the layers with out the specific layering tools that are in development, bitbake will always need to support different work flows. I'm trying hard to avoid that kind of interwoven complexity as it makes code changes very hard to make in the future and leads to frequent breakage where multiple usage methods exist. Well in this case, there is little that is interwoven. The remote layers bit in the main thread of the execution is a single line in the cooker. Paul was saying that he wanted to more or less still implement the tool with in the bitbake code. Ironically, that will likely be more interwoven then this patch. The patch on its own with out regard to layer tooling for this project, can pretty much stand on its own(which is why I provided it a month or two before we pushed up the content tools). As an example consider the case someone calls a script asking for new commits in layer Y to be added to flattened layer Z. We then have to add code checking if layer Y or layer X is a bitbake remote layer and then handle the updating of the layer accordingly. When ever you evaluate any of the layers, they are downloaded and unpacked prior to examination of any of the meta data(stay bblayers.conf). More or less any place where you would evalute bblayers.conf you would evaluate the collection uri's. How you update(i.e. if they are git for example) should be setable via the already in place fetch mechanism. More or less you would just need to run the BBLAYERS var through the remote layers class then the end result is the BBLAYERS is just a list of directories like it is now, which is why there is only one line of change in the current thread of execution. Can something external to the bitbake code do that? Unless your planning on creating tooling that doesn't use any of the bitbake internals, not unless you want to duplicate a whole bunch of code. When we extend the later tooling are we expected to extend this code to match functionality? Well if the end results of the layer tooling is a BBLAYERS with a list of directories as it is now, there is nothing to extend. The code handles that now. More or less if unless you are going in a drastically different direction with the BBLAYERS list, I am not sure what would need to be updated. The abstraction in the remote layers code isn't strong enough to cope with that kind of interaction in its own right and I'm not sure its possible to do that simply with a line in a bblayers.conf file and still be readable. My problem with this is currently using the same uri mechanism used in the rest of bitbake fetches. Why pick on it here? So I guess my question is how do you see this moving forwards? Well paul more or less said he was going to be writing the remote layering tools with hooks in to bitbake like bitbake-layers, so I am not entirely certain what external means in this context. With the current patch, you could basically write the entire tool calling in to bitbake and pass uri's to the layer fetch code, and either pass in our pass out the path of the final destination. Are you planning to use external layer tooling at all or are you wanting anything that external tooling can do exposed also by the bblayers.conf URI? Well it is two fold. Right now, the actual form of the end layer-tooling doesn't exist. So no I really couldn't commit to using what ever is produced. However, the entire reason why we provided this patch and the content-tools, is so that we could nudge them in a direction
