The following changes since commit 47d1fc9f5c38f3d092937c47bd4c2f45adaa7fe6:
qemu: fix Darwin cross-compilation (2014-08-18 20:43:24 +0100)
are available in the git repository at:
git://git.openembedded.org/openembedded-core-contrib ChenQi/sudo_volatile
The new version of sudo has fixed the problem and will create the
directory if it doesn't exist. So the configuration file is no longer
needed.
Signed-off-by: Chen Qi qi.c...@windriver.com
---
meta/recipes-extended/sudo/sudo_1.8.10p3.bb |7 ++-
1 file changed, 2 insertions(+), 5
On Sun, 2014-08-17 at 16:06 -0700, Armin Kuster wrote:
With this update, LGPLv3 or GPLv3 where added to many files.
Each supported algorithms govern which license they want.
Many are stated as ether v2 or v3 or both in parallel.
Update license to be v2 or LGPLv3 or GPLv3.
The previous
On Thu, 2014-08-14 at 17:20 -0300, Mario Domenech Goulart wrote:
Without this change, meta-openembedded's php recipe (as of 45e62fb8 --
php 5.4.14: use pkg-config for libxml2 detection) breaks with this
error on my system:
tmp/sysroots/x86_64-linux/usr/lib/libxml2.so: undefined reference
We should remove volatiles.99_sudo file also.
//Hongxu
On 08/21/2014 02:55 PM, Chen Qi wrote:
The new version of sudo has fixed the problem and will create the
directory if it doesn't exist. So the configuration file is no longer
needed.
Signed-off-by: Chen Qi qi.c...@windriver.com
---
The following changes since commit 47d1fc9f5c38f3d092937c47bd4c2f45adaa7fe6:
qemu: fix Darwin cross-compilation (2014-08-18 20:43:24 +0100)
are available in the git repository at:
git://git.openembedded.org/openembedded-core-contrib ChenQi/sudo_volatile
The new version of sudo has fixed the problem and will create the
directory if it doesn't exist. So the configuration file is no longer
needed.
Signed-off-by: Chen Qi qi.c...@windriver.com
---
meta/recipes-extended/sudo/files/volatiles.99_sudo |1 -
Hello Richard,
On Thu, Aug 21, 2014 at 4:50 AM, Richard Purdie
richard.pur...@linuxfoundation.org wrote:
On Thu, 2014-08-14 at 17:20 -0300, Mario Domenech Goulart wrote:
Without this change, meta-openembedded's php recipe (as of 45e62fb8 --
php 5.4.14: use pkg-config for libxml2 detection)
On Thu, 21 Aug 2014 08:50:51 +0100 Richard Purdie
richard.pur...@linuxfoundation.org wrote:
On Thu, 2014-08-14 at 17:20 -0300, Mario Domenech Goulart wrote:
Without this change, meta-openembedded's php recipe (as of 45e62fb8 --
php 5.4.14: use pkg-config for libxml2 detection) breaks with
http://www.openembedded.org/wiki/Bitbake_World_Status
== Failed tasks 2014-08-21 ==
=== common () ===
=== common-x86 (1) ===
* meta-browser/recipes-browser/chromium/chromium_37.0.2062.0.bb, do_compile
=== qemuarm (1) ===
*
On 08/21/2014 12:38 AM, Richard Purdie wrote:
On Sun, 2014-08-17 at 16:06 -0700, Armin Kuster wrote:
With this update, LGPLv3 or GPLv3 where added to many files.
Each supported algorithms govern which license they want.
Many are stated as ether v2 or v3 or both in parallel.
Update license
On 08/21/2014 12:38 AM, Richard Purdie wrote:
On Sun, 2014-08-17 at 16:06 -0700, Armin Kuster wrote:
With this update, LGPLv3 or GPLv3 where added to many files.
Each supported algorithms govern which license they want.
Many are stated as ether v2 or v3 or both in parallel.
Update license
Is there some way to specify incompatible licenses for native recipes? An
alternate mechanism might work,
but here is a case in which it would be valuable:
If I do not allow AGPL licenses, rpm builds with db-5. rpm-native builds with
db-6. When you try
to run rpm on the target it gets very
On Thu, Aug 21, 2014 at 11:33 AM, akuster808 akuster...@gmail.com wrote:
On 08/21/2014 12:38 AM, Richard Purdie wrote:
On Sun, 2014-08-17 at 16:06 -0700, Armin Kuster wrote:
With this update, LGPLv3 or GPLv3 where added to many files.
Each supported algorithms govern which license they
On 08/21/2014 09:55 AM, Otavio Salvador wrote:
On Thu, Aug 21, 2014 at 11:33 AM, akuster808 akuster...@gmail.com wrote:
On 08/21/2014 12:38 AM, Richard Purdie wrote:
On Sun, 2014-08-17 at 16:06 -0700, Armin Kuster wrote:
With this update, LGPLv3 or GPLv3 where added to many files.
Each
Every cortexa* chip I've encountered so far has been capable of
executing Thumb code, so it probably makes more sense to use
armv7at-neon instead of armv7a-neon as the DEFAULTTUNE. Choice
of code generation is controlled separately, by ARM_INSTRUCTION_SET.
Most packages tend to perform at
The various cortex chips generally support thumb code, so the armv7at
tunings are a better default for them than the plain armv7a tunings.
The armv7at tuning allows generation of both arm and thumb code, while
armv7a only allows arm code, which is typically significantly bigger.
(It may be faster
tmp-gcd_1.s: Assembler messages:
| tmp-gcd_1.s:94: Error: unsupported relocation against
BMOD_1_TO_MOD_1_THRESHOLD
| make[2]: *** [gcd_1.lo] Error 1
Signed-off-by: Armin Kuster akuster...@gmail.com
---
meta/recipes-support/gmp/gmp/gpm-6.0.0-ppc64.patch | 25 ++
While playing with adding qemuppc64, I found a build issue gpm.
Armin Kuster (1):
gpm: ppc64 build issue
meta/recipes-support/gmp/gmp/gpm-6.0.0-ppc64.patch | 25 ++
meta/recipes-support/gmp/gmp_6.0.0.bb | 1 +
2 files changed, 26 insertions(+)
create mode
Currently, IOErrors are just passed over due to the broken Exception
clause. A command like bitbake X | invalid command would break stdout
triggering a traceback. With these changes we print the exceptions, shut down
the server gracefully and exit which is a much nicer behaviour and is less
Our usage of multitprocessing is problematic. In particular, there is a bug
in python 2.7 multiprocessing where signals are not handled until command
completion instead of immediately.
This factors the multiprocess code into a function which is enhanced with
a workaround to ensure immediate
When processes terminate, we really want all of the child processes to
terminate too. This was not happening for worker processes which spawned their
own multiprocessing pools, leading to build hangs. This change ensures any
sigterm gets passed to the whole process group. In local tests, this
We may as well use the common function for this rather than
duplicating the code.
Signed-off-by: Richard Purdie richard.pur...@linuxfoundation.org
diff --git a/meta/classes/package.bbclass b/meta/classes/package.bbclass
index 23832b1..0ff5370 100644
--- a/meta/classes/package.bbclass
+++
On Thu, 2014-08-21 at 13:44 -0700, Armin Kuster wrote:
tmp-gcd_1.s: Assembler messages:
| tmp-gcd_1.s:94: Error: unsupported relocation against
BMOD_1_TO_MOD_1_THRESHOLD
| make[2]: *** [gcd_1.lo] Error 1
Signed-off-by: Armin Kuster akuster...@gmail.com
---
On Thu, 2014-08-21 at 12:27 -0700, akuster808 wrote:
On 08/21/2014 09:55 AM, Otavio Salvador wrote:
On Thu, Aug 21, 2014 at 11:33 AM, akuster808 akuster...@gmail.com wrote:
On 08/21/2014 12:38 AM, Richard Purdie wrote:
On Sun, 2014-08-17 at 16:06 -0700, Armin Kuster wrote:
With
tmp-gcd_1.s: Assembler messages:
| tmp-gcd_1.s:94: Error: unsupported relocation against
BMOD_1_TO_MOD_1_THRESHOLD
| make[2]: *** [gcd_1.lo] Error 1
V2: fixed PN name
Signed-off-by: Armin Kuster akuster...@gmail.com
---
meta/recipes-support/gmp/gmp/gmp-6.0.0-ppc64.patch | 25
On Thu, Aug 21, 2014 at 1:46 PM, Richard Purdie
richard.pur...@linuxfoundation.org wrote:
Our usage of multitprocessing is problematic. In particular, there is a bug
in python 2.7 multiprocessing where signals are not handled until command
completion instead of immediately.
This looks good,
27 matches
Mail list logo
