Apply the same sort of changes to the Cortex-A17 tune as were done in commit
35392025f3236f5e5393f9cf0857732da9a2e503.
Signed-off-by: Trevor Woerner
---
meta/conf/machine/include/tune-cortexa17.inc | 52 ++--
1 file changed, 26 insertions(+), 26 deletions(-)
diff --git a
Dear Ross,
Thanks for your valuable time...As you said, I added “meta-oe” layer in
“bblayers.conf” . Now that Error got disappeared. Now it spits out the
following error..
winiston@winiston-VirtualBox:~/poky/build$ bitbake qt4e-demo-image
Loading cache: 100% |##| ETA:
On Mar 5, 2016 8:12 AM, "Ross Burton" wrote:
>
> The xmlto script uses bashisms and checks at configure time to find a bash
> binary. If the build host has /bin/sh as bash then this gets detected,
which
> causes problems in native builds if the sstate is then shared to a
machine with
> /bin/sh as
These patchset is against master next to fix previous uninative patches. They
most likely will not apply cleanly to master.
The following changes since commit dd359830ad267f9763e9c35493b2846fd2269234:
poky: Enable uninative (2016-03-04 17:15:56 +)
are available in the git repository at:
uninative changes the location of the IBM850 codepage used by mcopy. So
make sure to set GCONV_PATH to the correct location when using
uninative.
Signed-off-by: Randy Witt
---
meta/recipes-devtools/mtools/mtools_4.0.18.bb | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a
Set a variable so other metadata can easily tell where uninative is
located.
Signed-off-by: Randy Witt
---
meta/classes/uninative.bbclass | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/meta/classes/uninative.bbclass b/meta/classes/uninative.bbclass
index 7f242de..99dee20
From: Robert Joslyn
libgcc_s.so.1 is required by btrfs-tools at runtime for certain
operations, such as scrub.
Signed-off-by: Robert Joslyn
---
meta/recipes-devtools/btrfs-tools/btrfs-tools_4.1.2.bb | 1 +
1 file changed, 1 insertion(+)
diff --git a/meta/recipes-devtools/btrfs-tools/btrfs-too
On 5 March 2016 at 00:09, Burton, Ross wrote:
> * a codepage issue with mcopy (uninative)
>>
>
> My hunch is that we need to add the utf8 gconv module to the tarball?
>
My hunch was probably wrong.
stracing the mcopy shows that it's trying to open the gconv files from the
proper native sysroot
Apply a patch taken from Gentoo to hopefully fix the remaining parallel make
races.
Signed-off-by: Ross Burton
---
.../openssl/openssl/parallel.patch | 326 +
.../recipes-connectivity/openssl/openssl_1.0.2g.bb | 1 +
2 files changed, 327 insertions(+)
creat
The xmlto script uses bashisms and checks at configure time to find a bash
binary. If the build host has /bin/sh as bash then this gets detected, which
causes problems in native builds if the sstate is then shared to a machine with
/bin/sh as dash.
Signed-off-by: Ross Burton
---
meta/recipes-de
Signed-off-by: Ross Burton
---
meta/recipes-extended/xdg-utils/xdg-utils_1.1.1.bb | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/meta/recipes-extended/xdg-utils/xdg-utils_1.1.1.bb
b/meta/recipes-extended/xdg-utils/xdg-utils_1.1.1.bb
index 6f66c6e..c1472cf 100644
On 4 March 2016 at 22:51, Richard Purdie wrote:
> * a codepage issue with mcopy (uninative)
>
My hunch is that we need to add the utf8 gconv module to the tarball?
Ross
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
ht
do_compile does this but do_install needs same env as well
Signed-off-by: Khem Raj
---
meta/recipes-extended/net-tools/net-tools_1.60-26.bb | 4
1 file changed, 4 insertions(+)
diff --git a/meta/recipes-extended/net-tools/net-tools_1.60-26.bb
b/meta/recipes-extended/net-tools/net-tools_1.
This patch is no longer required as upstreamed has fixed
the problem in more comprehensive way
Signed-off-by: Khem Raj
---
...001-Remove-the-check-for-LINUX-glibc-case.patch | 35 --
meta/recipes-support/nspr/nspr_4.12.bb | 11 ++-
2 files changed, 3 insertion
The xmlto script uses bashisms and checks at configure time to find a bash
binary. If the build host has /bin/sh as bash then this gets detected, which
causes problems in native builds if the sstate is then shared to a machine with
/bin/sh as dash.
Signed-off-by: Ross Burton
---
meta/recipes-de
On Fri, Mar 4, 2016 at 3:23 PM, Khem Raj wrote:
> On Sat, Mar 5, 2016 at 6:33 AM, Richard Purdie
> wrote:
>>
>> +# https://wiki.debian.org/GCC5
>> +# We may see binaries built with gcc5 run or linked into gcc4 environment
>> +# so use the older libstdc++ standard for now until we don't support gc
On 4 March 2016 at 22:51, Richard Purdie wrote:
> * some xmlto execution issue
>
/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-ppc-lsb/build/build/tmp/sysroots/x86_64-linux/usr/bin/xmlto.real:
Bad substitution
This is a bashism in a /bin/sh script. Patch incoming!
Ross
--
__
On 4 March 2016 at 22:51, Richard Purdie wrote:
> * parallel make race in openssl (borrow patches from other distro?)
>
Assuming my build test passes, expect a patch for this one shortly.
Ross
--
___
Openembedded-core mailing list
Openembedded-core@l
On Sat, Mar 5, 2016 at 6:33 AM, Richard Purdie
wrote:
>
> +# https://wiki.debian.org/GCC5
> +# We may see binaries built with gcc5 run or linked into gcc4 environment
> +# so use the older libstdc++ standard for now until we don't support gcc4
> +# on the host system.
> +BUILD_CXXFLAGS_append = "
On Thu, 2016-03-03 at 14:23 +, Richard Purdie wrote:
> Things which still break:
>
> * rpm upgrade causes smart remove to not function
> * gobject-introspection breaks on multilib with python-pygobject file
> location issue
> * gobject-introspection fails on musl
> * createrepo has occasiona
Hi Khem,
I'm trying to get the autobuilders to use uninative and in wider
deployment we're seeing errors like:
https://autobuilder.yoctoproject.org/main/builders/nightly-x86-64/build
s/700/steps/BuildImages/logs/stdio
x86_64-linux-libtool: link: gcc
-isystem/home/pokybuild/yocto-autobuilder/yo
This looks good to me
On Mar 5, 2016 12:28 AM, "Richard Purdie" <
richard.pur...@linuxfoundation.org> wrote:
> Prelinking on x86-64 wasn't working out the box as it uses /lib and
> not /lib64 for libs. Prelink was refusing to link as the dynamic loader
> didn't match its idea of the right path. Pa
On Sun, 2016-01-31 at 16:10 +0800, guojian.z...@windriver.com wrote:
> From: Guojian Zhou
>
> The vendor proprietary rpms should be packaged into the
> "vendor_proprietary_extensions" directory. Add the
> "PACKAGE_VENDOR_REPO"
> to allow the recipes select the required packages directory.
>
> Si
On 4 Mar 2016 11:23 a.m., "Christopher Larson" wrote:
>
>
>
> On Tue, Sep 29, 2015 at 10:09 AM Khem Raj wrote:
>>
>>
>> > On Sep 29, 2015, at 6:27 AM, Richard Purdie <
richard.pur...@linuxfoundation.org> wrote:
>> >
>> > Prelinking on x86-64 wasn't working out the box as it uses /lib and
>> > not
On Fri, Mar 04, 2016 at 11:02:38AM -0600, Mark Hatle wrote:
> On 3/4/16 10:51 AM, Denys Dmytriyenko wrote:
> > On Fri, Mar 04, 2016 at 08:46:01AM -0800, akuster wrote:
> >>
> >>
> >> On 03/04/2016 07:39 AM, Denys Dmytriyenko wrote:
> >>> On Tue, Mar 01, 2016 at 11:37:21PM -0800, Armin Kuster wrote:
[Re: runtime regression with "x86/mm/pat: Emulate PAT when it is disabled"] On
03/03/2016 (Thu 22:02) Toshi Kani wrote:
> On Thu, 2016-03-03 at 15:59 -0500, Paul Gortmaker wrote:
> > So, the yocto folks moved from 4.1 to 4.4 and one of their automated
> > qemu x86-32 boot tests started failing.
Integrating the folliwing patch series from Cal:
This patch series refactors the ktypes so that base and standard ktypes
do not enable EMBEDDED, EXPERT, or DEBUG_KERNEL. The reason this
decision was made is because production platforms likely do not want
DEBUG_KERNEL enabled, and EMBEDDED
On Tue, Sep 29, 2015 at 10:09 AM Khem Raj wrote:
>
> > On Sep 29, 2015, at 6:27 AM, Richard Purdie <
> richard.pur...@linuxfoundation.org> wrote:
> >
> > Prelinking on x86-64 wasn't working out the box as it uses /lib and
> > not /lib64 for libs. Prelink was refusing to link as the dynamic loader
uninative needs to adjust NATIVELSBSTRING fairly late in the
configuration parsing process but the sstate code encodes it into
variables. Since this string doesn't vary on a per recipe basis, we
defer its expansion until usage time.
Signed-off-by: Richard Purdie
diff --git a/meta/classes/sstate.
On 3/4/16 10:51 AM, Denys Dmytriyenko wrote:
> On Fri, Mar 04, 2016 at 08:46:01AM -0800, akuster wrote:
>>
>>
>> On 03/04/2016 07:39 AM, Denys Dmytriyenko wrote:
>>> On Tue, Mar 01, 2016 at 11:37:21PM -0800, Armin Kuster wrote:
From: Armin Kuster
CVE-2016-0800 SSL/TLS: Cross-protoco
On Fri, Mar 04, 2016 at 08:46:01AM -0800, akuster wrote:
>
>
> On 03/04/2016 07:39 AM, Denys Dmytriyenko wrote:
> > On Tue, Mar 01, 2016 at 11:37:21PM -0800, Armin Kuster wrote:
> >> From: Armin Kuster
> >>
> >> CVE-2016-0800 SSL/TLS: Cross-protocol attack on TLS using SSLv2 (DROWN)
> >>
> >> ht
The previous attempt at soft-failing when uninative was enabled didn't actually
work, because the workers didn't evaluate the function that actually enabled
uninative.
In a BuildStarted handler we can check if we need to download or extract the
uninative tarball.
In a ConfigParsed handler on the
On Tue, Mar 01, 2016 at 11:37:21PM -0800, Armin Kuster wrote:
> From: Armin Kuster
>
> CVE-2016-0800 SSL/TLS: Cross-protocol attack on TLS using SSLv2 (DROWN)
>
> https://www.openssl.org/news/secadv/20160301.txt
>
> Signed-off-by: Armin Kuster
> ---
> .../openssl/openssl/CVE-2016-0800.patch
uninative has some specific setup requirements. Rather than have everyone
doing this themselves, do this centrally and allow people to opt into it
based on some Yocto Project builds of the uninative tarballs.
Signed-off-by: Richard Purdie
diff --git a/meta/conf/distro/include/yocto-uninative.inc
Prelinking on x86-64 wasn't working out the box as it uses /lib and
not /lib64 for libs. Prelink was refusing to link as the dynamic loader
didn't match its idea of the right path. Passing in the --dyanmic-linker
option avoids this.
We can share code from image-mklibs so abstract that into a new c
Prelink contains some hardcoded assumptions about the path layout of
the target system. Unfortunately if the system doesn't match, prelink
doesn't work. This breaks:
a) prelink of those images
b) the unsafe-references-in-binaries QA test (which uses prelink-rtld)
One way to work around this is to
When installing the eSDK, if setscene task fail for some reason, the tests
would ignore this. This is bad since we assume they're working.
This adds some sanity test code which detects if setscene tasks are
needing to run and errors if there are any.
Signed-off-by: Richard Purdie
diff --git a
Current Dev Position: YP 2.1 M4 (Stabilization only milestone.)
Next Deadline: YP 2.1 M3 Target release date is March 18, 2016
SWAT team rotation: Alejandro -> Jussi
https://wiki.yoctoproject.org/wiki/Yocto_Build_Failure_Swat_Team
Key Status/Updates:
*M3 is proving a challenge to s
On Fri, 2016-03-04 at 15:06 +0100, Pascal Bach wrote:
> > It really depends on your view of what the sysroot is used for. We
> > intentionally strip a variety of things out of it as things work
> > today
> > basically for size/performance reasons. If we start putting
> > debugging
> > source in the
2016-02-23 12:36 skrev Markus Lehtonen:
> It would seem reasonable
that do_unpack() always results in a pristine source
> tree. This patch
causes ${S} to be removed before unpacking sources.
>
> I didn't quite
understand what kind of "investigation" the following code
> comment in
do_unpack()
Previously this class copied the uninative tarball to a certain directory in the
assumption that is where uninative.bbclass is looking for it. However as this
is a variable in uninative.bbclass that can be changed, specify exactly where
the tarball is in the eSDK local.conf.
Also don't use string
> It really depends on your view of what the sysroot is used for. We
> intentionally strip a variety of things out of it as things work today
> basically for size/performance reasons. If we start putting debugging
> source in there, it will become huge and this will image the size of
> things like
On 4 March 2016 at 14:04, Martin Jansa wrote:
> Ups, sorry for noise
>
Thank god for that :)
Cheers,
Ross
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
On Fri, Mar 04, 2016 at 03:02:12PM +0100, Martin Jansa wrote:
> On Thu, Mar 03, 2016 at 09:01:13PM +, Ross Burton wrote:
> > If gdb was configured to use the internal readline but static libraries were
> > disabled, gdb wouldn't dutifully not build libreadline.a which was a problem
> > when it
On 4 March 2016 at 14:02, Martin Jansa wrote:
> Somehow this caused hardfloat builds to fail
>
Can you verify that removing --disable-static from gdb fixes this?
Ross
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http
On Thu, Mar 03, 2016 at 09:01:13PM +, Ross Burton wrote:
> If gdb was configured to use the internal readline but static libraries were
> disabled, gdb wouldn't dutifully not build libreadline.a which was a problem
> when it tried to link with that library.
>
> Solve this by ensuring --enable-
On Fri, Dec 04, 2015 at 08:57:04PM +0530, Jagadeesh Krishnanjanappa wrote:
> Ping.
> Any updates regarding this patch?
Ping.
AFAIK: This still wasn't applied in master nor jethro - I just got 250+
these warnings in small(ish) Jethro build.
$ grep "WARNING: QA Issue: .*/licenses/" consoleText.txt
On Tue, 2016-02-23 at 15:09 +0100, Pascal Bach wrote:
> Currently debugging using sysroots seems to work as long as the work
> folder containing the original source is available.
> Once this work dir is gone the debugger is no longer able to find the
> source code. This is especially confusing if s
Hi Richard,
> -Original Message-
> From: openembedded-core-boun...@lists.openembedded.org
> [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf
> Of Richard Purdie
> Sent: Thursday, March 03, 2016 10:23 PM
> To: openembedded-core
> Subject: [OE-core] Status of M3
>
> I'm
Test that layer git revisions are displayed and
do not fail without git repository.
fix for [YOCTO #8852]
Signed-off-by: Daniel Istrate
---
meta/lib/oeqa/selftest/buildoptions.py | 43 +-
1 file changed, 42 insertions(+), 1 deletion(-)
diff --git a/meta/lib/oeqa
Test that layer git revisions are displayed and
do not fail without git repository.
fix for [YOCTO #8852]
Signed-off-by: Daniel Istrate
---
meta/lib/oeqa/selftest/buildoptions.py | 43 +-
1 file changed, 42 insertions(+), 1 deletion(-)
diff --git a/meta/lib/oeqa
You might want to assure that S is a child of WORKDIR before wiping it.
Strange things would happen if someone tried setting S=$HOME in a recipe
(by mistake or just for experimenting).
On 23-02-16 12:36, Markus Lehtonen wrote:
Make sure that we have a pristine source tree after do_unpack.
[Y
On Fri, 2016-03-04 at 09:41 +, Zhenhua Luo wrote:
> > * meta-fsl-ppc breaks on eudev change (patch pending)
> > * meta-fsl-ppc breakage blocks AB artefact publishing
> [Luo Zhenhua-B19537] The eudev patch is merged, http://git.yoctoproje
> ct.org/cgit/cgit.cgi/meta-fsl
> -ppc/commit/?id=2642cf5
Test that layer git revisions are displayed and
do not fail without git repository.
fix for [YOCTO #8852]
Signed-off-by: Daniel Istrate
---
meta/lib/oeqa/selftest/buildoptions.py | 46 +-
1 file changed, 45 insertions(+), 1 deletion(-)
diff --git a/meta/lib/oeqa
Signed-off-by: Ross Burton
---
...nsparent-theme_0.1.1.bbappend => xcursor-transparent-theme_%.bbappend} | 0
1 file changed, 0 insertions(+), 0 deletions(-)
rename
meta-selftest/recipes-test/xcursor-transparent-theme/{xcursor-transparent-theme_0.1.1.bbappend
=> xcursor-transparent-theme_%.bba
Hi, Richard:
Could you please give me some information about how to do
"selftests for sstate sigs"? Thank you.
On 03/01/2016 07:27 PM, Richard Purdie wrote:
On Tue, 2016-03-01 at 15:53 +0800, Zhou, Li wrote:
Please refer to Peter Seebach's patch earlier:
http://lists.openembedded.or
On 4 March 2016 at 04:23, wrote:
> ERROR: Nothing PROVIDES 'gd' (but
> /home/winiston/poky/meta/recipes-qt/navit/navit_svn.bb DEPENDS on or
> otherwise requires it). Close matches:
>
gd is part of meta-oe. Instead of copying a few files and assuming that
you know what you're doing, add the enti
ping!
No comment on this topic?
Am 23.02.2016 um 15:09 schrieb Pascal Bach:
> Hi Everybody
>
> Currently debugging using sysroots seems to work as long as the work folder
> containing the original source is available.
> Once this work dir is gone the debugger is no longer able to find the source
58 matches
Mail list logo
