> On Oct 15, 2015, at 7:27 PM, Peter Seebach
> wrote:
>
> I'd like a second opinion on this. Without this, we had very strange build
> failures which ended up being using the build system g++ with the mingw
> "host" (in cross-canadian land, this would be the machine the compiler will
> run on)
From: Kai Kang
The following changes since commit e35c404537db0b46047fcb2ee7d3645e3e0935c5:
bitbake: toaster: Don't descend into directories for cached_layers
(2015-10-11 08:12:58 +0100)
are available in the git repository at:
git://git.yoctoproject.org/poky-contrib kangkai/sqlite3
http
From: Kai Kang
Upgrade sqlite from 3.8.10.2 to 3.9.0.
* update python function to get right SRC_URI
* drop 0001-using-the-dynamic-library.patch which use dynamic library
that it is done that way in new version
Signed-off-by: Kai Kang
---
.../files/0001-using-the-dynamic-library.patch |
Ping again ...
Thanks
Wenzong
On 07/15/2015 02:19 PM, wenzong@windriver.com wrote:
From: Li Wang
While runing:
$ systemctl restart rpcbind
$ systemctl status rpcbind
There are errors like below:
rpcbind[1722]: Cannot open '/tmp/rpcbind.xdr' file for reading, \
errno 2 (No such f
Hi All,
Will you going to merge this patch?
I have ever discuss with Robert Yang and he agreed to integrated it.
Thanks!
Jian
于 2015年10月08日 14:47, Jian Liu 写道:
The PACKAGES is not mapped with MLPREFIX when setting LICENSE_EXCLUSION
in base.bbclass. For example,
For libgcc-dev,
LICENSE
From: Wenzong Fan
* Pass global CFLAGS to build:
The CFLAGS does not pass to build at all since it was redefined by
mdadm Makefile:
CFLAGS = $(CWFLAGS) $(CXFLAGS) ...
This could be done by setting 'CXFLAGS="${CFLAGS}"'.
* Also fix ptest build error caused by global CFLAGS:
raid6check.c:
From: Wenzong Fan
V2 changes:
* update commit subject:
mdadm: fix CFLAGS invalid issue -> mdadm: fix CFLAGS and ptest issue
* rebase changes against latest master branch.
The following changes since commit 556c0ea92eb32ddb9c9a5e30a74b2ca24ac69c68:
lib/oe/image.py: Fix dependency handling
I'd like a second opinion on this. Without this, we had very strange build
failures which ended up being using the build system g++ with the mingw
"host" (in cross-canadian land, this would be the machine the compiler will
run on) headers. On study, the issue seems to be that libcpp is now being
bu
On Thu, Oct 15, 2015 at 5:57 PM, Pushpal Sidhu wrote:
> The source get's checked out into ${PN}-${PV}, not 'build'. Currently,
> building
> iw is broken because none of the source files are found.
>
First, this message doesn't make sense. You're implying that bitbake thinks
B is S, which it does
On Thu, Oct 15, 2015 at 10:27 AM, Benjamin Esquivel <
benjamin.esqui...@linux.intel.com> wrote:
> +def movefile(self, sourcefile, destdir):
> +try:
> +# FIXME: this check of movefile's return code to None should
> be
> +# fixed within the function to use only ex
The source get's checked out into ${PN}-${PV}, not 'build'. Currently, building
iw is broken because none of the source files are found.
Signed-off-by: Pushpal Sidhu
---
meta/recipes-connectivity/iw/iw_4.1.bb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/recipes-connec
Combining -fschedule-insns with the CFLAGS provided by syslinux (in
particular -fPIC and -mregparm) causes build failures with gcc 5.2.
Since -fschedule-insns is of questionable benefit for ia32, exclude
it from TUNE_CCARGS when building for x86.
Signed-off-by: Andre McCurdy
---
meta/recipes-de
On Thu, Oct 15, 2015 at 9:42 PM, Burton, Ross wrote:
> On 15 October 2015 at 18:26, Andreas Müller
> wrote:
>
>> I have several gtk3+ applications that stopped working. E.G
>> network-manager-applet has stopped working: running
>> nm-connection-editor fails with 'Couldn't open libGL.so.1'. Same f
bb.utils.remove, bb.utils.movefile and bb.utils.mkdirhier can throw
exceptions that need handling and proper error messages.
[YOCTO#8213]
Signed-off-by: Benjamin Esquivel
---
meta/lib/oe/sdk.py | 81 ++
1 file changed, 57 insertions(+), 24 del
On Thu, Oct 15, 2015 at 4:08 AM, Martin Jansa wrote:
> On Wed, Oct 14, 2015 at 11:40:35PM -0700, Khem Raj wrote:
>>
>> > On Oct 14, 2015, at 4:21 AM, Martin Jansa wrote:
>> >
>> > +# http://errors.yoctoproject.org/Errors/Details/20486/
>> > +ARM_INSTRUCTION_SET_armv4 = "arm"
>> > +ARM_INSTRUCTION
On Thu, Oct 15, 2015 at 3:02 AM, Phil Blundell wrote:
> On Wed, 2015-10-14 at 23:37 -0700, Khem Raj wrote:
>> > On Oct 14, 2015, at 2:38 PM, Andre McCurdy
>> > wrote:
>> >
>> > I'm seeing what looks like a gcc bug when building syslinux with
>> > certain combinations of TUNE_CCARGS. A specific co
From: Mariano Lopez
Some runtime tests will overwrite the setUp and tearDown methods
and this will cause the parent's method to not run at all. These
changes will fix the setUp and tearDown methods for the child classes.
The following changes since commit d302c98822efe2cb78a63b620aed1b94b4ed4a6
From: Mariano Lopez
Currently some of the runtime test overwrites
the setUp and tearDown methods provided by
oeRuntimeTest, this will avoid some checks
required when running the test suit.
This patch changes the setUp and tearDown methods
for their local counterparts, so when these
tests are cal
From: Mariano Lopez
In the current state there are some runtime test that
don't run the tearDown method fromm oeRuntimeTest class
because the tearDown class is overwritten in the child
class.
This change adds tearDownLocal method in oeRuntimeTest
class that will run after tearDown. This method c
On Thu, 2015-10-15 at 14:09 +0200, Martin Jansa wrote:
> What about consistency with less specific PACKAGE_ARCHs which use "t"
> to show if it was built with or without thumb?
For the generic architectures, the trailing "t" does serve a useful
purpose. There exist ARMv5 CPUs that can't run Thumb
Changed testcase decorator for TC test18_iso_image from 1264 to 1346.
Signed-off-by: Daniel Istrate
---
meta/lib/oeqa/selftest/wic.py | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/lib/oeqa/selftest/wic.py b/meta/lib/oeqa/selftest/wic.py
index 7625505..f4c22f7 100644
--
On Thu, Oct 15, 2015 at 12:51:29PM +0100, Phil Blundell wrote:
> On Thu, 2015-10-15 at 13:31 +0200, Martin Jansa wrote:
>
> > It's package architecture for binary feeds with -mtune=arm926ejs and
> > it
> > can be built with or without -mthumb, that's why packages can be
> > built
> > in arm926ejse
On Thu, 2015-10-15 at 13:31 +0200, Martin Jansa wrote:
> It's package architecture for binary feeds with -mtune=arm926ejs and
> it
> can be built with or without -mthumb, that's why packages can be
> built
> in arm926ejse or arm926ejste package feed.
Yes, I understand that. But the point is that
The toolchain install script suggest the user to source env_setup_script
from wrong path now. eg:
" Each time you wish to use the SDK in a new shell session, you need to
source the environment setup script e.g.
$ . /opt/poky/2.0//opt/poky/2.0/environment-setup-armv5e-poky-linux-gnueabi
"
fix it.
On Thu, Oct 15, 2015 at 11:49:52AM +0100, Phil Blundell wrote:
> On Tue, 2015-10-13 at 22:37 +0200, Jens Rehsack wrote:
> > When enabling tune for arm926ejs, poky optionally appends suffixes
> > for thumb and dsp support. Since sometimes arm926ejse (ARM code) and
> > sometime arm926ejste (thumb c
> Am 15.10.2015 um 12:49 schrieb Phil Blundell :
>
> On Tue, 2015-10-13 at 22:37 +0200, Jens Rehsack wrote:
>> When enabling tune for arm926ejs, poky optionally appends suffixes
>> for thumb and dsp support. Since sometimes arm926ejse (ARM code) and
>> sometime arm926ejste (thumb code) is used
On Wed, Oct 14, 2015 at 11:40:35PM -0700, Khem Raj wrote:
>
> > On Oct 14, 2015, at 4:21 AM, Martin Jansa wrote:
> >
> > +# http://errors.yoctoproject.org/Errors/Details/20486/
> > +ARM_INSTRUCTION_SET_armv4 = "arm"
> > +ARM_INSTRUCTION_SET_armv5 = "arm"
> > +
>
> would it make sense to have it
On Tue, 2015-10-13 at 22:37 +0200, Jens Rehsack wrote:
> When enabling tune for arm926ejs, poky optionally appends suffixes
> for thumb and dsp support. Since sometimes arm926ejse (ARM code) and
> sometime arm926ejste (thumb code) is used in PACKAGE_ARCH, allow
> both.
It seems like it is a bug
On Wed, 2015-10-14 at 23:37 -0700, Khem Raj wrote:
> > On Oct 14, 2015, at 2:38 PM, Andre McCurdy
> > wrote:
> >
> > I'm seeing what looks like a gcc bug when building syslinux with
> > certain combinations of TUNE_CCARGS. A specific combination which
> > fails is:
> >
> > TUNE_CCARGS = " -m32
> On Oct 15, 2015, at 12:03 AM, Andre McCurdy wrote:
>
> On Wed, Oct 14, 2015 at 11:37 PM, Khem Raj wrote:
>>
>>> On Oct 14, 2015, at 2:38 PM, Andre McCurdy wrote:
>>>
>>> I'm seeing what looks like a gcc bug when building syslinux with
>>> certain combinations of TUNE_CCARGS. A specific com
On Wed, Oct 14, 2015 at 11:37 PM, Khem Raj wrote:
>
>> On Oct 14, 2015, at 2:38 PM, Andre McCurdy wrote:
>>
>> I'm seeing what looks like a gcc bug when building syslinux with
>> certain combinations of TUNE_CCARGS. A specific combination which
>> fails is:
>>
>> TUNE_CCARGS = " -m32 -march=core
31 matches
Mail list logo
