As far as kmod package is concerned O_CLOEXEC is used in constructs like
O_RDONLY|O_CLOEXEC. O_CLOEXEC can be used (is defined) starting with
Linux kernel ≥2.6.23 and glibc ≥2.7 case in which the patch does not
logically changing anything. However, prior Linux kernel ≥2.6.23
O_CLOEXEC is not
On Mon, Jul 23, 2012 at 03:06:12PM +0200, Martin Jansa wrote:
On Mon, Jul 23, 2012 at 02:02:12PM +0100, Richard Purdie wrote:
On Mon, 2012-07-23 at 13:37 +0200, Martin Jansa wrote:
On Mon, Jul 23, 2012 at 12:32:55PM +0100, Richard Purdie wrote:
On Mon, 2012-07-23 at 13:18 +0200, Martin
On Tue, 2012-07-24 at 09:57 +0200, Martin Jansa wrote:
On Mon, Jul 23, 2012 at 03:06:12PM +0200, Martin Jansa wrote:
On Mon, Jul 23, 2012 at 02:02:12PM +0100, Richard Purdie wrote:
On Mon, 2012-07-23 at 13:37 +0200, Martin Jansa wrote:
On Mon, Jul 23, 2012 at 12:32:55PM +0100, Richard
On Tue, Jul 24, 2012 at 09:17:26AM +0100, Richard Purdie wrote:
On Tue, 2012-07-24 at 09:57 +0200, Martin Jansa wrote:
On Mon, Jul 23, 2012 at 03:06:12PM +0200, Martin Jansa wrote:
On Mon, Jul 23, 2012 at 02:02:12PM +0100, Richard Purdie wrote:
On Mon, 2012-07-23 at 13:37 +0200, Martin
i asked about this not that long ago but i'm still a bit puzzled --
what's the best practice for adding new layers in terms of how
bblayers.conf and the various layer.conf files are defined?
the default layer.conf for oe-core contains:
BBPATH .= :${LAYERDIR}
...
BBFILE_PRIORITY_normal = 5
On Tuesday 24 July 2012 05:04:25 Robert P. J. Day wrote:
i asked about this not that long ago but i'm still a bit puzzled --
what's the best practice for adding new layers in terms of how
bblayers.conf and the various layer.conf files are defined?
the default layer.conf for oe-core
On Tuesday 24 July 2012 10:15:32 Paul Eggleton wrote:
but every single meta-openembedded sub-layer uses the *other* form:
BBPATH .= :${LAYERDIR}
Again, only as of quite recently
Actually it seems that may not be true. This change was made in May 2011.
Cheers,
Paul
--
Paul Eggleton
On Tue, 24 Jul 2012, Paul Eggleton wrote:
On Tuesday 24 July 2012 05:04:25 Robert P. J. Day wrote:
... snip ...
with both the yocto and oe-core layer having priority 5. is there no
chance of confusion here?
As I mentioned before, the priority currently has no bearing on the
order of
On Tue, Jul 24, 2012 at 11:15 AM, Paul Eggleton
paul.eggle...@linux.intel.com wrote:
On Tuesday 24 July 2012 05:04:25 Robert P. J. Day wrote:
i asked about this not that long ago but i'm still a bit puzzled --
what's the best practice for adding new layers in terms of how
bblayers.conf and
On Tuesday 24 July 2012 11:29:26 Martin Jansa wrote:
As I mentioned before, the priority currently has no bearing on the order
of BBPATH - that is determined by the order in which the layer conf files
are parsed and (as you highlight) whether they prepend or append to
BBPATH. Remember that
(wasn't sure whether this belonged with current layers thread, it
seemed appropriate to start a new one since it's fairly specific.)
$ bitbake-layers help
... snip ...
show-overlayed
list overlayed recipes (where the same recipe exists in another layer that
has a higher layer priority)
This is used for fixing the rpm-createsolvedb.py error:
'import site' failed; use -v for traceback
Traceback (most recent call last):
File
/srv/home/pokybuild/yocto-autobuilder/yocto-slave/nightly/build/scripts/rpm-createsolvedb.py,
line 14, in
import sys, os
ImportError: No module named os
The native python binary has been moved from usr/bin/python to
usr/bin/python-native/python, the recipe which needs python-native
should inherit pythonnative, otherwise there would be errors when the
python script runs.
[YOCTO #2822]
Signed-off-by: Robert Yang liezhi.y...@windriver.com
---
Besides being clearly broken, that line is unnecessary as that file is
already being picked up from this line in xorg-app-common.inc:
FILES_${PN} += ${libdir}/X11/${BPN} ${datadir}/X11/app-defaults/
Signed-off-by: Robert P. J. Day rpj...@crashcourse.ca
---
diff --git
On Tue, 2012-07-24 at 18:19 +0800, Robert Yang wrote:
The native python binary has been moved from usr/bin/python to
usr/bin/python-native/python, the recipe which needs python-native
should inherit pythonnative, otherwise there would be errors when the
python script runs.
[YOCTO #2822]
On 24 July 2012 06:36, Cristian Iorga cristian.io...@intel.com wrote:
rename meta/recipes-connectivity/telepathy/{telepathy-glib_0.19.2.bb =
telepathy-glib_0.19.4.bb} (80%)
I only just noticed that we're shipping the development series of
telepathy-glib, which is a bold statement. Telepathy
Hello Ross, Saul, all,
Previously, an update to telepathy-glib 0.19.2 was in our yocto recipes, so
updating to 0.19.4 seems like an obvious choice.
This is the status with a lot of stuff we are delivering.
I am in the process of updating gstreamer, and I have received recommendation
to update
Hi Christian,
On 24 July 2012 12:30, Iorga, Cristian cristian.io...@intel.com wrote:
I am in the process of updating gstreamer, and I have received recommendation
to update the entire gstreamer stack to unstable versions, because we are
many versions behind while being on the stable branch.
On Tuesday 24 July 2012 05:53:40 Robert P. J. Day wrote:
those two layers have the same priority, but the help suggests that
you'll only see instances of recipes from layers that have a
*different* priority -- not quite true.
Agreed - the intent was to try to indicate that the recipes that
On 24 July 2012 14:27, Chris Larson clar...@kergoth.com wrote:
On Tue, Jul 24, 2012 at 12:37 AM, Radu Moisan radu.moi...@intel.com wrote:
I have not tested on CentOS 5.8 if the applications are not broken in some
way, but that's not in the scope of this patch. If something does indeed
break,
Upstream updates checked.
Signed-off-by: Cristian Iorga cristian.io...@intel.com
---
.../conf/distro/include/upstream_tracking.inc | 28 ++--
1 file changed, 14 insertions(+), 14 deletions(-)
diff --git a/meta-yocto/conf/distro/include/upstream_tracking.inc
when bzip2-native is installed in parallel to sysroot, it is possible that
some packages are using bzip2 to unpack, there are chances that bzip2 is
installed to sysroot but libbz2.so.0 not installed yet because parallel
installation.
link bzip2 and bzip2recover statically to avoid this problem and
On 24 July 2012 14:49, Yao Zhao yao.z...@windriver.com wrote:
when bzip2-native is installed in parallel to sysroot, it is possible that
some packages are using bzip2 to unpack, there are chances that bzip2 is
installed to sysroot but libbz2.so.0 not installed yet because parallel
On 12-07-24 09:57 AM, Burton, Ross wrote:
On 24 July 2012 14:49, Yao Zhao yao.z...@windriver.com wrote:
when bzip2-native is installed in parallel to sysroot, it is possible that
some packages are using bzip2 to unpack, there are chances that bzip2 is
installed to sysroot but libbz2.so.0 not
patch mkfs.minix.tests to have correct md5sum on big endian platform.
Signed-off-by: Yao Zhao yao.z...@windriver.com
---
.../busybox-mkfs-minix-tests_bigendian.patch | 34
meta/recipes-core/busybox/busybox_1.19.4.bb|3 +-
2 files changed, 36
This patchset fixes isssue with compiling toolchain's bootstrap elements
added changes from kernel.bbclass from meta-oe
Fixes eglibc when certain options are disabled (seen on poky-tiny)
The following changes since commit 4148bc80c008d25c8a536c7c7dfdeac1669a6662:
libgcc: Add missing dependency
From: Denis Carikli gnu...@no-log.org
Without that fix we have the following while compiling compat-wireless.
include/linux/mmzone.h:18:30: fatal error: generated/bounds.h: No such file
or directory
Note that the compat-wireless recipe will be added in another commit.
make -C $kerneldir
From: Koen Kooi k...@dominion.thruhere.net
The intent of the uImage code in this class includes the following
1) be able to specify custom load addresses without needing to patch the kernel
2) add better information to the uImage description field
The current state is a NOP anyway, the kernel
currently gcc installs a limits.h which references to another
limits.h which it expects from target sysroot and that header
in target sysroot will come from eglibc. So we need to break
this catch-22 and hence we install a self sufficient limits.h
which is then happy when referenced and doesnt
We have had these things in place to overcome a limitation
from our gcc-initial-cross not staging a self sufficient
limits.h. Now thats fixed we do reset TOOLCHAIN_OPTIONS
to point to sysroot where linux kernel headers are staged
and not the bootstrap sysroot which will infact be popuated
by
poky-tiny disables certain eglibc options which gives good excercise
for eglibc's componentized builds. This patch essentially updates the
GLRO patch to account for additions of GLRO(dl_debug_mask) and
converts them to GLRO_dl_debug_mask
Secondly adds a new patch where it was creating a undefined
On Tue, 2012-07-24 at 14:57 +0100, Burton, Ross wrote:
On 24 July 2012 14:49, Yao Zhao yao.z...@windriver.com wrote:
when bzip2-native is installed in parallel to sysroot, it is possible that
some packages are using bzip2 to unpack, there are chances that bzip2 is
installed to sysroot but
On Tue, 2012-07-24 at 09:49 -0400, Yao Zhao wrote:
when bzip2-native is installed in parallel to sysroot, it is possible that
some packages are using bzip2 to unpack, there are chances that bzip2 is
installed to sysroot but libbz2.so.0 not installed yet because parallel
installation.
link
On 12-07-24 11:39 AM, Phil Blundell wrote:
On Tue, 2012-07-24 at 09:49 -0400, Yao Zhao wrote:
when bzip2-native is installed in parallel to sysroot, it is possible that
some packages are using bzip2 to unpack, there are chances that bzip2 is
installed to sysroot but libbz2.so.0 not installed
On 12-07-24 11:34 AM, Richard Purdie wrote:
On Tue, 2012-07-24 at 14:57 +0100, Burton, Ross wrote:
On 24 July 2012 14:49, Yao Zhao yao.z...@windriver.com wrote:
when bzip2-native is installed in parallel to sysroot, it is possible that
some packages are using bzip2 to unpack, there are chances
On 07/24/2012 06:43 AM, Cristian Iorga wrote:
Upstream updates checked.
This should really go to p...@yoctoproject.org for your future reference.
Sau!
Signed-off-by: Cristian Iorga cristian.io...@intel.com
---
.../conf/distro/include/upstream_tracking.inc | 28 ++--
On 12-07-24 11:47 AM, Phil Blundell wrote:
On Tue, 2012-07-24 at 11:45 -0400, Yao Zhao wrote:
In the Makefile, libbz2.so.0 is installed before bzip2, but the
installation is make -j xxx install. Then this could happen.
Well, yes, but you could fix that by adding an appropriate dependency.
On 7/24/12 11:39 AM, Yao Zhao wrote:
On 12-07-24 11:47 AM, Phil Blundell wrote:
On Tue, 2012-07-24 at 11:45 -0400, Yao Zhao wrote:
In the Makefile, libbz2.so.0 is installed before bzip2, but the
installation is make -j xxx install. Then this could happen.
Well, yes, but you could fix that by
On Tue, Jul 24, 2012 at 12:04 PM, Khem Raj raj.k...@gmail.com wrote:
--- a/meta/recipes-devtools/gcc/gcc-cross-initial.inc
+++ b/meta/recipes-devtools/gcc/gcc-cross-initial.inc
@@ -27,3 +27,13 @@ EXTRA_OECONF = --with-newlib \
do_compile () {
oe_runmake all-gcc all-target-libgcc
}
+#
On 12-07-24 12:52 PM, Mark Hatle wrote:
On 7/24/12 11:39 AM, Yao Zhao wrote:
On 12-07-24 11:47 AM, Phil Blundell wrote:
On Tue, 2012-07-24 at 11:45 -0400, Yao Zhao wrote:
In the Makefile, libbz2.so.0 is installed before bzip2, but the
installation is make -j xxx install. Then this could
On 12-07-24 12:00 PM, Yao Zhao wrote:
On 12-07-24 11:34 AM, Richard Purdie wrote:
On Tue, 2012-07-24 at 14:57 +0100, Burton, Ross wrote:
On 24 July 2012 14:49, Yao Zhao yao.z...@windriver.com wrote:
when bzip2-native is installed in parallel to sysroot, it is
possible that
some packages are
On 7/24/12 8:57 AM, Burton, Ross wrote:
On 24 July 2012 14:49, Yao Zhao yao.z...@windriver.com wrote:
when bzip2-native is installed in parallel to sysroot, it is possible that
some packages are using bzip2 to unpack, there are chances that bzip2 is
installed to sysroot but libbz2.so.0 not
On Tue, 2012-07-24 at 13:39 -0500, Mark Hatle wrote:
On 7/24/12 8:57 AM, Burton, Ross wrote:
On 24 July 2012 14:49, Yao Zhao yao.z...@windriver.com wrote:
when bzip2-native is installed in parallel to sysroot, it is possible that
some packages are using bzip2 to unpack, there are chances
On 12-07-24 03:07 PM, Richard Purdie wrote:
On Tue, 2012-07-24 at 13:39 -0500, Mark Hatle wrote:
On 7/24/12 8:57 AM, Burton, Ross wrote:
On 24 July 2012 14:49, Yao Zhao yao.z...@windriver.com wrote:
when bzip2-native is installed in parallel to sysroot, it is possible that
some packages are
On Tue, 2012-07-24 at 15:25 -0400, Yao Zhao wrote:
On 12-07-24 03:07 PM, Richard Purdie wrote:
On Tue, 2012-07-24 at 13:39 -0500, Mark Hatle wrote:
On 7/24/12 8:57 AM, Burton, Ross wrote:
On 24 July 2012 14:49, Yao Zhao yao.z...@windriver.com wrote:
when bzip2-native is installed in
On Tue, 2012-07-24 at 14:32 -0400, Yao Zhao wrote:
On 12-07-24 12:00 PM, Yao Zhao wrote:
On 12-07-24 11:34 AM, Richard Purdie wrote:
On Tue, 2012-07-24 at 14:57 +0100, Burton, Ross wrote:
On 24 July 2012 14:49, Yao Zhao yao.z...@windriver.com wrote:
when bzip2-native is installed in
Signed-off-by: Mark Hatle mark.ha...@windriver.com
---
.../binutils/binutils/binutils-armv5e.patch|4
.../ossp-uuid/0001-Change-library-name.patch |7 +++
...erve-m-option-status-in-v-option-handling.patch |7 +++
.../ossp-uuid/0003-Fix-whatis-entries.patch
Add missing Upstream-Status entries, no code changes.
The following changes since commit 4148bc80c008d25c8a536c7c7dfdeac1669a6662:
libgcc: Add missing dependency on libc:do_package (2012-07-24 10:12:08 +0100)
are available in the git repository at:
git://git.pokylinux.org/poky-contrib
On 07/24/2012 06:49 PM, Richard Purdie wrote:
On Tue, 2012-07-24 at 18:19 +0800, Robert Yang wrote:
The native python binary has been moved from usr/bin/python to
usr/bin/python-native/python, the recipe which needs python-native
should inherit pythonnative, otherwise there would be errors
49 matches
Mail list logo
