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 g
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
---
meta/recipes-support/gmp/gmp/gmp-6.0.0-ppc64.patch | 25 ++
meta/recipes-s
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 wrote:
> >>
> >>
> >> On 08/21/2014 12:38 AM, Richard Purdie wrote:
> >>>
> >>> On Sun, 2014-08-17 at 16:06 -0700, Armin Kuster wrote:
>
>
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
> ---
> meta/recipes-support/gmp/gmp/gpm-6.0.0-ppc6
We may as well use the common function for this rather than
duplicating the code.
Signed-off-by: Richard Purdie
diff --git a/meta/classes/package.bbclass b/meta/classes/package.bbclass
index 23832b1..0ff5370 100644
--- a/meta/classes/package.bbclass
+++ b/meta/classes/package.bbclass
@@ -931,13
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 resol
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 signal
Currently, IOErrors are just passed over due to the broken Exception
clause. A command like "bitbake X | " 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
confusion to the use
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 100
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
---
meta/recipes-support/gmp/gmp/gpm-6.0.0-ppc64.patch | 25 ++
meta/recipes-support/gmp/gmp_6.0.0
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 i
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 comparabl
On 08/21/2014 09:55 AM, Otavio Salvador wrote:
On Thu, Aug 21, 2014 at 11:33 AM, akuster808 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
On Thu, Aug 21, 2014 at 11:33 AM, akuster808 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 want.
>
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 up
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
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) ===
* meta-openembedded/meta-multimedia/recipes-mediacentre/xbmc/xbmc_
On Thu, 21 Aug 2014 08:50:51 +0100 Richard Purdie
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 this
>> error on my system:
>>
Hello Richard,
On Thu, Aug 21, 2014 at 4:50 AM, Richard Purdie
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 this
>> error on my
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
http://cgit.openembedded.org/cgit.c
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
---
meta/recipes-extended/sudo/files/volatiles.99_sudo |1 -
meta/recipes-extended/sudo/sudo_1.8.10p3.bb|7 ++
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
---
meta/recipes-extended/sudo
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 refe
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 previ
25 matches
Mail list logo