Re: [OE-core] compiling the host tools natively for the host Linux?
* Janne Karhunen janne.karhu...@gmail.com [150413 17:44]: Is there a way to compile the host tools (primarily interested in the compiler) for the host Linux rather than for the own distro? Could you explain what you're trying to achieve a little bit more? Which computer do you call host Linux and which one is own distro? Is the build-machine the host? Is the target own distro? If so, you need to look at generateing an SDK. (Prefebly, `bitbake image-name -c populate_sdk`). I'm comping the toolchains sysroots as RPMs and the relocation of the toolchain from $RPM_BUILD_ROOT is a bit painful due to the own distro being used to run them. I'm doing that in RPM %post with patchelf chrpath, but it is getting hairy. I'm not really following what you're trying to achieve... Cheers, Anders -- Anders Darander ChargeStorm AB / eStorm AB -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/1] rootfsdebugfiles.bbclass: quick-and-dirty installation of additional files
On Mon, 2015-04-13 at 09:07 -0700, Christopher Larson wrote: On Mon, Apr 13, 2015 at 8:44 AM, Patrick Ohly patrick.o...@intel.com wrote: The main motivation for this class was the observation that a) a core-image can hang under qemu when the kernel does not have enough entropy to generate the ssh host key b) ssh complains about changing ssh host key files when rebooting the same machine with different images For debugging it is okay to reuse an ssh host key generated on the device before. There may be also similar use cases, so the class is generic enough to also copy more than one file or directory, with dropbear_rsa_host_key given as example. The documentation and naming of the class makes it clear that it should not be used for production images. Signed-off-by: Patrick Ohly patrick.o...@intel.com Freescale's merge-files recipe may be worth looking at as an alternative to this. Thanks for mentioning it. Yes, that's also a way to do it. It seems a bit more complicated to set up (all files must be in a common merge directory) and does not seem to support sub-directories (-maxdepth 1), so it is a bit less flexible than the ROOTFS_DEBUG_FILES that I was proposing. On the other hand, the files get packaged properly (well, if one is careful about adapting the default MIT license as needed). For my use case, I still prefer the quick-and-dirty approach. -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 2/6] cracklib: add python support back
It had been disabled because of installed-vs-shipped:
WARNING: /usr/lib/python2.7
WARNING: /usr/lib/python2.7/site-packages
Now we fix it and add cracklib-python back.
Signed-off-by: Robert Yang liezhi.y...@windriver.com
---
meta/recipes-extended/cracklib/cracklib_2.9.2.bb | 28 ++
1 file changed, 24 insertions(+), 4 deletions(-)
diff --git a/meta/recipes-extended/cracklib/cracklib_2.9.2.bb
b/meta/recipes-extended/cracklib/cracklib_2.9.2.bb
index 177ab27..fceca54 100644
--- a/meta/recipes-extended/cracklib/cracklib_2.9.2.bb
+++ b/meta/recipes-extended/cracklib/cracklib_2.9.2.bb
@@ -4,10 +4,12 @@ HOMEPAGE = http://sourceforge.net/projects/cracklib;
LICENSE = LGPLv2.1+
LIC_FILES_CHKSUM = file://COPYING.LIB;md5=e3eda01d9815f8d24aae2dbd89b68b06
-DEPENDS = cracklib-native zlib
-DEPENDS_class-native = zlib-native
+DEPENDS = cracklib-native zlib python
+RDEPEND_${PN}-python += python
-EXTRA_OECONF = --without-python --libdir=${base_libdir}
+PACKAGES += ${PN}-python
+
+EXTRA_OECONF = --with-python --libdir=${base_libdir}
SRC_URI = ${SOURCEFORGE_MIRROR}/cracklib/cracklib-${PV}.tar.gz \
file://0001-packlib.c-support-dictionary-byte-order-dependent.patch
\
@@ -18,10 +20,28 @@ SRC_URI[sha256sum] =
c1c899291d443e99d1aecfbc879e4ac9c0cbc265574f47b487842da11e
PR = r1
-inherit autotools gettext
+inherit autotools gettext pythonnative python-dir
do_install_append_class-target() {
create-cracklib-dict -o ${D}${datadir}/cracklib/pw_dict
${D}${datadir}/cracklib/cracklib-small
}
+do_install_append() {
+ src_dir=${D}${base_libdir}/${PYTHON_DIR}/site-packages
+ rm -f $src_dir/*.pyo
+ rm -f $src_dir/test_cracklib.py
+ # Move python files from ${base_libdir} to ${libdir} since used
--libdir=${base_libdir}
+ install -d -m 0755 ${D}${PYTHON_SITEPACKAGES_DIR}/
+ mv $src_dir/* ${D}${PYTHON_SITEPACKAGES_DIR}
+ rm -fr ${D}${base_libdir}/${PYTHON_DIR}
+}
+
BBCLASSEXTEND = native nativesdk
+
+FILES_${PN}-python = ${PYTHON_SITEPACKAGES_DIR}/cracklib.py \
+ ${PYTHON_SITEPACKAGES_DIR}/_cracklib.so \
+
+FILES_${PN}-dbg += ${PYTHON_SITEPACKAGES_DIR}/.debug/_cracklib.so
+FILES_${PN}-staticdev += ${PYTHON_SITEPACKAGES_DIR}/_cracklib.a \
+ ${PYTHON_SITEPACKAGES_DIR}/_cracklib.la \
+
--
1.7.9.5
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 4/6] strace: fix build for aarch64
Fixed:
sigreturn.c: In function 'sys_sigreturn':
sigreturn.c:27:7: error: 'aarch64_sp_ptr' undeclared (first use in this
function)
(*aarch64_sp_ptr + SIZEOF_STRUCT_SIGINFO +
sigreturn.c:30:7: error: 'arm_sp_ptr' undeclared (first use in this function)
Signed-off-by: Robert Yang liezhi.y...@windriver.com
---
.../strace/sigreturn.c-fix-build-for-aarch64.patch | 34
meta/recipes-devtools/strace/strace_4.10.bb|1 +
2 files changed, 35 insertions(+)
create mode 100644
meta/recipes-devtools/strace/strace/sigreturn.c-fix-build-for-aarch64.patch
diff --git
a/meta/recipes-devtools/strace/strace/sigreturn.c-fix-build-for-aarch64.patch
b/meta/recipes-devtools/strace/strace/sigreturn.c-fix-build-for-aarch64.patch
new file mode 100644
index 000..ac2621b
--- /dev/null
+++
b/meta/recipes-devtools/strace/strace/sigreturn.c-fix-build-for-aarch64.patch
@@ -0,0 +1,34 @@
+From 1ef2d93924581ec8412ee9c163fbc92d039c1222 Mon Sep 17 00:00:00 2001
+From: Robert Yang liezhi.y...@windriver.com
+Date: Tue, 14 Apr 2015 03:15:04 +
+Subject: [PATCH] sigreturn.c: fix build for aarch64
+
+Fixed:
+sigreturn.c: In function 'sys_sigreturn':
+sigreturn.c:27:7: error: 'aarch64_sp_ptr' undeclared (first use in this
function)
+ (*aarch64_sp_ptr + SIZEOF_STRUCT_SIGINFO +
+sigreturn.c:30:7: error: 'arm_sp_ptr' undeclared (first use in this function)
+
+Upstream-Status: Backport [scratch from strace:
a3c483545a7fb3a075f885a01a3c58b2f84db8fa]
+
+Signed-off-by: Robert Yang liezhi.y...@windriver.com
+---
+ sigreturn.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+diff --git a/sigreturn.c b/sigreturn.c
+index 648bd0a..45c4675 100644
+--- a/sigreturn.c
b/sigreturn.c
+@@ -12,6 +12,8 @@
+ #elif NSIG 32
+ # error NSIG 32
+ #endif
++extern uint64_t *const aarch64_sp_ptr;
++extern uint32_t *const arm_sp_ptr;
+
+ int
+ sys_sigreturn(struct tcb *tcp)
+--
+2.0.1
+
diff --git a/meta/recipes-devtools/strace/strace_4.10.bb
b/meta/recipes-devtools/strace/strace_4.10.bb
index 416c387..489e1f4 100644
--- a/meta/recipes-devtools/strace/strace_4.10.bb
+++ b/meta/recipes-devtools/strace/strace_4.10.bb
@@ -9,6 +9,7 @@ SRC_URI = ${SOURCEFORGE_MIRROR}/strace/strace-${PV}.tar.xz \
file://strace-add-configure-options.patch \
file://Makefile-ptest.patch \
file://run-ptest \
+ file://sigreturn.c-fix-build-for-aarch64.patch \
SRC_URI[md5sum] = 107a5be455493861189e9b57a3a51912
--
1.7.9.5
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 3/6] libepoxy: DEPENDS on virtual/mesa
Fixed do_configure error:
configure: error: libX11 headers (libx11-dev) required to build with GLX support
and do_compile error:
../include/epoxy/egl_generated.h:10:29: fatal error: EGL/eglplatform.h: No such
file or directory
#include EGL/eglplatform.h
The dependencies form its README.md:
* automake
* libegl1-mesa-dev
* xutils-dev
Signed-off-by: Robert Yang liezhi.y...@windriver.com
---
meta/recipes-graphics/libepoxy/libepoxy_1.2.bb |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/recipes-graphics/libepoxy/libepoxy_1.2.bb
b/meta/recipes-graphics/libepoxy/libepoxy_1.2.bb
index 4357331..50b9d2c 100644
--- a/meta/recipes-graphics/libepoxy/libepoxy_1.2.bb
+++ b/meta/recipes-graphics/libepoxy/libepoxy_1.2.bb
@@ -13,4 +13,4 @@ S = ${WORKDIR}/git
inherit autotools pkgconfig
-DEPENDS = util-macros
+DEPENDS = util-macros virtual/mesa
--
1.7.9.5
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 6/6] libunwind: fix build with aarch64
Referred to RP's fix for x86 and x86-64:
34d517a5626ce2465f776367349bd9e66bf8ed1f
libunwind: Build with gold to avoid build failures
Fixed:
aarch64-poky-linux/4.9.2/ld: copy reloc against protected
`_Uaarch64_local_addr_space' is invalid
aarch64-poky-linux/4.9.2/ld: failed to set dynamic section sizes: Bad value
aarch64-poky-linux/4.9.2/ld: copy reloc against protected
`_Uaarch64_local_addr_space' is invalid
aarch64-poky-linux/4.9.2/ld: failed to set dynamic section sizes: Bad value
| collect2: error: ld returned 1 exit status
Signed-off-by: Richard Purdie richard.pur...@linuxfoundation.org
Signed-off-by: Robert Yang liezhi.y...@windriver.com
---
meta/recipes-support/libunwind/libunwind.inc |2 ++
1 file changed, 2 insertions(+)
diff --git a/meta/recipes-support/libunwind/libunwind.inc
b/meta/recipes-support/libunwind/libunwind.inc
index 74afba1..56905c2 100644
--- a/meta/recipes-support/libunwind/libunwind.inc
+++ b/meta/recipes-support/libunwind/libunwind.inc
@@ -26,6 +26,8 @@ LIBATOMICS ?=
LDFLAGS_append_x86 = -fuse-ld=gold
LDFLAGS_append_x86-64 = -fuse-ld=gold
+LDFLAGS_append_aarch64 = -fuse-ld=gold
+
DEPENDS += ${DEPLIBATOMICS}
DEPLIBATOMICS_armv5 = libatomics-ops
DEPLIBATOMICS_armv4 = libatomics-ops
--
1.7.9.5
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/6] libxml2: fix python path and add libxml2-python
We have libxml2-python for native and nativesdk, but don't have it for
target, and can't find the reason from the git log, libxml2-python is
widely used, after looked into it's configure.in, we can add it
by PACKAGECONFIG.
The previous --with-python=${STAGING_BINDIR}/python is incorrect, it
acted as work becase it's conigure can check automatically, python is in
${STAGING_BINDIR_NATIVE}/${PYTHON_PN}-native/${PYTHON_PN}, as known as
${PYTHON}.
Add python to PACKAGECONFIG, since createrepo rdepends on
libxml2-python, otherwise the target createrepo can't work.
Signed-off-by: Robert Yang liezhi.y...@windriver.com
---
meta/recipes-core/libxml/libxml2.inc | 19 +--
1 file changed, 9 insertions(+), 10 deletions(-)
diff --git a/meta/recipes-core/libxml/libxml2.inc
b/meta/recipes-core/libxml/libxml2.inc
index 1314bbf..1c62254 100644
--- a/meta/recipes-core/libxml/libxml2.inc
+++ b/meta/recipes-core/libxml/libxml2.inc
@@ -9,8 +9,6 @@ LIC_FILES_CHKSUM =
file://Copyright;md5=2044417e2e5006b65a8b9067b683fcf1 \
file://list.c;beginline=4;endline=13;md5=cdbfa3dee51c099edb04e39f762ee907 \
file://trio.c;beginline=5;endline=14;md5=6c025753c86d958722ec76e94cae932e
-DEPENDS_class-nativesdk = nativesdk-python
-DEPENDS_class-native = python-native
DEPENDS =+ zlib
SRC_URI = ftp://xmlsoft.org/libxml2/libxml2-${PV}.tar.gz;name=libtar \
@@ -37,16 +35,17 @@ do_configure_prepend () {
sed -i -e '/.*ansidecl.h.*/d' ${S}/configure.ac
}
-do_configure_prepend_class-nativesdk () {
- # Ensure we get the correct site-packages path
- export PYTHON_SITE_PACKAGES=${PYTHON_SITEPACKAGES_DIR}
-}
+export PYTHON_SITE_PACKAGES=${PYTHON_SITEPACKAGES_DIR}
+
+PACKAGECONFIG ??= python
+PACKAGECONFIG_linuxstdbase ??=
+PACKAGECONFIG[python] =
--with-python=${PYTHON},--without-python,python,python-core
# WARNING: zlib is require for RPM use
-EXTRA_OECONF = --without-python --without-debug --without-legacy
--with-catalog --without-docbook --with-c14n --without-lzma --with-fexceptions
-EXTRA_OECONF_class-native = --with-python=${STAGING_BINDIR}/python
--without-legacy --without-docbook --with-c14n --without-lzma --with-zlib
-EXTRA_OECONF_class-nativesdk = --with-python=${STAGING_BINDIR}/python
--without-legacy --without-docbook --with-c14n --without-lzma --with-zlib
-EXTRA_OECONF_linuxstdbase = --without-python --with-debug --with-legacy
--with-docbook --with-c14n --without-lzma --with-zlib
+EXTRA_OECONF = --without-debug --without-legacy --with-catalog
--without-docbook --with-c14n --without-lzma --with-fexceptions
+EXTRA_OECONF_class-native = --without-legacy --without-docbook --with-c14n
--without-lzma --with-zlib
+EXTRA_OECONF_class-nativesdk = --without-legacy --without-docbook --with-c14n
--without-lzma --with-zlib
+EXTRA_OECONF_linuxstdbase = --with-debug --with-legacy --with-docbook
--with-c14n --without-lzma --with-zlib
# required for pythong binding
export HOST_SYS
--
1.7.9.5
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 0/6] meta: 6 fixes
The following changes since commit 8d207e55031c0b93387e728f4312b8cb34ad5b12: libgpg-error 1.18: simplify tupple handling and add armv8b support (2015-04-13 22:32:06 +0100) are available in the git repository at: git://git.openembedded.org/openembedded-core-contrib rbt/6fixes http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=rbt/6fixes Robert Yang (6): libxml2: fix python path and add libxml2-python cracklib: add python support back libepoxy: DEPENDS on virtual/mesa strace: fix build for aarch64 aspell: inherit binconfig-disabled libunwind: fix build with aarch64 meta/recipes-core/libxml/libxml2.inc | 19 ++- .../strace/sigreturn.c-fix-build-for-aarch64.patch | 34 meta/recipes-devtools/strace/strace_4.10.bb|1 + meta/recipes-extended/cracklib/cracklib_2.9.2.bb | 28 +--- meta/recipes-graphics/libepoxy/libepoxy_1.2.bb |2 +- meta/recipes-support/aspell/aspell_0.60.6.1.bb |4 ++- meta/recipes-support/libunwind/libunwind.inc |2 ++ 7 files changed, 74 insertions(+), 16 deletions(-) create mode 100644 meta/recipes-devtools/strace/strace/sigreturn.c-fix-build-for-aarch64.patch -- 1.7.9.5 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 5/6] aspell: inherit binconfig-disabled
There is a pspell-config.
Signed-off-by: Robert Yang liezhi.y...@windriver.com
---
meta/recipes-support/aspell/aspell_0.60.6.1.bb |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/meta/recipes-support/aspell/aspell_0.60.6.1.bb
b/meta/recipes-support/aspell/aspell_0.60.6.1.bb
index f546721..7cf17d6 100644
--- a/meta/recipes-support/aspell/aspell_0.60.6.1.bb
+++ b/meta/recipes-support/aspell/aspell_0.60.6.1.bb
@@ -25,4 +25,6 @@ FILES_libpspell = ${libdir}/libpspell.so.*
FILES_${PN}-dev += ${bindir}/pspell-config
ARM_INSTRUCTION_SET = arm
-inherit autotools-brokensep gettext texinfo
+inherit autotools-brokensep gettext texinfo binconfig-disabled
+
+BINCONFIG = ${bindir}/pspell-config
--
1.7.9.5
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [RFC] allow installation of multiple kernels in the rootfs
Hi Bruce,
thanks for the initial feedback, I guess I'll need a bit more help/guidance,
so I hope that others will also join the discussion.
On Mon, Apr 13, 2015 at 11:31:50AM -0400, Bruce Ashfield wrote:
I'd be happy to hear some feedback on this and I'm willing to tune anything
that might be necessary in order to get this feature merged into core.
My big concerns are around compatibility/consistency and the wreckage
that changing
the package names will cause for the system.
I'm competent in packaging .. but not an expert, so I'm hoping that
Richard and folks
like Mark Hatle can jump in with options to allow the package managers
to deal with
this as well.
+1, hoping to hear their feedback as well.
diff --git a/meta/classes/kernel-module-split.bbclass
b/meta/classes/kernel-module-split.bbclass
index 9a95b72..dbfad01 100644
--- a/meta/classes/kernel-module-split.bbclass
+++ b/meta/classes/kernel-module-split.bbclass
@@ -28,7 +28,7 @@ do_install_append() {
PACKAGESPLITFUNCS_prepend = split_kernel_module_packages
-KERNEL_MODULES_META_PACKAGE ?= kernel-modules
+KERNEL_MODULES_META_PACKAGE ?= ${KERNEL_PACKAGE_NAME}-modules
The problem that I have with this is one of wider consistency and eco
system layers.
Before, I could count on the fact that kernel-modules got me all the
built kernel
modules for any kernel provided by the virtual/kernel dependency. Now
I have to know
if a layer changes this variable and/or update all my package lists to
use this variable.
Not impossible, but preferably something to avoid.
Would it make sense to introduce some virtual/kernel-modules, similar to
virtual/kernel?
This way we would have one kernel and kernel modules provider which can always
be referenced by a clear name.
python split_kernel_module_packages () {
import re
@@ -178,12 +178,15 @@ python split_kernel_module_packages () {
module_deps = parse_depmod()
module_regex = '^(.*)\.k?o$'
-module_pattern = 'kernel-module-%s'
+
+kernel_package_name = d.getVar('KERNEL_PACKAGE_NAME')
+
+module_pattern = kernel_package_name + '-module-%s'
postinst = d.getVar('pkg_postinst_modules', True)
postrm = d.getVar('pkg_postrm_modules', True)
-modules = do_split_packages(d, root='/lib/modules',
file_regex=module_regex, output_pattern=module_pattern, description='%s
kernel module', postinst=postinst, postrm=postrm, recursive=True,
hook=frob_metadata, extra_depends='kernel-%s' % (d.getVar(KERNEL_VERSION,
True)))
+modules = do_split_packages(d, root='/lib/modules',
file_regex=module_regex, output_pattern=module_pattern, description='%s
kernel module', postinst=postinst, postrm=postrm, recursive=True,
hook=frob_metadata, extra_depends='%s-%s' % (kernel_package_name,
d.getVar(KERNEL_VERSION, True)))
if modules:
metapkg = d.getVar('KERNEL_MODULES_META_PACKAGE', True)
d.appendVar('RDEPENDS_' + metapkg, ' '+' '.join(modules))
diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index 70ed95b..c7c6c3e 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -6,11 +6,43 @@ DEPENDS += virtual/${TARGET_PREFIX}binutils
virtual/${TARGET_PREFIX}gcc kmod-na
# we include gcc above, we dont need virtual/libc
INHIBIT_DEFAULT_DEPS = 1
+
+KERNEL_PACKAGE_NAME =
You do set a default to kernel in the processvars routine below, but
what's the harm
in setting this to kernel as well ?
Roger that.
+
+# adds a suffix to the kernel name, allowing to change the naming scheme of
+# the kernel packages, result will be kernel-${KERNEL_PACKAGE_EXTRA_NAME}
+KERNEL_PACKAGE_EXTRA_NAME ?=
+
KERNEL_IMAGETYPE ?= zImage
INITRAMFS_IMAGE ?=
INITRAMFS_TASK ?=
INITRAMFS_IMAGE_BUNDLE ?=
+python kernel_processvars_handler () {
+extra_name = e.data.getVar('KERNEL_PACKAGE_EXTRA_NAME', True) or
+default_name = e.data.getVar('KERNEL_PACKAGE_NAME', True) or kernel
+if extra_name != :
+new_kernel_package_name = '%s-%s' % (default_name, extra_name)
+e.data.setVar('KERNEL_PACKAGE_NAME', new_kernel_package_name)
+localversion = e.data.getVar('KERNEL_LOCALVERSION', True) or
+if (localversion == ):
+localversion = -%s % extra_name
+else:
+localversion = %s+%s % (localversion, extra_name)
+
+e.data.setVar('KERNEL_LOCALVERSION', localversion)
+# if name has been tuned, add localversion to the kernel src path
+# in order to avoid conflicts with virtual/kernel
+e.data.setVar('KERNEL_SRC_PATH', '/usr/src/%s%s' %
(new_kernel_package_name, localversion))
+else:
+e.data.setVar('KERNEL_PACKAGE_NAME', '%s' % default_name)
+
+}
Both the extra time to process this and the now (relatively) hidden
complexity and
processing the variables is a concern for
[OE-core] [PATCH 3/4] libgcc: remove libgcov-dev from PACKAGES
There should be only one dev and dbg package.
Signed-off-by: Robert Yang liezhi.y...@windriver.com
---
.../packagegroup-core-standalone-sdk-target.bb |1 -
meta/recipes-devtools/gcc/libgcc.inc |5 +
2 files changed, 1 insertion(+), 5 deletions(-)
diff --git
a/meta/recipes-core/packagegroups/packagegroup-core-standalone-sdk-target.bb
b/meta/recipes-core/packagegroups/packagegroup-core-standalone-sdk-target.bb
index 154a55c..5d1ce97 100644
--- a/meta/recipes-core/packagegroups/packagegroup-core-standalone-sdk-target.bb
+++ b/meta/recipes-core/packagegroups/packagegroup-core-standalone-sdk-target.bb
@@ -7,7 +7,6 @@ inherit packagegroup
RDEPENDS_${PN} = \
libgcc \
libgcc-dev \
-libgcov-dev \
libstdc++ \
libstdc++-dev \
${LIBC_DEPENDENCIES} \
diff --git a/meta/recipes-devtools/gcc/libgcc.inc
b/meta/recipes-devtools/gcc/libgcc.inc
index 21cb8c1..35432c7 100644
--- a/meta/recipes-devtools/gcc/libgcc.inc
+++ b/meta/recipes-devtools/gcc/libgcc.inc
@@ -6,7 +6,6 @@ PACKAGES = \
${PN} \
${PN}-dev \
${PN}-dbg \
-libgcov-dev \
# All libgcc source is marked with the exception.
@@ -26,10 +25,9 @@ FILES_${PN}-dev = \
${libdir}/${TARGET_SYS}/${BINV}/n32 \
${libdir}/${TARGET_SYS}/${BINV}/libgcc* \
${@base_conditional('TARGET_SYS_NO_EXTENSION', '${TARGET_SYS}', '',
'${libdir}/${TARGET_SYS_NO_EXTENSION}', d)} \
-
-FILES_libgcov-dev = \
${libdir}/${TARGET_SYS}/${BINV}/libgcov.a \
+
FILES_${PN}-dbg += ${base_libdir}/.debug/
LIBGCCBUILDTREENAME = gcc-build-internal-
@@ -40,5 +38,4 @@ do_package_write_deb[depends] +=
virtual/${MLPREFIX}libc:do_packagedata
do_package_write_rpm[depends] += virtual/${MLPREFIX}libc:do_packagedata
INSANE_SKIP_${PN}-dev = staticdev
-INSANE_SKIP_${MLPREFIX}libgcov-dev = staticdev
--
1.7.9.5
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 0/4] meta: remove extra dev and dbg from PACKAGES
Hello, I had sent xz and curl in the previous thread, but not got merged, any comments on them, please ? // Robert The following changes since commit 8d207e55031c0b93387e728f4312b8cb34ad5b12: libgpg-error 1.18: simplify tupple handling and add armv8b support (2015-04-13 22:32:06 +0100) are available in the git repository at: git://git.openembedded.org/openembedded-core-contrib rbt/dev http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=rbt/dev Robert Yang (4): xz: remove liblzma-dev and liblzma-dbg from PACKAGES curl: remove extra dev and staticdev from PACKAGES libgcc: remove libgcov-dev from PACKAGES gcc-target: remove gcc-plugin-dev from PACKAGES .../packagegroup-core-standalone-sdk-target.bb |1 - meta/recipes-devtools/gcc/gcc-target.inc |3 --- meta/recipes-devtools/gcc/libgcc.inc |5 + meta/recipes-extended/xz/xz_5.2.1.bb |8 +--- meta/recipes-support/curl/curl_7.41.0.bb | 11 +-- 5 files changed, 3 insertions(+), 25 deletions(-) -- 1.7.9.5 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 2/4] curl: remove extra dev and staticdev from PACKAGES
There should be only one dev and dbg package.
Signed-off-by: Robert Yang liezhi.y...@windriver.com
---
meta/recipes-support/curl/curl_7.41.0.bb | 11 +--
1 file changed, 1 insertion(+), 10 deletions(-)
diff --git a/meta/recipes-support/curl/curl_7.41.0.bb
b/meta/recipes-support/curl/curl_7.41.0.bb
index c3c3c0b..49ce716 100644
--- a/meta/recipes-support/curl/curl_7.41.0.bb
+++ b/meta/recipes-support/curl/curl_7.41.0.bb
@@ -42,18 +42,9 @@ do_install_append() {
oe_multilib_header curl/curlbuild.h
}
-PACKAGES =+ lib${BPN} lib${BPN}-dev lib${BPN}-staticdev lib${BPN}-doc
+PACKAGES =+ lib${BPN}
FILES_lib${BPN} = ${libdir}/lib*.so.*
RRECOMMENDS_lib${BPN} += ca-certificates
-FILES_lib${BPN}-dev = ${includedir} \
- ${libdir}/lib*.so \
- ${libdir}/lib*.la \
- ${libdir}/pkgconfig \
- ${datadir}/aclocal \
- ${bindir}/*-config
-FILES_lib${BPN}-staticdev = ${libdir}/lib*.a
-FILES_lib${BPN}-doc = ${mandir}/man3 \
- ${mandir}/man1/curl-config.1
BBCLASSEXTEND = native nativesdk
--
1.7.9.5
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 4/4] gcc-target: remove gcc-plugin-dev from PACKAGES
There should be only one dev and dbg package.
Signed-off-by: Robert Yang liezhi.y...@windriver.com
---
meta/recipes-devtools/gcc/gcc-target.inc |3 ---
1 file changed, 3 deletions(-)
diff --git a/meta/recipes-devtools/gcc/gcc-target.inc
b/meta/recipes-devtools/gcc/gcc-target.inc
index 4c3eea6..e348517 100644
--- a/meta/recipes-devtools/gcc/gcc-target.inc
+++ b/meta/recipes-devtools/gcc/gcc-target.inc
@@ -19,7 +19,6 @@ PACKAGES = \
g77 g77-symlinks \
gfortran gfortran-symlinks \
gcov gcov-symlinks \
-${PN}-plugin-dev \
${PN}-doc \
${PN}-dev \
${PN}-dbg \
@@ -47,8 +46,6 @@ FILES_${PN}-dbg += \
FILES_${PN}-dev = \
${gcclibdir}/${TARGET_SYS}/${BINV}/lib*${SOLIBSDEV} \
${libexecdir}/gcc/${TARGET_SYS}/${BINV}/lib*${SOLIBSDEV} \
-
-FILES_${PN}-plugin-dev = \
${gcclibdir}/${TARGET_SYS}/${BINV}/plugin/include/ \
${libexecdir}/gcc/${TARGET_SYS}/${BINV}/plugin/gengtype \
${gcclibdir}/${TARGET_SYS}/${BINV}/plugin/gtype.state \
--
1.7.9.5
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 0/6] Package Upgrades
The following changes since commit 8d207e55031c0b93387e728f4312b8cb34ad5b12:
libgpg-error 1.18: simplify tupple handling and add armv8b support
(2015-04-13 22:32:06 +0100)
are available in the git repository at:
git://git.openembedded.org/openembedded-core-contrib rbt/pu
http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=rbt/pu
Chong Lu (2):
gstreamer: change priv_gst_parse_yylex arguments
webkit-gtk: ANGLE doesn't build with bison 3
Robert Yang (4):
gnu-efi: 3.0.1 - 3.0.2
tcl: 8.6.3 - 8.6.4
python-git: 0.3.6 - 1.0.0
bison: 2.7.1 - 3.0.4
.../gnu-efi/{gnu-efi_3.0.1.bb = gnu-efi_3.0.2.bb} |4 +--
.../bison/bison/dont-depend-on-help2man.patch | 32 ---
.../bison/bison/fix_cross_manpage_building.patch | 19 ---
.../bison/{bison_2.7.1.bb = bison_3.0.4.bb} | 20 ++--
.../{python-git_0.3.6.bb = python-git_1.0.0.bb} |4 +--
.../tcltk/{tcl_8.6.3.bb = tcl_8.6.4.bb} | 16 +-
...mer-change-priv_gst_parse_yylex-arguments.patch | 33
.../gstreamer/gstreamer_0.10.36.bb |1 +
...bkit-gtk-ANGLE-doesn-t-build-with-bison-3.patch | 26 +++
meta/recipes-sato/webkit/webkit-gtk_1.8.3.bb |1 +
10 files changed, 82 insertions(+), 74 deletions(-)
rename meta/recipes-bsp/gnu-efi/{gnu-efi_3.0.1.bb = gnu-efi_3.0.2.bb} (93%)
delete mode 100644
meta/recipes-devtools/bison/bison/dont-depend-on-help2man.patch
delete mode 100644
meta/recipes-devtools/bison/bison/fix_cross_manpage_building.patch
rename meta/recipes-devtools/bison/{bison_2.7.1.bb = bison_3.0.4.bb} (70%)
rename meta/recipes-devtools/python/{python-git_0.3.6.bb =
python-git_1.0.0.bb} (85%)
rename meta/recipes-devtools/tcltk/{tcl_8.6.3.bb = tcl_8.6.4.bb} (81%)
create mode 100644
meta/recipes-multimedia/gstreamer/gstreamer-0.10.36/gstreamer-change-priv_gst_parse_yylex-arguments.patch
create mode 100644
meta/recipes-sato/webkit/files/webkit-gtk-ANGLE-doesn-t-build-with-bison-3.patch
--
1.7.9.5
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 6/6] webkit-gtk: ANGLE doesn't build with bison 3
From: Chong Lu chong...@windriver.com
Use %lex-param to set YYLEX_PARAM.
Signed-off-by: Chong Lu chong...@windriver.com
---
...bkit-gtk-ANGLE-doesn-t-build-with-bison-3.patch | 26
meta/recipes-sato/webkit/webkit-gtk_1.8.3.bb |1 +
2 files changed, 27 insertions(+)
create mode 100644
meta/recipes-sato/webkit/files/webkit-gtk-ANGLE-doesn-t-build-with-bison-3.patch
diff --git
a/meta/recipes-sato/webkit/files/webkit-gtk-ANGLE-doesn-t-build-with-bison-3.patch
b/meta/recipes-sato/webkit/files/webkit-gtk-ANGLE-doesn-t-build-with-bison-3.patch
new file mode 100644
index 000..e7e9083
--- /dev/null
+++
b/meta/recipes-sato/webkit/files/webkit-gtk-ANGLE-doesn-t-build-with-bison-3.patch
@@ -0,0 +1,26 @@
+webkit-gtk: ANGLE doesn't build with bison 3
+
+Use %lex-param to set YYLEX_PARAM.
+
+Upstream-Status: Pending
+
+Signed-off-by: Chong Lu chong...@windriver.com
+---
+ Source/ThirdParty/ANGLE/src/compiler/glslang.y | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/Source/ThirdParty/ANGLE/src/compiler/glslang.y
b/Source/ThirdParty/ANGLE/src/compiler/glslang.y
+index ec1a85c..15723cc 100644
+--- a/Source/ThirdParty/ANGLE/src/compiler/glslang.y
b/Source/ThirdParty/ANGLE/src/compiler/glslang.y
+@@ -32,6 +32,7 @@ WHICH GENERATES THE GLSL ES PARSER (glslang_tab.cpp AND
glslang_tab.h).
+ %expect 1 /* One shift reduce conflict because of if | else */
+ %pure-parser
+ %parse-param {TParseContext* context}
++%lex-param {YYLEX_PARAM}
+
+ %union {
+ struct {
+--
+1.9.1
+
diff --git a/meta/recipes-sato/webkit/webkit-gtk_1.8.3.bb
b/meta/recipes-sato/webkit/webkit-gtk_1.8.3.bb
index 15c73cf..3f19c2d 100644
--- a/meta/recipes-sato/webkit/webkit-gtk_1.8.3.bb
+++ b/meta/recipes-sato/webkit/webkit-gtk_1.8.3.bb
@@ -26,6 +26,7 @@ SRC_URI = \
file://obsolete_automake_macros.patch \
file://0001-Enable-mips64-build.patch \
file://aarch64.patch \
+ file://webkit-gtk-ANGLE-doesn-t-build-with-bison-3.patch \
SRC_URI[md5sum] = dcbf9d5e2e6391f857c29a57528b32a6
--
1.7.9.5
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 5/6] gstreamer: change priv_gst_parse_yylex arguments
From: Chong Lu chong...@windriver.com
Change priv_gst_parse_yylex to fit new bison version, else we will
get following error:
| grammar.tab.c: In function 'priv_gst_parse_yyparse':
| grammar.tab.c:67:25: error: too few arguments to function
'priv_gst_parse_yylex'
| #define yylex priv_gst_parse_yylex
| ^
Signed-off-by: Chong Lu chong...@windriver.com
---
...mer-change-priv_gst_parse_yylex-arguments.patch | 33
.../gstreamer/gstreamer_0.10.36.bb |1 +
2 files changed, 34 insertions(+)
create mode 100644
meta/recipes-multimedia/gstreamer/gstreamer-0.10.36/gstreamer-change-priv_gst_parse_yylex-arguments.patch
diff --git
a/meta/recipes-multimedia/gstreamer/gstreamer-0.10.36/gstreamer-change-priv_gst_parse_yylex-arguments.patch
b/meta/recipes-multimedia/gstreamer/gstreamer-0.10.36/gstreamer-change-priv_gst_parse_yylex-arguments.patch
new file mode 100644
index 000..bf93cb2
--- /dev/null
+++
b/meta/recipes-multimedia/gstreamer/gstreamer-0.10.36/gstreamer-change-priv_gst_parse_yylex-arguments.patch
@@ -0,0 +1,33 @@
+gstreamer: change priv_gst_parse_yylex arguments
+
+Change priv_gst_parse_yylex to fit new bison version, else we will
+get following error:
+
+| grammar.tab.c: In function 'priv_gst_parse_yyparse':
+| grammar.tab.c:67:25: error: too few arguments to function
'priv_gst_parse_yylex'
+| #define yylex priv_gst_parse_yylex
+| ^
+
+Upstream-Status: Pending
+
+Signed-off-by: Chong Lu chong...@windriver.com
+---
+ gst/parse/grammar.y | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/gst/parse/grammar.y b/gst/parse/grammar.y
+index 24fc87b..24fe906 100644
+--- a/gst/parse/grammar.y
b/gst/parse/grammar.y
+@@ -36,7 +36,7 @@
+
+ typedef void* yyscan_t;
+
+-int priv_gst_parse_yylex (void * yylval_param , yyscan_t yyscanner);
++int priv_gst_parse_yylex (yyscan_t yyscanner);
+ int priv_gst_parse_yylex_init (yyscan_t scanner);
+ int priv_gst_parse_yylex_destroy (yyscan_t scanner);
+ struct yy_buffer_state * priv_gst_parse_yy_scan_string (char* , yyscan_t);
+--
+1.9.1
+
diff --git a/meta/recipes-multimedia/gstreamer/gstreamer_0.10.36.bb
b/meta/recipes-multimedia/gstreamer/gstreamer_0.10.36.bb
index f08908a..5b30603 100644
--- a/meta/recipes-multimedia/gstreamer/gstreamer_0.10.36.bb
+++ b/meta/recipes-multimedia/gstreamer/gstreamer_0.10.36.bb
@@ -15,6 +15,7 @@ SRC_URI =
http://gstreamer.freedesktop.org/src/gstreamer/gstreamer-${PV}.tar.bz
file://check_fix.patch \
file://gst-inspect-check-error.patch \
file://0001-baseparse-Fix-self-comparison-always-evaluates-to-tr.patch \
+ file://gstreamer-change-priv_gst_parse_yylex-arguments.patch \
SRC_URI[md5sum] = a0cf7d6877f694a1a2ad2b4d1ecb890b
--
1.7.9.5
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 2/6] tcl: 8.6.3 - 8.6.4
The LIC_FILES_CHKSUM has been changed since 2 extra spaces in the end
were moved.
Signed-off-by: Robert Yang liezhi.y...@windriver.com
---
.../tcltk/{tcl_8.6.3.bb = tcl_8.6.4.bb} | 16
1 file changed, 8 insertions(+), 8 deletions(-)
rename meta/recipes-devtools/tcltk/{tcl_8.6.3.bb = tcl_8.6.4.bb} (81%)
diff --git a/meta/recipes-devtools/tcltk/tcl_8.6.3.bb
b/meta/recipes-devtools/tcltk/tcl_8.6.4.bb
similarity index 81%
rename from meta/recipes-devtools/tcltk/tcl_8.6.3.bb
rename to meta/recipes-devtools/tcltk/tcl_8.6.4.bb
index 73c0d25..8e92b3e 100644
--- a/meta/recipes-devtools/tcltk/tcl_8.6.3.bb
+++ b/meta/recipes-devtools/tcltk/tcl_8.6.4.bb
@@ -4,12 +4,12 @@ SECTION = devel/tcltk
# http://www.tcl.tk/software/tcltk/license.html
LICENSE = tcl BSD-3-Clause
-LIC_FILES_CHKSUM =
file://../license.terms;md5=3c6f62c07835353e36f0db550ccfb65a \
-file://../compat/license.terms;md5=3c6f62c07835353e36f0db550ccfb65a \
-file://../library/license.terms;md5=3c6f62c07835353e36f0db550ccfb65a \
-file://../macosx/license.terms;md5=3c6f62c07835353e36f0db550ccfb65a \
-file://../tests/license.terms;md5=3c6f62c07835353e36f0db550ccfb65a \
-file://../win/license.terms;md5=3c6f62c07835353e36f0db550ccfb65a \
+LIC_FILES_CHKSUM =
file://../license.terms;md5=058f6229798281bbcac4239c788cfa38 \
+file://../compat/license.terms;md5=058f6229798281bbcac4239c788cfa38 \
+file://../library/license.terms;md5=058f6229798281bbcac4239c788cfa38 \
+file://../macosx/license.terms;md5=058f6229798281bbcac4239c788cfa38 \
+file://../tests/license.terms;md5=058f6229798281bbcac4239c788cfa38 \
+file://../win/license.terms;md5=058f6229798281bbcac4239c788cfa38 \
DEPENDS = tcl-native zlib
@@ -24,8 +24,8 @@ SRC_URI = ${BASE_SRC_URI} \
file://alter-includedir.patch \
file://run-ptest \
-SRC_URI[md5sum] = db382feca91754b7f93da16dc4cdad1f
-SRC_URI[sha256sum] =
6ce0778de0d50daaa9c345d7c1fd1288fb658f674028812e7992e3051005
+SRC_URI[md5sum] = d7cbb91f1ded1919370a30edd1534304
+SRC_URI[sha256sum] =
9e6ed94c981c1d0c5f5fefb8112d06c6bf4d050a7327e95e71d417c416519c8d
SRC_URI_class-native = ${BASE_SRC_URI}
--
1.7.9.5
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 4/6] bison: 2.7.1 - 3.0.4
* Based on Chong Lu's previous upgrade to 3.0.2
* Remove unneeded patches:
dont-depend-on-help2man.patch and
fix_cross_manpage_building.patch
Signed-off-by: Chong Lu chong...@windriver.com
Signed-off-by: Robert Yang liezhi.y...@windriver.com
---
.../bison/bison/dont-depend-on-help2man.patch | 32
.../bison/bison/fix_cross_manpage_building.patch | 19
.../bison/{bison_2.7.1.bb = bison_3.0.4.bb} | 20 ++--
3 files changed, 9 insertions(+), 62 deletions(-)
delete mode 100644
meta/recipes-devtools/bison/bison/dont-depend-on-help2man.patch
delete mode 100644
meta/recipes-devtools/bison/bison/fix_cross_manpage_building.patch
rename meta/recipes-devtools/bison/{bison_2.7.1.bb = bison_3.0.4.bb} (70%)
diff --git a/meta/recipes-devtools/bison/bison/dont-depend-on-help2man.patch
b/meta/recipes-devtools/bison/bison/dont-depend-on-help2man.patch
deleted file mode 100644
index 21b44bf..000
--- a/meta/recipes-devtools/bison/bison/dont-depend-on-help2man.patch
+++ /dev/null
@@ -1,32 +0,0 @@
-Upstream-Status: Inappropriate
-
-Signed-off-by: Marko Lindqvist cazf...@gmail.com
-diff -Nurd bison-2.7/doc/Makefile.am bison-2.7/doc/Makefile.am
bison-2.7/doc/Makefile.am 2012-12-09 17:51:03.0 +0200
-+++ bison-2.7/doc/Makefile.am 2013-01-02 06:49:50.804894071 +0200
-@@ -52,15 +52,11 @@
- ## Man Pages. ##
- ## --- ##
-
--dist_man_MANS = $(srcdir)/bison.1
--
--EXTRA_DIST += $(dist_man_MANS:.1=.x) common.x
--MAINTAINERCLEANFILES += $(dist_man_MANS)
-+EXTRA_DIST += bison.x common.x
-
- # Depend on configure to get version number changes.
- common_dep = $(top_srcdir)/configure $(srcdir)/common.x
- srcsrcdir = $(top_srcdir)/bin
--$(srcdir)/bison.1: $(common_dep) $(top_srcdir)/src/getargs.c
-
- # Differences to ignore when comparing the man page (the date).
- remove_time_stamp = \
-@@ -94,8 +90,6 @@
- fi
- $(AM_V_at)rm -f $@*.t
-
--nodist_man_MANS = yacc.1
--
- ## -- ##
- ## Graphviz examples generation. ##
- ## -- ##
diff --git a/meta/recipes-devtools/bison/bison/fix_cross_manpage_building.patch
b/meta/recipes-devtools/bison/bison/fix_cross_manpage_building.patch
deleted file mode 100644
index 8b68379..000
--- a/meta/recipes-devtools/bison/bison/fix_cross_manpage_building.patch
+++ /dev/null
@@ -1,19 +0,0 @@
-Upstream-Status: Inappropriate [embedded specific]
-
-help2man is looking at the generated binary for help output. This does not
work for cross compilations. So taking out the local PREPATH (../src) directory
from path so that help2 man can find the native version of the bison in the
native sysroot directory.
-
-Date: 2010/06/28
-Signed-Off-By: Nitin A Kamble nitin.a.kam...@intel.com
-
-diff --git a/doc/Makefile.am b/doc/Makefile.am
-index c7f2755..af9453a 100644
a/doc/Makefile.am
-+++ b/doc/Makefile.am
-@@ -80,7 +80,6 @@ PREPATH = $(top_builddir)/src
- echo cd $$dir '' $(MAKE) $(AM_MAKEFLAGS) $$program\
- (cd $$dir $(MAKE) $(AM_MAKEFLAGS) $$program) || exit; \
- done
-- $(AM_V_at)PATH=$(PREPATH)$(PATH_SEPARATOR)$$PATH; \
- export PATH; \
- $(HELP2MAN) \
- --include=$*.x \
diff --git a/meta/recipes-devtools/bison/bison_2.7.1.bb
b/meta/recipes-devtools/bison/bison_3.0.4.bb
similarity index 70%
rename from meta/recipes-devtools/bison/bison_2.7.1.bb
rename to meta/recipes-devtools/bison/bison_3.0.4.bb
index 4a3ad15..0156201 100644
--- a/meta/recipes-devtools/bison/bison_2.7.1.bb
+++ b/meta/recipes-devtools/bison/bison_3.0.4.bb
@@ -9,28 +9,26 @@ LIC_FILES_CHKSUM =
file://COPYING;md5=d32239bcb673463ab874e80d47fae504
SECTION = devel
DEPENDS = bison-native flex-native
-BASE_SRC_URI = ${GNU_MIRROR}/bison/bison-${PV}.tar.xz \
- file://m4.patch \
-file://dont-depend-on-help2man.patch \
-
+SRC_URI = ${GNU_MIRROR}/bison/bison-${PV}.tar.xz \
+ file://m4.patch \
+
# No point in hardcoding path to m4, just use PATH
EXTRA_OECONF += M4=m4
-SRC_URI = ${BASE_SRC_URI} \
- file://fix_cross_manpage_building.patch \
-
-
-SRC_URI[md5sum] = 7be02eb973eccf388f1ae750fc09eed0
-SRC_URI[sha256sum] =
b409adcbf245baadb68d2f66accf6fdca5e282cafec1b865f4b5e963ba8ea7fb
+SRC_URI[md5sum] = c342201de104cc9ce0a21e0ad10d4021
+SRC_URI[sha256sum] =
a72428c7917bdf9fa93cb8181c971b6e22834125848cf1d03ce10b1bb0716fe1
LDFLAGS_prepend_libc-uclibc = -lrt
DEPENDS_class-native = gettext-minimal-native
-SRC_URI_class-native = ${BASE_SRC_URI}
inherit autotools gettext texinfo
acpaths = -I ${S}/m4
+do_compile_prepend() {
+ for i in mfcalc calc++ rpcalc; do mkdir -p ${B}/examples/$i; done
+}
+
do_install_append_class-native() {
create_wrapper
[OE-core] [PATCH 1/6] gnu-efi: 3.0.1 - 3.0.2
Signed-off-by: Robert Yang liezhi.y...@windriver.com
---
.../gnu-efi/{gnu-efi_3.0.1.bb = gnu-efi_3.0.2.bb} |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
rename meta/recipes-bsp/gnu-efi/{gnu-efi_3.0.1.bb = gnu-efi_3.0.2.bb} (93%)
diff --git a/meta/recipes-bsp/gnu-efi/gnu-efi_3.0.1.bb
b/meta/recipes-bsp/gnu-efi/gnu-efi_3.0.2.bb
similarity index 93%
rename from meta/recipes-bsp/gnu-efi/gnu-efi_3.0.1.bb
rename to meta/recipes-bsp/gnu-efi/gnu-efi_3.0.2.bb
index ad7f2e3..2b4f3f3 100644
--- a/meta/recipes-bsp/gnu-efi/gnu-efi_3.0.1.bb
+++ b/meta/recipes-bsp/gnu-efi/gnu-efi_3.0.2.bb
@@ -17,8 +17,8 @@ LIC_FILES_CHKSUM =
file://gnuefi/crt0-efi-arm.S;beginline=4;endline=9;md5=2240d
SRC_URI = ${SOURCEFORGE_MIRROR}/${BPN}/${BP}.tar.bz2 \
file://parallel-make-archives.patch \
-SRC_URI[md5sum] = c4099c443b6b0c2b04dedc33e7814ec0
-SRC_URI[sha256sum] =
e2e8d5940347eebfb00eaaeef107a8ba59e7838e40bc716c74d9a36fff648f1f
+SRC_URI[md5sum] = a9db2cabc01a2674715bd6aea2911f01
+SRC_URI[sha256sum] =
194b580ecdb1fad0e41914845ba064c279afb687855960b58693459e5537b4d7
COMPATIBLE_HOST = (x86_64.*|i.86.*|aarch64.*|arm.*)-linux
--
1.7.9.5
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 3/6] python-git: 0.3.6 - 1.0.0
Signed-off-by: Robert Yang liezhi.y...@windriver.com
---
.../{python-git_0.3.6.bb = python-git_1.0.0.bb} |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
rename meta/recipes-devtools/python/{python-git_0.3.6.bb =
python-git_1.0.0.bb} (85%)
diff --git a/meta/recipes-devtools/python/python-git_0.3.6.bb
b/meta/recipes-devtools/python/python-git_1.0.0.bb
similarity index 85%
rename from meta/recipes-devtools/python/python-git_0.3.6.bb
rename to meta/recipes-devtools/python/python-git_1.0.0.bb
index 80cdd7c..eea1543 100644
--- a/meta/recipes-devtools/python/python-git_0.3.6.bb
+++ b/meta/recipes-devtools/python/python-git_1.0.0.bb
@@ -11,8 +11,8 @@ DEPENDS = python-gitdb
SRC_URI =
http://pypi.python.org/packages/source/G/GitPython/GitPython-${PV}.tar.gz;
-SRC_URI[md5sum] = 87404ab9e0fcee81e660e932b3d9f2c6
-SRC_URI[sha256sum] =
f3f42ca085eedbd3a9956b5e639de58bbe77a119f6b3d5c3af27669a2322c4a9
+SRC_URI[md5sum] = c3833aad16d5660436e284d597ec1bec
+SRC_URI[sha256sum] =
c1b3e6fdd209040b6b1cb32ecbff989eeb2fb31b4e7078c3342d71ae8ef7352b
S = ${WORKDIR}/GitPython-${PV}
--
1.7.9.5
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/4] xz: remove liblzma-dev and liblzma-dbg from PACKAGES
There should be only one dev and dbg package.
Signed-off-by: Robert Yang liezhi.y...@windriver.com
---
meta/recipes-extended/xz/xz_5.2.1.bb |8 +---
1 file changed, 1 insertion(+), 7 deletions(-)
diff --git a/meta/recipes-extended/xz/xz_5.2.1.bb
b/meta/recipes-extended/xz/xz_5.2.1.bb
index a197f91..e0ae48f 100644
--- a/meta/recipes-extended/xz/xz_5.2.1.bb
+++ b/meta/recipes-extended/xz/xz_5.2.1.bb
@@ -14,9 +14,6 @@ LICENSE_${PN}-doc = GPLv2+
LICENSE_${PN}-dbg = GPLv2+
LICENSE_${PN}-locale = GPLv2+
LICENSE_liblzma = PD
-LICENSE_liblzma-dev = PD
-LICENSE_liblzma-staticdev = PD
-LICENSE_liblzma-dbg = PD
LIC_FILES_CHKSUM = file://COPYING;md5=c475b6c7dca236740ace4bba553e8e1c \
file://COPYING.GPLv2;md5=b234ee4d69f5fce4486a80fdaf4a4263 \
@@ -30,12 +27,9 @@ SRC_URI[sha256sum] =
b918b6648076e74f8d7ae19db5ee663df800049e187259faf5eb997a7b
inherit autotools gettext
-PACKAGES =+ liblzma liblzma-dev liblzma-staticdev liblzma-dbg
+PACKAGES =+ liblzma
FILES_liblzma = ${libdir}/liblzma*${SOLIBS}
-FILES_liblzma-dev = ${includedir}/lzma* ${libdir}/liblzma*${SOLIBSDEV}
${libdir}/liblzma.la ${libdir}/pkgconfig/liblzma.pc
-FILES_liblzma-staticdev = ${libdir}/liblzma.a
-FILES_liblzma-dbg = ${libdir}/.debug/liblzma*
BBCLASSEXTEND = native nativesdk
--
1.7.9.5
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] ghostscript: add objarch.h for armeb
From: Krishnanjanappa, Jagadeesh jagadeesh.krishnanjana...@caviumnetworks.com ghostscript application fails to fetch objarch.h file while building for armeb. The fetch failure is due to absence of this file in the default set of directories that the OpenEmbedded build system searches (i.e FILESPATH) for patches and files. This patch adds the required objarch.h file for armeb in one of the default locations where OpenEmbedded build system searches. Signed-off-by: Krishnanjanappa, Jagadeesh jagadeesh.krishnanjana...@caviumnetworks.com --- .../ghostscript/ghostscript/armeb/objarch.h| 40 ++ 1 file changed, 40 insertions(+) create mode 100644 meta/recipes-extended/ghostscript/ghostscript/armeb/objarch.h diff --git a/meta/recipes-extended/ghostscript/ghostscript/armeb/objarch.h b/meta/recipes-extended/ghostscript/ghostscript/armeb/objarch.h new file mode 100644 index 000..359097f --- /dev/null +++ b/meta/recipes-extended/ghostscript/ghostscript/armeb/objarch.h @@ -0,0 +1,40 @@ +/* Parameters derived from machine and compiler architecture. */ +/* This file is generated mechanically by genarch.c. */ + +/* Scalar alignments */ + +#define ARCH_ALIGN_SHORT_MOD 2 +#define ARCH_ALIGN_INT_MOD 4 +#define ARCH_ALIGN_LONG_MOD 4 +#define ARCH_ALIGN_PTR_MOD 4 +#define ARCH_ALIGN_FLOAT_MOD 4 +#define ARCH_ALIGN_DOUBLE_MOD 8 + +/* Scalar sizes */ + +#define ARCH_LOG2_SIZEOF_CHAR 0 +#define ARCH_LOG2_SIZEOF_SHORT 1 +#define ARCH_LOG2_SIZEOF_INT 2 +#define ARCH_LOG2_SIZEOF_LONG 2 +#define ARCH_LOG2_SIZEOF_LONG_LONG 3 +#define ARCH_SIZEOF_GX_COLOR_INDEX 8 +#define ARCH_SIZEOF_PTR 4 +#define ARCH_SIZEOF_FLOAT 4 +#define ARCH_SIZEOF_DOUBLE 8 +#define ARCH_FLOAT_MANTISSA_BITS 24 +#define ARCH_DOUBLE_MANTISSA_BITS 53 + +/* Unsigned max values */ + +#define ARCH_MAX_UCHAR ((unsigned char)0xff + (unsigned char)0) +#define ARCH_MAX_USHORT ((unsigned short)0x + (unsigned short)0) +#define ARCH_MAX_UINT ((unsigned int)~0 + (unsigned int)0) +#define ARCH_MAX_ULONG ((unsigned long)~0L + (unsigned long)0) + +/* Miscellaneous */ + +#define ARCH_IS_BIG_ENDIAN 1 +#define ARCH_PTRS_ARE_SIGNED 0 +#define ARCH_FLOATS_ARE_IEEE 1 +#define ARCH_ARITH_RSHIFT 2 +#define ARCH_DIV_NEG_POS_TRUNCATES 1 -- 1.8.2.3 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 5/5] bluetooth.bbclass: set bluez5 as the default BT stack
On 7 April 2015 at 00:41, Peter A. Bigot p...@pabigot.com wrote: Thank you. So, if I understand correctly, the effect of adding bluez5 to DISTRO_FEATURES_BACKFILL while keeping the current logic: # bluetooth support on the platform: # if bluetooth is not in DISTRO_FEATURES # else bluez5 if bluez5 is in DISTRO_FEATURES # else bluez4 is that bluez5 becomes the default and is in DISTRO_FEATURES automatically, and it stays the default even if bluez4 is also in DISTRO_FEATURES unless somebody adds bluez5 to DISTRO_FEATURES_BACKFILL_CONSIDERED at which point bluez4 takes precedence. If that understanding is correct, and reviewing http://www.yoctoproject.org/docs/latest/ref-manual/ref-manual.html#ref-features-backfill, it's not clear to me that it's the right approach. We're not backfilling bluetooth, which remains optional and continues to control whether either bluez4 or bluez5 is relevant. We're changing the default provider of bluetooth services, something that I think can reasonably be changed between releases, and something that 1.8 already controls (via explicit specification of bluez4 or bluez5 in DISTRO_FEATURES). My reasoning for backfilling bluez5 is that bluetooth.bbclass has a defined behaviour in 1.8: if bluetooth in DF: if bluez5 in DF: return bluez5 else: return bluez4 else: return There's no mention of a bluez4 DISTRO_FEATURE, just a bluetooth value to enable/disable Bluetooth in general, and the toggle between BlueZ 4 and 5 is the presence of a bluez5 DISTRO_FEATURE. We don't need to change the algorithm or create new DISTRO_FEATURE entries, as we have all the logic and items needed: by backfilling bluez5 into DISTRO_FEATURES we get the default switched, and distributions can flip back to bluez4 when upgrading to 1.9 by adding in meta-connectivity and wiping out bluez5 from DISTRO_FEATURES. Or am I alone in thinking this is the best approach going forward? Ross -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 3/6] libepoxy: DEPENDS on virtual/mesa
On 14 April 2015 at 14:50, Andreas Müller schnitzelt...@googlemail.com wrote: from the error I would DEPEND on virtual/egl Agreed. And there's no dependency on virtual/libx11 which the readme you quote suggests there should be. Presumably that dependency - if it's actually required - can be made conditional on the x11 DISTRO_FEATURE? Ross -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] kernel.bbclass: Fix race condition
Race condition between do_compile_kernelmodules and do_shared_workdir
tasks occurs when do_compilemodules changes files in include/generated/*
while do_shared_workdir tries to copy them to shared working directory.
Functionality of do_shared_workdir has been moved to separate function
mk_shared_workdir and called from do_kernel_compile. do_shared_workdir
left in the code as it may be used in many recipes.
[YOCTO #7321]
Signed-off-by: Ed Bartosh ed.bart...@linux.intel.com
Signed-off-by: Bruce Ashfield bruce.ashfi...@windriver.com
---
meta/classes/kernel.bbclass | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index 125ed88..aad430a 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -231,6 +231,8 @@ kernel_do_install() {
[ -e Module.symvers ] install -m 0644 Module.symvers
${D}/boot/Module.symvers-${KERNEL_VERSION}
install -d ${D}${sysconfdir}/modules-load.d
install -d ${D}${sysconfdir}/modprobe.d
+
+ mk_shared_workdir
}
do_install[prefuncs] += package_get_auto_pr
@@ -245,7 +247,7 @@ emit_depmod_pkgdata() {
PACKAGEFUNCS += emit_depmod_pkgdata
-do_shared_workdir () {
+mk_shared_workdir () {
cd ${B}
kerneldir=${STAGING_KERNEL_BUILDDIR}
@@ -289,6 +291,14 @@ do_shared_workdir () {
fi
}
+# NOTE!!! Functionality of do_shared_workdir has been moved to
mk_shared_workdir
+# and called from kernel_do_compile.
+# It caused race condition with do_compile_kernelmodules when it runs
+# in parallel with do_compile_kernelmodules
+do_shared_workdir () {
+ :
+}
+
# We don't need to stage anything, not the modules/firmware since those would
clash with linux-firmware
sysroot_stage_all () {
:
--
2.1.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 3/6] libepoxy: DEPENDS on virtual/mesa
On Tue, Apr 14, 2015 at 4:06 PM, Burton, Ross ross.bur...@intel.com wrote: On 14 April 2015 at 15:03, Andreas Müller schnitzelt...@googlemail.com wrote: 2. In meta-qt5-extra I have libepoxy in for a while - kwin needs it [1]. Problem with Xorg-Macros: These are build for x11 in distro features only but there are BSPs around (e.g meta-fsl-arm) supporting either x11 or wayland - not both together. So for a wayland only distro epoxy would not build. util-macros doesn't require X11 to build. Right - just tested for wayland-only distro. Forget my last email. Andreas -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] Should disabling features in glibc also disable the corresponding headers?
On Apr 14, 2015, at 1:25 PM, Tanu Kaskinen tanu.kaski...@linux.intel.com wrote: Hello, oe-core's version of glibc allows configuring out some libc features. Currently, if a feature is disabled in glibc, glibc still installs the header for that feature. This means that applications using glibc can't rely on checking just the header presence in their configure scripts, they also need to check whether the function implementation is present. Is there some good reason why glibc works that way, or should glibc be fixed so that disabling a feature disables the header too? At least alsa-lib requires patching[1] for this reason, and I wouldn't be surprised if there were many other similar cases in other packages. [1] http://cgit.openembedded.org/openembedded-core/tree/meta/recipes-multimedia/alsa/alsa-lib/Check-if-wordexp-function-is-supported.patch checking for functions is the right thing. And it would fail to link if you passed configure check. -- Tanu -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [RFC] allow installation of multiple kernels in the rootfs
On 4/14/15 4:42 AM, Sergey 'Jin' Bostandzhyan wrote:
Hi Bruce,
thanks for the initial feedback, I guess I'll need a bit more help/guidance,
so I hope that others will also join the discussion.
On Mon, Apr 13, 2015 at 11:31:50AM -0400, Bruce Ashfield wrote:
I'd be happy to hear some feedback on this and I'm willing to tune anything
that might be necessary in order to get this feature merged into core.
My big concerns are around compatibility/consistency and the wreckage
that changing
the package names will cause for the system.
I'm competent in packaging .. but not an expert, so I'm hoping that
Richard and folks
like Mark Hatle can jump in with options to allow the package managers
to deal with
this as well.
+1, hoping to hear their feedback as well.
Honestly, I'm not really sure what all of the options are here. I know that RPM
supports a mode (designed for kernels and modules) that allow you to install
multiple versions of the same package at the same time. I'm not sure if this is
what you want... but the initial install can only be a single version.
Using RPM (or smart) basically you have to tell the system to 'install' vs
'upgrade'. And as long as there are no conflicting files, it will happily do
more then one version of the same package.
(I doubt dpkg or deb support this, but I don't know.)
As for the changes below. (Without annotating too much,) the things I would
look out for are:
*) Various pieces of the system may assume package names, such as
'kernel-modules' or 'kernel-image' or ... So it's wise to provide an RPROVIDE
for any packages that provide these elements. RREPLACES would also be needed to
support target upgrades from the 'old naming' to the 'new' naming. (With
appropriate checks that the 'newname' is not the same as the old name.)
*) Different names for the packages should work -- but you'll need to make sure
they're providing different file paths or non-conflict files... otherwise you
could get conflicts and install failures.
With the above said, the only thing that I see that is likely missing is the
RPROVIDES.. and RREPLACES to support an on-target upgrade mode.
--Mark
diff --git a/meta/classes/kernel-module-split.bbclass
b/meta/classes/kernel-module-split.bbclass
index 9a95b72..dbfad01 100644
--- a/meta/classes/kernel-module-split.bbclass
+++ b/meta/classes/kernel-module-split.bbclass
@@ -28,7 +28,7 @@ do_install_append() {
PACKAGESPLITFUNCS_prepend = split_kernel_module_packages
-KERNEL_MODULES_META_PACKAGE ?= kernel-modules
+KERNEL_MODULES_META_PACKAGE ?= ${KERNEL_PACKAGE_NAME}-modules
The problem that I have with this is one of wider consistency and eco
system layers.
Before, I could count on the fact that kernel-modules got me all the
built kernel
modules for any kernel provided by the virtual/kernel dependency. Now
I have to know
if a layer changes this variable and/or update all my package lists to
use this variable.
Not impossible, but preferably something to avoid.
Would it make sense to introduce some virtual/kernel-modules, similar to
virtual/kernel?
This way we would have one kernel and kernel modules provider which can
always
be referenced by a clear name.
python split_kernel_module_packages () {
import re
@@ -178,12 +178,15 @@ python split_kernel_module_packages () {
module_deps = parse_depmod()
module_regex = '^(.*)\.k?o$'
-module_pattern = 'kernel-module-%s'
+
+kernel_package_name = d.getVar('KERNEL_PACKAGE_NAME')
+
+module_pattern = kernel_package_name + '-module-%s'
postinst = d.getVar('pkg_postinst_modules', True)
postrm = d.getVar('pkg_postrm_modules', True)
-modules = do_split_packages(d, root='/lib/modules',
file_regex=module_regex, output_pattern=module_pattern, description='%s
kernel module', postinst=postinst, postrm=postrm, recursive=True,
hook=frob_metadata, extra_depends='kernel-%s' % (d.getVar(KERNEL_VERSION,
True)))
+modules = do_split_packages(d, root='/lib/modules',
file_regex=module_regex, output_pattern=module_pattern, description='%s
kernel module', postinst=postinst, postrm=postrm, recursive=True,
hook=frob_metadata, extra_depends='%s-%s' % (kernel_package_name,
d.getVar(KERNEL_VERSION, True)))
if modules:
metapkg = d.getVar('KERNEL_MODULES_META_PACKAGE', True)
d.appendVar('RDEPENDS_' + metapkg, ' '+' '.join(modules))
diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index 70ed95b..c7c6c3e 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -6,11 +6,43 @@ DEPENDS += virtual/${TARGET_PREFIX}binutils
virtual/${TARGET_PREFIX}gcc kmod-na
# we include gcc above, we dont need virtual/libc
INHIBIT_DEFAULT_DEPS = 1
+
+KERNEL_PACKAGE_NAME =
You do set a default to kernel in the processvars routine below, but
what's the harm
in setting this to kernel as well ?
Roger that.
+
+# adds a suffix to the kernel
[OE-core] Should disabling features in glibc also disable the corresponding headers?
Hello, oe-core's version of glibc allows configuring out some libc features. Currently, if a feature is disabled in glibc, glibc still installs the header for that feature. This means that applications using glibc can't rely on checking just the header presence in their configure scripts, they also need to check whether the function implementation is present. Is there some good reason why glibc works that way, or should glibc be fixed so that disabling a feature disables the header too? At least alsa-lib requires patching[1] for this reason, and I wouldn't be surprised if there were many other similar cases in other packages. [1] http://cgit.openembedded.org/openembedded-core/tree/meta/recipes-multimedia/alsa/alsa-lib/Check-if-wordexp-function-is-supported.patch -- Tanu -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] sysvinit upgrade woes
I am using opkg for package management and sysvinit for init. I am testing a large jump on an upgrade and I have been having a few issues. One issue I have traced to sysvinit's upgrade, but I'm unsure how to remedy the solution. At some point during the upgrade process, opkg records what the new version is of all the packages getting installed. However, when I upgrade sysvinit causes sysvinit to restart before opkg has recorded which packages were just installed. So opkg thinks that it didn't upgrade anything even though all packages were upgraded. I verified that if I call opkg upgrade for all packages that require upgrade except for sysvinit that opkg correctly records which packages were upgraded. However, the end user doesn't have that kind of control, so upgrading in this manner is not an option. Has anyone else seen a similar issue? Any ideas on how to hold off sysvinit from restarting until after opkg has finished recording its information? Thanks, Bryan -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [RFC] allow installation of multiple kernels in the rootfs
On Tue, Apr 14, 2015 at 5:42 AM, Sergey 'Jin' Bostandzhyan
j...@dev.digitalstrom.org wrote:
Hi Bruce,
thanks for the initial feedback, I guess I'll need a bit more help/guidance,
so I hope that others will also join the discussion.
On Mon, Apr 13, 2015 at 11:31:50AM -0400, Bruce Ashfield wrote:
I'd be happy to hear some feedback on this and I'm willing to tune anything
that might be necessary in order to get this feature merged into core.
My big concerns are around compatibility/consistency and the wreckage
that changing
the package names will cause for the system.
I'm competent in packaging .. but not an expert, so I'm hoping that
Richard and folks
like Mark Hatle can jump in with options to allow the package managers
to deal with
this as well.
+1, hoping to hear their feedback as well.
diff --git a/meta/classes/kernel-module-split.bbclass
b/meta/classes/kernel-module-split.bbclass
index 9a95b72..dbfad01 100644
--- a/meta/classes/kernel-module-split.bbclass
+++ b/meta/classes/kernel-module-split.bbclass
@@ -28,7 +28,7 @@ do_install_append() {
PACKAGESPLITFUNCS_prepend = split_kernel_module_packages
-KERNEL_MODULES_META_PACKAGE ?= kernel-modules
+KERNEL_MODULES_META_PACKAGE ?= ${KERNEL_PACKAGE_NAME}-modules
The problem that I have with this is one of wider consistency and eco
system layers.
Before, I could count on the fact that kernel-modules got me all the
built kernel
modules for any kernel provided by the virtual/kernel dependency. Now
I have to know
if a layer changes this variable and/or update all my package lists to
use this variable.
Not impossible, but preferably something to avoid.
Would it make sense to introduce some virtual/kernel-modules, similar to
virtual/kernel?
The modules and kernel really are the same thing, and we do need the modules
to be provided (but packaged separately) by the same kernel, so as near as I
can tell, that wouldn't buy us anything and add complexity. A good thought
though.
I see that Mark just followed up as well, and probably just generating a
RPROVIDES under the old name would meet that compatibility issue.
This way we would have one kernel and kernel modules provider which can always
be referenced by a clear name.
python split_kernel_module_packages () {
import re
@@ -178,12 +178,15 @@ python split_kernel_module_packages () {
module_deps = parse_depmod()
module_regex = '^(.*)\.k?o$'
-module_pattern = 'kernel-module-%s'
+
+kernel_package_name = d.getVar('KERNEL_PACKAGE_NAME')
+
+module_pattern = kernel_package_name + '-module-%s'
postinst = d.getVar('pkg_postinst_modules', True)
postrm = d.getVar('pkg_postrm_modules', True)
-modules = do_split_packages(d, root='/lib/modules',
file_regex=module_regex, output_pattern=module_pattern, description='%s
kernel module', postinst=postinst, postrm=postrm, recursive=True,
hook=frob_metadata, extra_depends='kernel-%s' %
(d.getVar(KERNEL_VERSION, True)))
+modules = do_split_packages(d, root='/lib/modules',
file_regex=module_regex, output_pattern=module_pattern, description='%s
kernel module', postinst=postinst, postrm=postrm, recursive=True,
hook=frob_metadata, extra_depends='%s-%s' % (kernel_package_name,
d.getVar(KERNEL_VERSION, True)))
if modules:
metapkg = d.getVar('KERNEL_MODULES_META_PACKAGE', True)
d.appendVar('RDEPENDS_' + metapkg, ' '+' '.join(modules))
diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index 70ed95b..c7c6c3e 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -6,11 +6,43 @@ DEPENDS += virtual/${TARGET_PREFIX}binutils
virtual/${TARGET_PREFIX}gcc kmod-na
# we include gcc above, we dont need virtual/libc
INHIBIT_DEFAULT_DEPS = 1
+
+KERNEL_PACKAGE_NAME =
You do set a default to kernel in the processvars routine below, but
what's the harm
in setting this to kernel as well ?
Roger that.
+
+# adds a suffix to the kernel name, allowing to change the naming scheme
of
+# the kernel packages, result will be
kernel-${KERNEL_PACKAGE_EXTRA_NAME}
+KERNEL_PACKAGE_EXTRA_NAME ?=
+
KERNEL_IMAGETYPE ?= zImage
INITRAMFS_IMAGE ?=
INITRAMFS_TASK ?=
INITRAMFS_IMAGE_BUNDLE ?=
+python kernel_processvars_handler () {
+extra_name = e.data.getVar('KERNEL_PACKAGE_EXTRA_NAME', True) or
+default_name = e.data.getVar('KERNEL_PACKAGE_NAME', True) or kernel
+if extra_name != :
+new_kernel_package_name = '%s-%s' % (default_name, extra_name)
+e.data.setVar('KERNEL_PACKAGE_NAME', new_kernel_package_name)
+localversion = e.data.getVar('KERNEL_LOCALVERSION', True) or
+if (localversion == ):
+localversion = -%s % extra_name
+else:
+localversion = %s+%s % (localversion, extra_name)
+
+e.data.setVar('KERNEL_LOCALVERSION',
Re: [OE-core] [PATCH 5/5] bluetooth.bbclass: set bluez5 as the default BT stack
On Tue, Apr 14, 2015 at 6:28 AM, Burton, Ross ross.bur...@intel.com wrote: On 7 April 2015 at 00:41, Peter A. Bigot p...@pabigot.com wrote: Thank you. So, if I understand correctly, the effect of adding bluez5 to DISTRO_FEATURES_BACKFILL while keeping the current logic: # bluetooth support on the platform: # if bluetooth is not in DISTRO_FEATURES # else bluez5 if bluez5 is in DISTRO_FEATURES # else bluez4 is that bluez5 becomes the default and is in DISTRO_FEATURES automatically, and it stays the default even if bluez4 is also in DISTRO_FEATURES unless somebody adds bluez5 to DISTRO_FEATURES_BACKFILL_CONSIDERED at which point bluez4 takes precedence. If that understanding is correct, and reviewing http://www.yoctoproject.org/docs/latest/ref-manual/ref-manual.html#ref-features-backfill, it's not clear to me that it's the right approach. We're not backfilling bluetooth, which remains optional and continues to control whether either bluez4 or bluez5 is relevant. We're changing the default provider of bluetooth services, something that I think can reasonably be changed between releases, and something that 1.8 already controls (via explicit specification of bluez4 or bluez5 in DISTRO_FEATURES). My reasoning for backfilling bluez5 is that bluetooth.bbclass has a defined behaviour in 1.8: if bluetooth in DF: if bluez5 in DF: return bluez5 else: return bluez4 else: return There's no mention of a bluez4 DISTRO_FEATURE, just a bluetooth value to enable/disable Bluetooth in general, and the toggle between BlueZ 4 and 5 is the presence of a bluez5 DISTRO_FEATURE. We don't need to change the algorithm or create new DISTRO_FEATURE entries, as we have all the logic and items needed: by backfilling bluez5 into DISTRO_FEATURES we get the default switched, and distributions can flip back to bluez4 when upgrading to 1.9 by adding in meta-connectivity and wiping out bluez5 from DISTRO_FEATURES. Or am I alone in thinking this is the best approach going forward? For what it's worth, I'd agree with that. There's no need to change the logic. -- Christopher Larson clarson at kergoth dot com Founder - BitBake, OpenEmbedded, OpenZaurus Maintainer - Tslib Senior Software Engineer, Mentor Graphics -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] psplash and systemd
Hello, I noticed that splash does not have system support and it is still being used in our image class. I wanna ask any plan to add system support or move to other splash screen package? Noor Noor Ahsan | Engineering Manager Mentor Embedded Linux Mentor Embeddedhttp://www.mentor.com/embedded(tm) |5-6-7-8th floors 105 B2 Gulberg III, Ali Tower MM Alam Road, Lahore P +92 42 36099196 | M +92 307 4448444 Nucleushttp://www.mentor.com/embedded-software/nucleus/(r) | Linuxhttp://www.mentor.com/embedded-software/linux/(r) | Androidhttp://www.mentor.com/embedded-software/android/(tm) | Serviceshttp://www.mentor.com/embedded-software/services/ | UIhttp://www.mentor.com/embedded-software/inflexion/ | Multi-OShttp://www.mentor.com/embedded-software/multicore-multi-os Android is a trademark of Google Inc. Use of this trademark is subject to Google Permissions. Linux is the registered trademark of Linus Torvalds in the U.S. and other countries. -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] psplash and systemd
On Apr 14, 2015, at 12:04 PM, Ahsan, Noor noor_ah...@mentor.com wrote: Hello, I noticed that splash does not have system support and it is still being used in our image class. I wanna ask any plan to add system support or move to other splash screen package? Locally, I have patches for plymouth, which works well integrated with systemd. I plan to post them this 1.9 cycle. Noor Noor Ahsan | Engineering Manager Mentor Embedded Linux Mentor Embedded http://www.mentor.com/embedded™ |5-6-7-8th floors 105 B2 Gulberg III, Ali Tower MM Alam Road, Lahore P +92 42 36099196 | M +92 307 4448444 Nucleus http://www.mentor.com/embedded-software/nucleus/® | Linux http://www.mentor.com/embedded-software/linux/® | Android http://www.mentor.com/embedded-software/android/™ | Services http://www.mentor.com/embedded-software/services/ | UI http://www.mentor.com/embedded-software/inflexion/ | Multi-OS http://www.mentor.com/embedded-software/multicore-multi-os Android is a trademark of Google Inc. Use of this trademark is subject to Google Permissions. Linux is the registered trademark of Linus Torvalds in the U.S. and other countries. -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org mailto:Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core http://lists.openembedded.org/mailman/listinfo/openembedded-core -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] lz4: update package to 128 and SRC_URI
From: Armin Kuster akus...@mvista.com
The main reason for the update is to use github
as the project moved away from googlecode.
Signed-off-by: Armin Kuster akus...@mvista.com
---
meta/recipes-support/lz4/{lz4_svn.bb = lz4.bb} | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
rename meta/recipes-support/lz4/{lz4_svn.bb = lz4.bb} (78%)
diff --git a/meta/recipes-support/lz4/lz4_svn.bb
b/meta/recipes-support/lz4/lz4.bb
similarity index 78%
rename from meta/recipes-support/lz4/lz4_svn.bb
rename to meta/recipes-support/lz4/lz4.bb
index 363e439..ee5de0a 100644
--- a/meta/recipes-support/lz4/lz4_svn.bb
+++ b/meta/recipes-support/lz4/lz4.bb
@@ -4,13 +4,13 @@ DESCRIPTION = LZ4 is a very fast lossless compression
algorithm, providing comp
LICENSE = BSD
LIC_FILES_CHKSUM = file://LICENSE;md5=0b0d063f37a4477b54af2459477dcafd
-# Upstream names releases after SVN revs
-SRCREV = 127
-PV = r${SRCREV}
+SRCREV = 5780864c0ce08622238a267c46fb489d7066cad4
-SRC_URI = svn://lz4.googlecode.com/svn/;module=trunk;protocol=http
+PV = 128+git${SRCPV}
-S = ${WORKDIR}/trunk
+SRC_URI = git://github.com/Cyan4973/lz4.git;protocol=http
+
+S = ${WORKDIR}/git
EXTRA_OEMAKE = PREFIX=${prefix} CC='${CC}' DESTDIR=${D} LIBDIR=${libdir}
INCLUDEDIR=${includedir}
--
2.3.5
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/1] rootfsdebugfiles.bbclass: quick-and-dirty installation of additional files
On Tue, Apr 14, 2015 at 12:42 AM, Patrick Ohly patrick.o...@intel.com wrote: On Mon, 2015-04-13 at 09:07 -0700, Christopher Larson wrote: On Mon, Apr 13, 2015 at 8:44 AM, Patrick Ohly patrick.o...@intel.com wrote: The main motivation for this class was the observation that a) a core-image can hang under qemu when the kernel does not have enough entropy to generate the ssh host key b) ssh complains about changing ssh host key files when rebooting the same machine with different images For debugging it is okay to reuse an ssh host key generated on the device before. There may be also similar use cases, so the class is generic enough to also copy more than one file or directory, with dropbear_rsa_host_key given as example. The documentation and naming of the class makes it clear that it should not be used for production images. Signed-off-by: Patrick Ohly patrick.o...@intel.com Freescale's merge-files recipe may be worth looking at as an alternative to this. Thanks for mentioning it. Yes, that's also a way to do it. It seems a bit more complicated to set up (all files must be in a common merge directory) and does not seem to support sub-directories (-maxdepth 1), so it is a bit less flexible than the ROOTFS_DEBUG_FILES that I was proposing. On the other hand, the files get packaged properly (well, if one is careful about adapting the default MIT license as needed). For my use case, I still prefer the quick-and-dirty approach. Indeed, both approaches have value, depending on one's needs, I think. -- Christopher Larson clarson at kergoth dot com Founder - BitBake, OpenEmbedded, OpenZaurus Maintainer - Tslib Senior Software Engineer, Mentor Graphics -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [oe-core][dizzy][PATCH] base-files: Check for /run and /var/lock softlinks on upgrade
All,
-Original Message-
From: Bryan Evenson [mailto:beven...@melinkcorp.com]
Sent: Friday, April 10, 2015 12:44 PM
To: openembedded-core@lists.openembedded.org
Cc: Bryan Evenson
Subject: [oe-core][dizzy][PATCH] base-files: Check for /run and /var/lock
softlinks on upgrade
Commit ea647cd9eebdc3e3121b84074519c4bb305adac9 moved the locations
of /run and /var/lock to match the FHS 3 draft specifications.
However, the install doesn't remove the existing directories.
As a result, upgrading a system may result in /run as a softlink
to /var/run and /var/run as a softlink to /run, creating a circular
link.
During pre and post-install, check for the existence of the old
softlinks, move the old file contents to a temporary location, remove
the softlinks, and restore the directory contents after installation.
I went about this wrong, as I forgot that items may be mounted under /run. I'm
working on a different solution in which the preinst step removes the /run and
/var/lock softlinks if they exist. However, I still have odd issues. The
first reboot works fine, but then on the next reboot there is a link inside
/run for run - /var/run and inside /var there is a link for run -
/var/volatile/run. This doesn't match up with the files listed in the
base-files recipe. I can't figure out where these links are coming from. Has
anyone else had issues upgrading base-files?
Thanks,
Bryan
Signed-off-by: Bryan Evenson beven...@melinkcorp.com
---
meta/recipes-core/base-files/base-files_3.0.14.bb | 55
+++
1 file changed, 55 insertions(+)
diff --git a/meta/recipes-core/base-files/base-files_3.0.14.bb
b/meta/recipes-core/base-files/base-files_3.0.14.bb
index 07f5c54..71cea08 100644
--- a/meta/recipes-core/base-files/base-files_3.0.14.bb
+++ b/meta/recipes-core/base-files/base-files_3.0.14.bb
@@ -66,6 +66,41 @@ hostname = openembedded
BASEFILESISSUEINSTALL ?= do_install_basefilesissue
+# In previous versions of base-files, /run was a softlink to /var/run and the
+# directory was located in /var/volatlie/run. Also, /var/lock was a softlink
+# to /var/volatile/lock which is where the real directory was located. Now,
+# /run and /run/lock are the real directories. If we are upgrading, we may
+# need to remove the symbolic links first before we create the directories.
+# Otherwise the directory creation will fail and we will have circular
symbolic
+# links.
+#
+# If we do need to remove the symbolic links first, we also need to preserve
+# all the contents of the directory so running programs can find the files
that
+# are in use in these directories. Move the contents to a temporary
directory
+# during pre-install to protect the contents
+pkg_preinst_${PN} () {
+#!/bin/sh -e
+if [ x$D = x ]; then
+if [ -e /var/volatile/lock ]; then
+# Move the contents of /var/volatile/lock to a temporary
directory
+mkdir -p /run_lock_tmp
+mv /var/volatile/lock/* /run_lock_tmp/
+
+# Remove the current directory
+rm -rf /var/volatile/lock
+fi
+
+if [ -h /run ]; then
+# Move the contents of /run to a temporary directory
+mkdir -p /run_tmp
+mv /run/* /run_tmp/
+
+# Remove the current directory
+rm -rf /run
+fi
+fi
+}
+
do_install () {
for d in ${dirs755}; do
install -m 0755 -d ${D}$d
@@ -79,6 +114,7 @@ do_install () {
for d in ${volatiles}; do
ln -sf volatile/$d ${D}${localstatedir}/$d
done
+
ln -snf ../run ${D}${localstatedir}/run
ln -snf ../run/lock ${D}${localstatedir}/lock
@@ -144,6 +180,25 @@ do_install_append_linuxstdbase() {
done
}
+# If we are on the actual hardware, check if we had to move /run and
/run/lock.
+# If so, copy the temporary directory contents to their new locations.
+pkg_postinst_${PN} () {
+#!/bin/sh -e
+if [ x$D = x ]; then
+if [ -e /run_tmp ]; then
+mv /run_tmp/* /run/
+rmdir /run_tmp
+fi
+
+if [ -e /run_lock_tmp/ ]; then
+mv /run_lock_tmp/* /run/lock
+rmdir /run_lock_tmp
+fi
+else
+exit 1
+fi
+}
+
PACKAGES = ${PN}-doc ${PN} ${PN}-dev ${PN}-dbg
FILES_${PN} = /
FILES_${PN}-doc = ${docdir} ${datadir}/common-licenses
--
2.1.0
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 3/6] libepoxy: DEPENDS on virtual/mesa
On 04/14/2015 09:52 PM, Burton, Ross wrote: On 14 April 2015 at 14:50, Andreas Müller schnitzelt...@googlemail.com mailto:schnitzelt...@googlemail.com wrote: from the error I would DEPEND on virtual/egl Agreed. And there's no dependency on virtual/libx11 which the readme you quote virtual/mesa or virtual/egl depends on virtual/libx11, so I didn't add virtual/libx11, I updated virtual/mesa - virtual/egl in the repo. I also updated: [OE-core] [PATCH 4/6] strace: fix build for aarch64 extern uint32_t *const arm_sp_ptr; should be: extern long *const arm_sp_ptr; Otherwise there is a conflict types error when build arm. // Robert suggests there should be. Presumably that dependency - if it's actually required - can be made conditional on the x11 DISTRO_FEATURE? Ross -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] busybox: remove CVE-2014-9645 patch (already upstream in 1.23.x)
The CVE-2014-9645 fix was merged in Busybox prior to the 1.23.0
release [1]. The fix was then reworked in Busybox 1.23.1, in such
a way that the original change was no longer required [2].
Although oe-core's CVE-2014-9645 patch still applies cleanly to
Busybox 1.23.1 and 1.23.2, applying it partially reverts the second
version of the upstream fix.
[1]
http://git.busybox.net/busybox/commit/modutils/modprobe.c?h=1_23_stableid=4e314faa0aecb66717418e9a47a4451aec59262b
[2]
http://git.busybox.net/busybox/commit/modutils/modprobe.c?h=1_23_stableid=1ecfe811fe2f70380170ef7d820e8150054e88ca
Signed-off-by: Andre McCurdy armccu...@gmail.com
---
..._busybox_reject_module_names_with_slashes.patch | 41 --
meta/recipes-core/busybox/busybox_1.23.2.bb| 1 -
2 files changed, 42 deletions(-)
delete mode 100644
meta/recipes-core/busybox/busybox/CVE-2014-9645_busybox_reject_module_names_with_slashes.patch
diff --git
a/meta/recipes-core/busybox/busybox/CVE-2014-9645_busybox_reject_module_names_with_slashes.patch
b/meta/recipes-core/busybox/busybox/CVE-2014-9645_busybox_reject_module_names_with_slashes.patch
deleted file mode 100644
index 4e76067..000
---
a/meta/recipes-core/busybox/busybox/CVE-2014-9645_busybox_reject_module_names_with_slashes.patch
+++ /dev/null
@@ -1,41 +0,0 @@
-Upstream-status: Backport
-http://git.busybox.net/busybox/commit/?id=4e314faa0aecb66717418e9a47a4451aec59262b
-
-CVE-2014-9645 fix.
-
-[YOCTO #7257]
-
-Signed-off-by: Armin Kuster akus...@mvista.com
-
-From 4e314faa0aecb66717418e9a47a4451aec59262b Mon Sep 17 00:00:00 2001
-From: Denys Vlasenko vda.li...@googlemail.com
-Date: Thu, 20 Nov 2014 17:24:33 +
-Subject: modprobe,rmmod: reject module names with slashes
-
-function old new delta
-add_probe 86 113 +27
-
-Signed-off-by: Denys Vlasenko vda.li...@googlemail.com
-Index: busybox-1.22.1/modutils/modprobe.c
-===
busybox-1.22.1.orig/modutils/modprobe.c
-+++ busybox-1.22.1/modutils/modprobe.c
-@@ -238,6 +238,17 @@ static void add_probe(const char *name)
- {
- struct module_entry *m;
-
-+ /*
-+ * get_or_add_modentry() strips path from name and works
-+ * on remaining basename.
-+ * This would make rmmod dir/name and modprobe dir/name
-+ * to work like rmmod name and modprobe name,
-+ * which is wrong, and can be abused via implicit modprobing:
-+ * ifconfig /usbserial up tries to modprobe netdev-/usbserial.
-+ */
-+ if (strchr(name, '/'))
-+ bb_error_msg_and_die(malformed module name '%s', name);
-+
- m = get_or_add_modentry(name);
- if (!(option_mask32 (OPT_REMOVE | OPT_SHOW_DEPS))
- (m-flags MODULE_FLAG_LOADED)
diff --git a/meta/recipes-core/busybox/busybox_1.23.2.bb
b/meta/recipes-core/busybox/busybox_1.23.2.bb
index 0af292d..b1b9032 100644
--- a/meta/recipes-core/busybox/busybox_1.23.2.bb
+++ b/meta/recipes-core/busybox/busybox_1.23.2.bb
@@ -30,7 +30,6 @@ SRC_URI =
http://www.busybox.net/downloads/busybox-${PV}.tar.bz2;name=tarball \
file://login-utilities.cfg \
file://recognize_connmand.patch \
file://busybox-cross-menuconfig.patch \
- file://CVE-2014-9645_busybox_reject_module_names_with_slashes.patch
\
SRC_URI[tarball.md5sum] = 7925683d7dd105aabe9b6b618d48cc73
--
1.9.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/1] syslinux: add syslinux-nomtools to PACKAGES
On 04/13/2015 05:05 PM, Robert Yang wrote:
The default installed syslinux depends on mtools, we install
syslinux-nomtools too, which has the ext2/3/4 support.
Signed-off-by: Robert Yang liezhi.y...@windriver.com
---
meta/recipes-devtools/syslinux/syslinux_6.03.bb |5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/meta/recipes-devtools/syslinux/syslinux_6.03.bb
b/meta/recipes-devtools/syslinux/syslinux_6.03.bb
index 33dd776..ddb8744 100644
--- a/meta/recipes-devtools/syslinux/syslinux_6.03.bb
+++ b/meta/recipes-devtools/syslinux/syslinux_6.03.bb
@@ -66,14 +66,17 @@ do_install() {
install -d ${D}${datadir}/syslinux/
install -m 644 ${S}/bios/core/ldlinux.sys ${D}${datadir}/syslinux/
install -m 644 ${S}/bios/core/ldlinux.bss ${D}${datadir}/syslinux/
+ install -m 644 ${S}/bios/linux/syslinux-nomtools ${D}${bindir}/
Sorry, I updated this patch a little, it should be:
-m 0755, not 0644.
git://git.openembedded.org/openembedded-core-contrib rbt/syslinux
Thanks to Adrian.
// Robert
}
-PACKAGES += ${PN}-extlinux ${PN}-mbr ${PN}-chain ${PN}-pxelinux ${PN}-isolinux
${PN}-misc
+PACKAGES += ${PN}-nomtools ${PN}-extlinux ${PN}-mbr ${PN}-chain ${PN}-pxelinux
${PN}-isolinux ${PN}-misc
RDEPENDS_${PN} += mtools
+RDEPENDS_${PN}-nomtools += libext2fs
RDEPENDS_${PN}-misc += perl
FILES_${PN} = ${bindir}/syslinux
+FILES_${PN}-nomtools = ${bindir}/syslinux-nomtools
FILES_${PN}-extlinux = ${sbindir}/extlinux
FILES_${PN}-mbr = ${datadir}/${BPN}/mbr.bin
FILES_${PN}-chain = ${datadir}/${BPN}/chain.c32
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] autom4te segfault in Dumper.so when configuring intltool
On Tue, Apr 14, 2015 at 4:39 PM, Martin Jansa martin.ja...@gmail.com wrote: Yes, I see it very often since this patch almost 3 years ago: http://lists.openembedded.org/pipermail/openembedded-core/2012-August/066282.html The problem seems to be that autom4te is getting executed by the host system's perl but loads Dumper.so from OE sysroot. If the host and OE versions of perl are sufficiently different then host perl crashes when it tries to execute OE sysroot Dumper.so Manually hacking the first line of autom4te to replace /usr/bin/perl with the full path to the perl-native binary in OE sysroot makes the crashes stop. On Tue, Apr 14, 2015 at 11:34 PM, Andre McCurdy armccu...@gmail.com wrote: I'm seeing messages such as the following appear in syslog when building intltool or intltool-native from fido: [1049484.121948] autom4te[16180]: segfault at 1 ip 7fea41a7e7fe sp 7fff3c666080 error 4 in Dumper.so[7fea41a77000+8000] [1049567.199028] autom4te[17012]: segfault at 1 ip 7f34acc007fe sp 7fff5ed84db0 error 4 in Dumper.so[7f34acbf9000+8000] The segfault happens reproducibly when configuring intltool or intltool-native (one segfault every time I run or re-run the run.do_configure script). There are no obvious errors in config.log and the intltool build succeeds over-all. If I hack the intltool run.do_configure script so that the host machine's perl (v5.18.2) is found instead of perl-native from sysroot then the segfaults stop. Is anyone else seeing the same issue? Andre -- -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 3/6] libepoxy: DEPENDS on virtual/mesa
On Tue, Apr 14, 2015 at 11:09 AM, Robert Yang liezhi.y...@windriver.com wrote:
Fixed do_configure error:
configure: error: libX11 headers (libx11-dev) required to build with GLX
support
and do_compile error:
../include/epoxy/egl_generated.h:10:29: fatal error: EGL/eglplatform.h: No
such file or directory
#include EGL/eglplatform.h
The dependencies form its README.md:
* automake
* libegl1-mesa-dev
* xutils-dev
Signed-off-by: Robert Yang liezhi.y...@windriver.com
---
meta/recipes-graphics/libepoxy/libepoxy_1.2.bb |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/recipes-graphics/libepoxy/libepoxy_1.2.bb
b/meta/recipes-graphics/libepoxy/libepoxy_1.2.bb
index 4357331..50b9d2c 100644
--- a/meta/recipes-graphics/libepoxy/libepoxy_1.2.bb
+++ b/meta/recipes-graphics/libepoxy/libepoxy_1.2.bb
@@ -13,4 +13,4 @@ S = ${WORKDIR}/git
inherit autotools pkgconfig
-DEPENDS = util-macros
+DEPENDS = util-macros virtual/mesa
--
1.7.9.5
from the error I would DEPEND on virtual/egl
Andreas
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 3/6] libepoxy: DEPENDS on virtual/mesa
On Tue, Apr 14, 2015 at 3:52 PM, Burton, Ross ross.bur...@intel.com wrote: On 14 April 2015 at 14:50, Andreas Müller schnitzelt...@googlemail.com wrote: from the error I would DEPEND on virtual/egl Agreed. And there's no dependency on virtual/libx11 which the readme you quote suggests there should be. Presumably that dependency - if it's actually required - can be made conditional on the x11 DISTRO_FEATURE? Ross 1. To look for dependencies configure.ac is first place - Readme is often a place without love 2. In meta-qt5-extra I have libepoxy in for a while - kwin needs it [1]. Problem with Xorg-Macros: These are build for x11 in distro features only but there are BSPs around (e.g meta-fsl-arm) supporting either x11 or wayland - not both together. So for a wayland only distro epoxy would not build. [1] https://github.com/schnitzeltony/meta-qt5-extra/tree/master/recipes-support/libepoxy Andreas -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 3/6] libepoxy: DEPENDS on virtual/mesa
On 14 April 2015 at 15:03, Andreas Müller schnitzelt...@googlemail.com wrote: 2. In meta-qt5-extra I have libepoxy in for a while - kwin needs it [1]. Problem with Xorg-Macros: These are build for x11 in distro features only but there are BSPs around (e.g meta-fsl-arm) supporting either x11 or wayland - not both together. So for a wayland only distro epoxy would not build. util-macros doesn't require X11 to build. Ross -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] autom4te segfault in Dumper.so when configuring intltool
I'm seeing messages such as the following appear in syslog when building intltool or intltool-native from fido: [1049484.121948] autom4te[16180]: segfault at 1 ip 7fea41a7e7fe sp 7fff3c666080 error 4 in Dumper.so[7fea41a77000+8000] [1049567.199028] autom4te[17012]: segfault at 1 ip 7f34acc007fe sp 7fff5ed84db0 error 4 in Dumper.so[7f34acbf9000+8000] The segfault happens reproducibly when configuring intltool or intltool-native (one segfault every time I run or re-run the run.do_configure script). There are no obvious errors in config.log and the intltool build succeeds over-all. If I hack the intltool run.do_configure script so that the host machine's perl (v5.18.2) is found instead of perl-native from sysroot then the segfaults stop. Is anyone else seeing the same issue? Andre -- -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH][dizzy] This patch fixes x32 builds broken since openssl update
From: Brendan Le Foll brendan.le.f...@intel.com I made a mistake rebasing the patch, this is a fix Brendan Le Foll (1): openssl: Fix x32 openssl patch which was not building .../openssl/openssl/openssl_fix_for_x32.patch | 30 ++ 1 file changed, 30 insertions(+) -- 2.3.5 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH][dizzy] openssl: Fix x32 openssl patch which was not building
From: Brendan Le Foll brendan.le.f...@intel.com x32 builds where broken due to patch rebase not having been done correctly for this patch Signed-off-by: Brendan Le Foll brendan.le.f...@intel.com --- .../openssl/openssl/openssl_fix_for_x32.patch | 30 ++ 1 file changed, 30 insertions(+) diff --git a/meta/recipes-connectivity/openssl/openssl/openssl_fix_for_x32.patch b/meta/recipes-connectivity/openssl/openssl/openssl_fix_for_x32.patch index 0d3902f..ab1434a 100644 --- a/meta/recipes-connectivity/openssl/openssl/openssl_fix_for_x32.patch +++ b/meta/recipes-connectivity/openssl/openssl/openssl_fix_for_x32.patch @@ -52,6 +52,36 @@ Index: openssl-1.0.1e/crypto/bn/bn.h /* * assuming long is 64bit - this is the DEC Alpha unsigned long long is only * 64 bits :-(, don't define BN_LLONG for the DEC Alpha +Index: openssl-1.0.1e/crypto/bn/asm/x86_64-gcc.c +=== +--- openssl-1.0.1m/crypto/bn/asm/x86_64-gcc.c 2015-03-19 13:37:10.0 + openssl-1.0.1m-modif/crypto/bn/asm/x86_64-gcc.c2015-04-14 17:09:11.876533194 +0100 +@@ -211,9 +211,9 @@ + + asm volatile ( subq%2,%2 \n + .p2align 4 \n +- 1: movq(%4,%2,8),%0\n +- adcq(%5,%2,8),%0\n +- movq%0,(%3,%2,8)\n ++ 1: movq(%q4,%2,8),%0 \n ++ adcq(%q5,%2,8),%0 \n ++ movq%0,(%q3,%2,8) \n + leaq1(%2),%2\n + loop1b \n + sbbq%0,%0 \n:=a (ret), +c(n), +@@ -235,9 +235,9 @@ + + asm volatile ( subq%2,%2 \n + .p2align 4 \n +- 1: movq(%4,%2,8),%0\n +- sbbq(%5,%2,8),%0\n +- movq%0,(%3,%2,8)\n ++ 1: movq(%q4,%2,8),%0 \n ++ sbbq(%q5,%2,8),%0 \n ++ movq%0,(%q3,%2,8) \n + leaq1(%2),%2\n + loop1b \n + sbbq%0,%0 \n:=a (ret), +c(n) Index: openssl-1.0.1e/crypto/bn/bn_exp.c === --- openssl-1.0.1e.orig/crypto/bn/bn_exp.c -- 2.3.5 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH v2] init-install-efi.sh: fix gummiboot entry installation
After selecting the install gummiboot option of a Live image we are seeing boot failure resulting from the gummiboot entries not being installed correctly. This seems to be a problem in this init-install-efi.sh script where it incorrectly installs the gummiboot entries into the root filesystem, not the boot partition. We fix it by installing the entries in the boot partition. Signed-off-by: Reinette Chatre reinette.cha...@intel.com Acked-by: Darren Hart dvh...@linux.intel.com --- Hi, Is it perhaps possible to backport this into dizzy release? Thank you very much v2: now with an ack from Darren meta/recipes-core/initrdscripts/files/init-install-efi.sh | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/meta/recipes-core/initrdscripts/files/init-install-efi.sh b/meta/recipes-core/initrdscripts/files/init-install-efi.sh index 89d0750..329586d 100644 --- a/meta/recipes-core/initrdscripts/files/init-install-efi.sh +++ b/meta/recipes-core/initrdscripts/files/init-install-efi.sh @@ -199,11 +199,11 @@ if [ -f /run/media/$1/EFI/BOOT/grub.cfg ]; then fi if [ -d /run/media/$1/loader ]; then -GUMMIBOOT_CFGS=/tgt_root/loader/entries/*.conf +GUMMIBOOT_CFGS=/boot/loader/entries/*.conf # copy config files for gummiboot -cp -dr /run/media/$1/loader /tgt_root +cp -dr /run/media/$1/loader /boot # delete the install entry -rm -f /tgt_root/loader/entries/install.conf +rm -f /boot/loader/entries/install.conf # delete the initrd lines sed -i /initrd /d $GUMMIBOOT_CFGS # delete any LABEL= strings -- 2.1.0 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] Should disabling features in glibc also disable the corresponding headers?
On Tue, 2015-04-14 at 13:40 -0400, Khem Raj wrote: On Apr 14, 2015, at 1:25 PM, Tanu Kaskinen tanu.kaski...@linux.intel.com wrote: Hello, oe-core's version of glibc allows configuring out some libc features. Currently, if a feature is disabled in glibc, glibc still installs the header for that feature. This means that applications using glibc can't rely on checking just the header presence in their configure scripts, they also need to check whether the function implementation is present. Is there some good reason why glibc works that way, or should glibc be fixed so that disabling a feature disables the header too? At least alsa-lib requires patching[1] for this reason, and I wouldn't be surprised if there were many other similar cases in other packages. [1] http://cgit.openembedded.org/openembedded-core/tree/meta/recipes-multimedia/alsa/alsa-lib/Check-if-wordexp-function-is-supported.patch checking for functions is the right thing. And it would fail to link if you passed configure check. Thanks for the quick reply. Could you elaborate why checking for functions is the right thing? If that's the right thing, then I should send that alsa-lib patch to upstream, and I want to be able to explain why the patch is not a workaround for oe-core's glibc brokenness. -- Tanu -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [meta-java] [PATCH] icedtea7-native fails on hosts without /usr/include/X11/extensions
From 4789a5dc622cc8537df28596a4beb66db4ba4774 Mon Sep 17 00:00:00 2001
From: Amy Fong amy.f...@windriver.com
Date: Tue, 14 Apr 2015 13:10:22 -0400
Subject: [PATCH] icedtea7-native compile failure undefined reference to `main'
On hosts without /usr/include/X11/extensions, icedtea7-native compile
results in a build failure while trying to create an object file:
+/data/home/.../git/csu/../sysdeps/x86_64/start.S:118: undefined reference to
`main'
[2015-03-31 15:22:53.115930161+00:00] | collect2: error: ld returned 1 exit
status
The compile line shows: (-c gets eaten)
... -I -c -o
The makefile tries to do the following which results in a faulty build
line if /usr/include/X11/extensions doesn't exist:
CPPFLAGS += -I$(firstword $(wildcard $(OPENWIN_HOME)/include/X11/extensions)
\
$(wildcard /usr/include/X11/extensions))
This looks like a missed line from the following patch which removes the need
for X11/extensions:
icedtea-ecj-disable-compilation.patch
Signed-off-by: Amy Fong amy.f...@windriver.com
---
recipes-core/icedtea/icedtea7-native.inc | 2 ++
.../openjdk-7-03b147/headless_x11_cleanup.patch| 35 ++
2 files changed, 37 insertions(+)
create mode 100644
recipes-core/icedtea/openjdk-7-03b147/headless_x11_cleanup.patch
diff --git a/recipes-core/icedtea/icedtea7-native.inc
b/recipes-core/icedtea/icedtea7-native.inc
index 81e9b66..f555d70 100644
--- a/recipes-core/icedtea/icedtea7-native.inc
+++ b/recipes-core/icedtea/icedtea7-native.inc
@@ -30,6 +30,7 @@ SRC_URI = \
SRC_URI += file://icedtea-unzip.patch
SRC_URI += file://icedtea-unzip-phase2.patch;apply=no
+SRC_URI += file://headless_x11_cleanup.patch;apply=no
S = ${WORKDIR}/${ICEDTEA}
B = ${S}/build
@@ -149,6 +150,7 @@ do_configure_append() {
oe_runmake patch-boot
cd ${S} cat ${WORKDIR}/icedtea-unzip-phase2.patch | patch -p1
+ cd ${S} cat ${WORKDIR}/headless_x11_cleanup.patch | patch -p1
}
EXTRA_OEMAKE = ' \
diff --git a/recipes-core/icedtea/openjdk-7-03b147/headless_x11_cleanup.patch
b/recipes-core/icedtea/openjdk-7-03b147/headless_x11_cleanup.patch
new file mode 100644
index 000..5b3e650
--- /dev/null
+++ b/recipes-core/icedtea/openjdk-7-03b147/headless_x11_cleanup.patch
@@ -0,0 +1,35 @@
+---
+ build/openjdk-boot/jdk/make/sun/awt/mawt.gmk |6 --
+ build/openjdk/jdk/make/sun/awt/mawt.gmk |6 --
+ 2 files changed, 12 deletions(-)
+
+--- a/build/openjdk-boot/jdk/make/sun/awt/mawt.gmk
b/build/openjdk-boot/jdk/make/sun/awt/mawt.gmk
+@@ -258,12 +258,6 @@
+ -I$(PLATFORM_SRC)/native/$(PKGDIR) \
+ $(EVENT_MODEL)
+
+-ifeq ($(PLATFORM), linux)
+- # Checking for the X11/extensions headers at the additional location
+- CPPFLAGS += -I$(firstword $(wildcard
$(OPENWIN_HOME)/include/X11/extensions) \
+-$(wildcard /usr/include/X11/extensions))
+-endif
+-
+ ifeq ($(PLATFORM), solaris)
+ CPPFLAGS += -I$(OPENWIN_HOME)/include/X11/extensions
+ endif
+--- a/build/openjdk/jdk/make/sun/awt/mawt.gmk
b/build/openjdk/jdk/make/sun/awt/mawt.gmk
+@@ -258,12 +258,6 @@
+ -I$(PLATFORM_SRC)/native/$(PKGDIR) \
+ $(EVENT_MODEL)
+
+-ifeq ($(PLATFORM), linux)
+- # Checking for the X11/extensions headers at the additional location
+- CPPFLAGS += -I$(firstword $(wildcard
$(OPENWIN_HOME)/include/X11/extensions) \
+-$(wildcard /usr/include/X11/extensions))
+-endif
+-
+ ifeq ($(PLATFORM), solaris)
+ CPPFLAGS += -I$(OPENWIN_HOME)/include/X11/extensions
+ endif
--
2.1.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH][daisy] openssl: Fix x32 openssl patch which was not building
From: Brendan Le Foll brendan.le.f...@intel.com x32 builds where broken due to patch rebase not having been done correctly for this patch Signed-off-by: Brendan Le Foll brendan.le.f...@intel.com --- .../openssl/openssl/openssl_fix_for_x32.patch | 30 ++ 1 file changed, 30 insertions(+) diff --git a/meta/recipes-connectivity/openssl/openssl/openssl_fix_for_x32.patch b/meta/recipes-connectivity/openssl/openssl/openssl_fix_for_x32.patch index 0d3902f..ab1434a 100644 --- a/meta/recipes-connectivity/openssl/openssl/openssl_fix_for_x32.patch +++ b/meta/recipes-connectivity/openssl/openssl/openssl_fix_for_x32.patch @@ -52,6 +52,36 @@ Index: openssl-1.0.1e/crypto/bn/bn.h /* * assuming long is 64bit - this is the DEC Alpha unsigned long long is only * 64 bits :-(, don't define BN_LLONG for the DEC Alpha +Index: openssl-1.0.1e/crypto/bn/asm/x86_64-gcc.c +=== +--- openssl-1.0.1m/crypto/bn/asm/x86_64-gcc.c 2015-03-19 13:37:10.0 + openssl-1.0.1m-modif/crypto/bn/asm/x86_64-gcc.c2015-04-14 17:09:11.876533194 +0100 +@@ -211,9 +211,9 @@ + + asm volatile ( subq%2,%2 \n + .p2align 4 \n +- 1: movq(%4,%2,8),%0\n +- adcq(%5,%2,8),%0\n +- movq%0,(%3,%2,8)\n ++ 1: movq(%q4,%2,8),%0 \n ++ adcq(%q5,%2,8),%0 \n ++ movq%0,(%q3,%2,8) \n + leaq1(%2),%2\n + loop1b \n + sbbq%0,%0 \n:=a (ret), +c(n), +@@ -235,9 +235,9 @@ + + asm volatile ( subq%2,%2 \n + .p2align 4 \n +- 1: movq(%4,%2,8),%0\n +- sbbq(%5,%2,8),%0\n +- movq%0,(%3,%2,8)\n ++ 1: movq(%q4,%2,8),%0 \n ++ sbbq(%q5,%2,8),%0 \n ++ movq%0,(%q3,%2,8) \n + leaq1(%2),%2\n + loop1b \n + sbbq%0,%0 \n:=a (ret), +c(n) Index: openssl-1.0.1e/crypto/bn/bn_exp.c === --- openssl-1.0.1e.orig/crypto/bn/bn_exp.c -- 2.3.5 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [meta-java] [PATCH] icedtea7-native fails on hosts without /usr/include/X11/extensions
Hello Amy,
On Tue, Apr 14, 2015 at 4:20 PM, Amy Fong amy.f...@windriver.com wrote:
From 4789a5dc622cc8537df28596a4beb66db4ba4774 Mon Sep 17 00:00:00 2001
From: Amy Fong amy.f...@windriver.com
Date: Tue, 14 Apr 2015 13:10:22 -0400
Subject: [PATCH] icedtea7-native compile failure undefined reference to `main'
On hosts without /usr/include/X11/extensions, icedtea7-native compile
results in a build failure while trying to create an object file:
+/data/home/.../git/csu/../sysdeps/x86_64/start.S:118: undefined reference to
`main'
[2015-03-31 15:22:53.115930161+00:00] | collect2: error: ld returned 1 exit
status
The compile line shows: (-c gets eaten)
... -I -c -o
The makefile tries to do the following which results in a faulty build
line if /usr/include/X11/extensions doesn't exist:
CPPFLAGS += -I$(firstword $(wildcard
$(OPENWIN_HOME)/include/X11/extensions) \
$(wildcard /usr/include/X11/extensions))
This looks like a missed line from the following patch which removes the need
for X11/extensions:
icedtea-ecj-disable-compilation.patch
Signed-off-by: Amy Fong amy.f...@windriver.com
The right mailing list for this is openembedded-devel, as described in
the README.
---
recipes-core/icedtea/icedtea7-native.inc | 2 ++
.../openjdk-7-03b147/headless_x11_cleanup.patch| 35
++
2 files changed, 37 insertions(+)
create mode 100644
recipes-core/icedtea/openjdk-7-03b147/headless_x11_cleanup.patch
diff --git a/recipes-core/icedtea/icedtea7-native.inc
b/recipes-core/icedtea/icedtea7-native.inc
index 81e9b66..f555d70 100644
--- a/recipes-core/icedtea/icedtea7-native.inc
+++ b/recipes-core/icedtea/icedtea7-native.inc
@@ -30,6 +30,7 @@ SRC_URI = \
SRC_URI += file://icedtea-unzip.patch
SRC_URI += file://icedtea-unzip-phase2.patch;apply=no
+SRC_URI += file://headless_x11_cleanup.patch;apply=no
S = ${WORKDIR}/${ICEDTEA}
B = ${S}/build
@@ -149,6 +150,7 @@ do_configure_append() {
oe_runmake patch-boot
cd ${S} cat ${WORKDIR}/icedtea-unzip-phase2.patch | patch -p1
+ cd ${S} cat ${WORKDIR}/headless_x11_cleanup.patch | patch -p1
}
This should be done if X11 is not available.
--
Otavio Salvador O.S. Systems
http://www.ossystems.com.brhttp://code.ossystems.com.br
Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [oe-core][dizzy][PATCH] base-files: Check for /run and /var/lock softlinks on upgrade
All,
-Original Message-
From: Bryan Evenson
Sent: Tuesday, April 14, 2015 11:47 AM
To: Bryan Evenson; openembedded-core@lists.openembedded.org
Subject: RE: [oe-core][dizzy][PATCH] base-files: Check for /run and /var/lock
softlinks on upgrade
All,
-Original Message-
From: Bryan Evenson [mailto:beven...@melinkcorp.com]
Sent: Friday, April 10, 2015 12:44 PM
To: openembedded-core@lists.openembedded.org
Cc: Bryan Evenson
Subject: [oe-core][dizzy][PATCH] base-files: Check for /run and
/var/lock softlinks on upgrade
Commit ea647cd9eebdc3e3121b84074519c4bb305adac9 moved the
locations of
/run and /var/lock to match the FHS 3 draft specifications.
However, the install doesn't remove the existing directories.
As a result, upgrading a system may result in /run as a softlink to
/var/run and /var/run as a softlink to /run, creating a circular link.
During pre and post-install, check for the existence of the old
softlinks, move the old file contents to a temporary location, remove
the softlinks, and restore the directory contents after installation.
I went about this wrong, as I forgot that items may be mounted under /run.
I'm working on a different solution in which the preinst step removes the
/run and /var/lock softlinks if they exist. However, I still have odd issues.
The first reboot works fine, but then on the next reboot there is a link
inside
/run for run - /var/run and inside /var there is a link for run -
/var/volatile/run. This doesn't match up with the files listed in the
base-files
recipe. I can't figure out where these links are coming from. Has anyone
else
had issues upgrading base-files?
The root cause seems to be the initscripts package. The script
/etc/volatile.cache is generated by /etc/init.d/populate-volatile.sh. On
upgrade, this file is not removed and may not necessarily be regenerated. As a
result, on the next boot the script /etc/volatile.cache repopulates directories
as it remembers them which may not be accurate. In my case, after the reboot,
the /etc/volatile.cache script deleted everything from a USB flash drive
attached to my system when it attempted to remove /run.
So to get this portion of the upgrade to work, I had to:
1. Remove the softlinks for /run and /var/lock through a preinst script in the
base-files recipe
2. Remove /etc/volatile.cache as a postint script in the initscripts recipe
Would someone like for me to submit a patch?
Thanks,
Bryan
Thanks,
Bryan
Signed-off-by: Bryan Evenson beven...@melinkcorp.com
---
meta/recipes-core/base-files/base-files_3.0.14.bb | 55
+++
1 file changed, 55 insertions(+)
diff --git a/meta/recipes-core/base-files/base-files_3.0.14.bb
b/meta/recipes-core/base-files/base-files_3.0.14.bb
index 07f5c54..71cea08 100644
--- a/meta/recipes-core/base-files/base-files_3.0.14.bb
+++ b/meta/recipes-core/base-files/base-files_3.0.14.bb
@@ -66,6 +66,41 @@ hostname = openembedded
BASEFILESISSUEINSTALL ?= do_install_basefilesissue
+# In previous versions of base-files, /run was a softlink to /var/run
+and the # directory was located in /var/volatlie/run. Also,
+/var/lock was a softlink # to /var/volatile/lock which is where the
+real directory was located. Now, # /run and /run/lock are the real
+directories. If we are upgrading, we may # need to remove the symbolic
links first before we create the directories.
+# Otherwise the directory creation will fail and we will have
+circular symbolic # links.
+#
+# If we do need to remove the symbolic links first, we also need to
+preserve # all the contents of the directory so running programs can
+find the files that # are in use in these directories. Move the
+contents to a temporary
directory
+# during pre-install to protect the contents pkg_preinst_${PN} () {
+#!/bin/sh -e
+if [ x$D = x ]; then
+if [ -e /var/volatile/lock ]; then
+# Move the contents of /var/volatile/lock to a temporary
directory
+mkdir -p /run_lock_tmp
+mv /var/volatile/lock/* /run_lock_tmp/
+
+# Remove the current directory
+rm -rf /var/volatile/lock
+fi
+
+if [ -h /run ]; then
+# Move the contents of /run to a temporary directory
+mkdir -p /run_tmp
+mv /run/* /run_tmp/
+
+# Remove the current directory
+rm -rf /run
+fi
+fi
+}
+
do_install () {
for d in ${dirs755}; do
install -m 0755 -d ${D}$d
@@ -79,6 +114,7 @@ do_install () {
for d in ${volatiles}; do
ln -sf volatile/$d ${D}${localstatedir}/$d
done
+
ln -snf ../run ${D}${localstatedir}/run
ln -snf ../run/lock ${D}${localstatedir}/lock
@@ -144,6 +180,25 @@ do_install_append_linuxstdbase() {
done
}
+# If we are on the
Re: [OE-core] [oe-core][dizzy][PATCH] base-files: Check for /run and /var/lock softlinks on upgrade
On 04/14/2015 01:41 PM, Bryan Evenson wrote:
All,
-Original Message-
From: Bryan Evenson
Sent: Tuesday, April 14, 2015 11:47 AM
To: Bryan Evenson; openembedded-core@lists.openembedded.org
Subject: RE: [oe-core][dizzy][PATCH] base-files: Check for /run and /var/lock
softlinks on upgrade
All,
-Original Message-
From: Bryan Evenson [mailto:beven...@melinkcorp.com]
Sent: Friday, April 10, 2015 12:44 PM
To: openembedded-core@lists.openembedded.org
Cc: Bryan Evenson
Subject: [oe-core][dizzy][PATCH] base-files: Check for /run and
/var/lock softlinks on upgrade
Commit ea647cd9eebdc3e3121b84074519c4bb305adac9 moved the
locations of
/run and /var/lock to match the FHS 3 draft specifications.
However, the install doesn't remove the existing directories.
As a result, upgrading a system may result in /run as a softlink to
/var/run and /var/run as a softlink to /run, creating a circular link.
During pre and post-install, check for the existence of the old
softlinks, move the old file contents to a temporary location, remove
the softlinks, and restore the directory contents after installation.
I went about this wrong, as I forgot that items may be mounted under /run.
I'm working on a different solution in which the preinst step removes the
/run and /var/lock softlinks if they exist. However, I still have odd issues.
The first reboot works fine, but then on the next reboot there is a link inside
/run for run - /var/run and inside /var there is a link for run -
/var/volatile/run. This doesn't match up with the files listed in the
base-files
recipe. I can't figure out where these links are coming from. Has anyone else
had issues upgrading base-files?
The root cause seems to be the initscripts package. The script
/etc/volatile.cache is generated by /etc/init.d/populate-volatile.sh. On
upgrade, this file is not removed and may not necessarily be regenerated. As a
result, on the next boot the script /etc/volatile.cache repopulates directories
as it remembers them which may not be accurate. In my case, after the reboot,
the /etc/volatile.cache script deleted everything from a USB flash drive
attached to my system when it attempted to remove /run.
So to get this portion of the upgrade to work, I had to:
1. Remove the softlinks for /run and /var/lock through a preinst script in the
base-files recipe
2. Remove /etc/volatile.cache as a postint script in the initscripts recipe
Would someone like for me to submit a patch?
sure.
- armin
Thanks,
Bryan
Thanks,
Bryan
Signed-off-by: Bryan Evenson beven...@melinkcorp.com
---
meta/recipes-core/base-files/base-files_3.0.14.bb | 55
+++
1 file changed, 55 insertions(+)
diff --git a/meta/recipes-core/base-files/base-files_3.0.14.bb
b/meta/recipes-core/base-files/base-files_3.0.14.bb
index 07f5c54..71cea08 100644
--- a/meta/recipes-core/base-files/base-files_3.0.14.bb
+++ b/meta/recipes-core/base-files/base-files_3.0.14.bb
@@ -66,6 +66,41 @@ hostname = openembedded
BASEFILESISSUEINSTALL ?= do_install_basefilesissue
+# In previous versions of base-files, /run was a softlink to /var/run
+and the # directory was located in /var/volatlie/run. Also,
+/var/lock was a softlink # to /var/volatile/lock which is where the
+real directory was located. Now, # /run and /run/lock are the real
+directories. If we are upgrading, we may # need to remove the symbolic
links first before we create the directories.
+# Otherwise the directory creation will fail and we will have
+circular symbolic # links.
+#
+# If we do need to remove the symbolic links first, we also need to
+preserve # all the contents of the directory so running programs can
+find the files that # are in use in these directories. Move the
+contents to a temporary
directory
+# during pre-install to protect the contents pkg_preinst_${PN} () {
+#!/bin/sh -e
+if [ x$D = x ]; then
+if [ -e /var/volatile/lock ]; then
+# Move the contents of /var/volatile/lock to a temporary directory
+mkdir -p /run_lock_tmp
+mv /var/volatile/lock/* /run_lock_tmp/
+
+# Remove the current directory
+rm -rf /var/volatile/lock
+fi
+
+if [ -h /run ]; then
+# Move the contents of /run to a temporary directory
+mkdir -p /run_tmp
+mv /run/* /run_tmp/
+
+# Remove the current directory
+rm -rf /run
+fi
+fi
+}
+
do_install () {
for d in ${dirs755}; do
install -m 0755 -d ${D}$d
@@ -79,6 +114,7 @@ do_install () {
for d in ${volatiles}; do
ln -sf volatile/$d ${D}${localstatedir}/$d
done
+
ln -snf ../run ${D}${localstatedir}/run
ln -snf ../run/lock ${D}${localstatedir}/lock
@@ -144,6 +180,25 @@ do_install_append_linuxstdbase() {
done
}
+# If we are on the actual hardware, check if we had to move /run and
/run/lock.
+# If so, copy the
Re: [OE-core] [PATCH 1/1] syslinux: add syslinux-nomtools to PACKAGES
From c0a00e59de0e5dad364b0f260303533bab6388a6 Mon Sep 17 00:00:00 2001 From: Adrian adrian.freiho...@gmail.com Date: Tue, 14 Apr 2015 23:49:05 +0200 Subject: [PATCH] wic: plugin for single ext partition This is not the final implementatio yet. It is based on a temporary wrapper script calling extlinux and sudo. The final solution will call syslinux-nomtools instead of the script. The wic plugin creates a disk image containig just one ext2/3/4 partition. The target devices are PCs with legacy BIOS. Syslinux is used as a bootloader. Creating just one ext partition instead of a fat partiton for boot and an ext partiton for rootfs solves several issues related to package based kernel updates on the device. --- .../lib/wic/plugins/source/rootfs-pcbios-ext.py| 165 + scripts/syslinux-e2fs | 68 + 2 files changed, 233 insertions(+) create mode 100644 scripts/lib/wic/plugins/source/rootfs-pcbios-ext.py create mode 100755 scripts/syslinux-e2fs diff --git a/scripts/lib/wic/plugins/source/rootfs-pcbios-ext.py b/scripts/lib/wic/plugins/source/rootfs-pcbios-ext.py new file mode 100644 index 000..e455036 --- /dev/null +++ b/scripts/lib/wic/plugins/source/rootfs-pcbios-ext.py @@ -0,0 +1,165 @@ +# ex:ts=4:sw=4:sts=4:et +# -*- tab-width: 4; c-basic-offset: 4; indent-tabs-mode: nil -*- +# +# This program is free software; you can distribute it and/or modify +# it under the terms of the GNU General Public License version 2 as +# published by the Free Software Foundation. +# +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for mo details. +# +# You should have received a copy of the GNU General Public License along +# with this program; if not, write to the Free Software Foundation, Inc., +# 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA. +# +# DESCRIPTION +# This plugin creates a disk image containing a bootable root partition with +# syslinux installed. The filesystem is ext2/3/4, no extra boot partition is +# required. +# +# Example kickstart file: +# part / --source rootfs-pcbios-ext --ondisk sda --fstype=ext4 --label rootfs --align 1024 +# bootloader --timeout=0 --append=rootwait rootfstype=ext4 --source rootfs-pcbios-ext +# +# The first line generates a root file system including a syslinux.cfg file +# The --source rootfs-pcbios-ext in the second line triggers the ldlinux.sys +# installation into the image. +# +# AUTHOR +# Adrian Freihofer adrian.freihofer (at] gmail.com +# + +import os +from wic import kickstart, msger +from wic.utils import runner +from wic.pluginbase import SourcePlugin +from wic.utils.oe.misc import * + + +class RootfsPlugin(SourcePlugin): +name = 'rootfs-pcbios-ext' + +@staticmethod +def __get_rootfs_dir(rootfs_dir): +if os.path.isdir(rootfs_dir): +return rootfs_dir + +bitbake_env_lines = find_bitbake_env_lines(rootfs_dir) +if not bitbake_env_lines: +msg = Couldn't get bitbake environment, exiting. +msger.error(msg) + +image_rootfs_dir = find_artifact(bitbake_env_lines, IMAGE_ROOTFS) +if not os.path.isdir(image_rootfs_dir): +msg = No valid artifact IMAGE_ROOTFS from image named +msg += %s has been found at %s, exiting.\n % \ +(rootfs_dir, image_rootfs_dir) +msger.error(msg) + +return image_rootfs_dir + +@classmethod +def do_configure_partition(self, part, source_params, cr, cr_workdir, + oe_builddir, bootimg_dir, kernel_dir, + native_sysroot): + +Called before do_prepare_partition(), creates syslinux config + +(rootdev, root_part_uuid) = cr._get_boot_config() +options = cr.ks.handler.bootloader.appendLine + +syslinux_conf = +syslinux_conf += PROMPT 0\n +timeout = kickstart.get_timeout(cr.ks) +if not timeout: +timeout = 0 +syslinux_conf += TIMEOUT + str(timeout) + \n +syslinux_conf += \n +syslinux_conf += ALLOWOPTIONS 1\n +syslinux_conf += SERIAL 0 115200\n +syslinux_conf += \n +syslinux_conf += DEFAULT boot\n +syslinux_conf += LABEL boot\n +syslinux_conf += KERNEL /boot/bzImage\n + +if cr._ptable_format == 'msdos': +rootstr = rootdev +else: +raise ImageError(Unsupported partition table format found) + +syslinux_conf += APPEND label=boot root=%s %s\n % (rootstr, options) + +syslinux_cfg = os.path.join(cr.rootfs_dir['ROOTFS_DIR'], boot, syslinux.cfg) +msger.debug(Writing syslinux config %s % syslinux_cfg) +cfg = open(syslinux_cfg, w) +cfg.write(syslinux_conf) +cfg.close() + +@classmethod
[OE-core] [dizzy][PATCHv2 1/2] base-files: Check for /run and /var/lock softlinks on upgrade
Commit ea647cd9eebdc3e3121b84074519c4bb305adac9 moved the locations
of /run and /var/lock to match the FHS 3 draft specifications.
However, the install doesn't remove the existing directories.
As a result, upgrading a system may result in /run as a softlink
to /var/run and /var/run as a softlink to /run, creating a circular
link.
During pre-install, check for the existence of the old softlinks and
remove them so the new directories can be installed.
Signed-off-by: Bryan Evenson beven...@melinkcorp.com
---
meta/recipes-core/base-files/base-files_3.0.14.bb | 24 +++
1 file changed, 24 insertions(+)
diff --git a/meta/recipes-core/base-files/base-files_3.0.14.bb
b/meta/recipes-core/base-files/base-files_3.0.14.bb
index 07f5c54..9021103 100644
--- a/meta/recipes-core/base-files/base-files_3.0.14.bb
+++ b/meta/recipes-core/base-files/base-files_3.0.14.bb
@@ -66,6 +66,29 @@ hostname = openembedded
BASEFILESISSUEINSTALL ?= do_install_basefilesissue
+# In previous versions of base-files, /run was a softlink to /var/run and the
+# directory was located in /var/volatlie/run. Also, /var/lock was a softlink
+# to /var/volatile/lock which is where the real directory was located. Now,
+# /run and /run/lock are the real directories. If we are upgrading, we may
+# need to remove the symbolic links first before we create the directories.
+# Otherwise the directory creation will fail and we will have circular symbolic
+# links.
+#
+pkg_preinst_${PN} () {
+#!/bin/sh -e
+if [ x$D = x ]; then
+if [ -h /var/lock ]; then
+# Remove the symbolic link
+rm -f /var/lock
+fi
+
+if [ -h /run ]; then
+# Remove the symbolic link
+rm -f /run
+fi
+fi
+}
+
do_install () {
for d in ${dirs755}; do
install -m 0755 -d ${D}$d
@@ -79,6 +102,7 @@ do_install () {
for d in ${volatiles}; do
ln -sf volatile/$d ${D}${localstatedir}/$d
done
+
ln -snf ../run ${D}${localstatedir}/run
ln -snf ../run/lock ${D}${localstatedir}/lock
--
2.1.0
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [dizzy][PATCHv2 2/2] initscripts: Remove /etc/volatile.cache on upgrade
/etc/volatile.cache is a cached copy of a script (which is
generated by /etc/init.d/populate-volatile.sh) that generates
the volatile filesystem directories. Since volatile.cache is
a generated file, it is not necessarily changed if
populate-volatile.sh is updated. As a result, the stale script
can add/remove the wrong directories on the next system boot.
If initscripts is being upgraded, make sure volatile.cache gets
deleted.
Signed-off-by: Bryan Evenson beven...@melinkcorp.com
---
meta/recipes-core/initscripts/initscripts_1.0.bb | 5 +
1 file changed, 5 insertions(+)
diff --git a/meta/recipes-core/initscripts/initscripts_1.0.bb
b/meta/recipes-core/initscripts/initscripts_1.0.bb
index a665acf..775816a 100644
--- a/meta/recipes-core/initscripts/initscripts_1.0.bb
+++ b/meta/recipes-core/initscripts/initscripts_1.0.bb
@@ -161,4 +161,9 @@ pkg_postinst_${PN} () {
systemctl $OPTS mask $SERVICE.service
done
fi
+
+# Delete any old volatile cache script, as directories may have moved
+if [ -z $D ]; then
+rm -f /etc/volatile.cache
+fi
}
--
2.1.0
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
