On Fri, 2014-08-29 at 22:45 -0500, Peter A. Bigot wrote:
Unlike normal builds of a gcc toolchain, OE builds the runtime libraries
separately in gcc-runtime and using the machine's tuning flags which
include the architecture. The flags affect how atomic operations are
implemented in the
On Fri, 2014-08-29 at 11:40 -0400, Jate Sujjavanich wrote:
There's a commit in poky's master-next with the message bitbake:
runqueue: Fix setscene tasks not running.
Should it fix the problem fixed by my patch?
No, your patch does need to merge, I've done that.
Cheers,
Richard
--
The following changes since commit d2fbc55d6863a767e69092bac686c02c3ec34650:
populate_sdk_base: Remap TOOLCHAIN_HOST_TASK variable (2014-08-28 15:12:31
+0100)
are available in the git repository at:
git://git.openembedded.org/openembedded-core-contrib rbt/libpam
The commit df3038768f59f7a0c814974ff674d4e59cbdfca4 changed 'libpam' to
'pn', then we don't need the MLPREFIX + pn any more, otherwise we
would get the name like: lib32-lib32-libpam-x, and the warn:
WARNING: QA Issue: lib32-pam-plugin-access rdepends on
lib32-lib32-libpam-suffix, but it isn't a
Hello,
I've sent a patch to fix the warning like:
WARNING: QA Issue: lib32-pam-plugin-access rdepends on
lib32-lib32-libpam-suffix, but it isn't a build dependency? [build-deps]
WARNING: QA Issue: lib32-pam-plugin-cracklib rdepends on
lib32-lib32-libpam-suffix, but it isn't a build
On 08/30/2014 02:49 AM, Richard Purdie wrote:
On Fri, 2014-08-29 at 22:45 -0500, Peter A. Bigot wrote:
Unlike normal builds of a gcc toolchain, OE builds the runtime libraries
separately in gcc-runtime and using the machine's tuning flags which
include the architecture. The flags affect how
On 8/29/14, 5:32 PM, Richard Purdie wrote:
On Fri, 2014-08-29 at 17:13 -0500, Mark Hatle wrote:
On 8/29/14, 5:02 PM, Richard Purdie wrote:
On Fri, 2014-08-29 at 13:36 -0500, Mark Hatle wrote:
Going back in time, I remember us specifically talking about directory
ownership and how we likely
On Sat, 2014-08-30 at 00:38 -0400, Bruce Ashfield wrote:
Rather than attempting to condition the entire tree to machine SRCREV (since
we don't know what branch will be built), we can instead wait until patching
has completed and then confirm that we are indeed building a decendant of the
On Sat, Aug 30, 2014 at 7:16 AM, Robert Yang liezhi.y...@windriver.com wrote:
I've sent a patch to fix the warning like:
WARNING: QA Issue: lib32-pam-plugin-access rdepends on
lib32-lib32-libpam-suffix, but it isn't a build dependency? [build-deps]
WARNING: QA Issue: lib32-pam-plugin-cracklib
On Sun, Aug 17, 2014 at 10:55 AM, Richard Purdie
richard.pur...@linuxfoundation.org wrote:
On Sun, 2014-08-17 at 10:33 +0200, Jacob Kroon wrote:
On Sat, Aug 2, 2014 at 10:54 AM, Richard Purdie
richard.pur...@linuxfoundation.org wrote:
[This is an RFC which depends on a patch to
On 08/30/2014 02:49 AM, Richard Purdie wrote:
On target is harder however the on target gcc is compiled to a specific
PACKAGE_ARCH so we should be able to put specific tuning into that gcc.
It does sound like the changes to gcc-configure-common.inc were not the
way to resolve this though, I'd
For a full description of the changes see:
http://mm.icann.org/pipermail/tz-announce/2014-August/24.html
Signed-off-by: Armin Kuster akuster...@gmail.com
---
meta/recipes-extended/tzdata/tzdata_2014f.bb | 6 --
meta/recipes-extended/tzdata/tzdata_2014g.bb | 6 ++
2 files changed, 6
The readme md5sum changed do you wording changes.
Signed-off-by: Armin Kuster akuster...@gmail.com
---
meta/recipes-extended/tzcode/tzcode-native.inc | 2 +-
meta/recipes-extended/tzcode/tzcode-native_2014f.bb | 11 ---
meta/recipes-extended/tzcode/tzcode-native_2014g.bb | 11
On Sat, Aug 30, 2014 at 9:55 AM, Richard Purdie
richard.pur...@linuxfoundation.org wrote:
On Sat, 2014-08-30 at 00:38 -0400, Bruce Ashfield wrote:
Rather than attempting to condition the entire tree to machine SRCREV (since
we don't know what branch will be built), we can instead wait until
On 2014-08-30, 9:55 AM, Richard Purdie wrote:
On Sat, 2014-08-30 at 00:38 -0400, Bruce Ashfield wrote:
Rather than attempting to condition the entire tree to machine SRCREV (since
we don't know what branch will be built), we can instead wait until patching
has completed and then confirm that we
15 matches
Mail list logo
