On Wed, Jan 17, 2018 at 1:58 PM, Andrea Galbusera wrote:
> Hi!
>
> On Wed, Jan 17, 2018 at 1:46 PM, Mathias Rudnik
> wrote:
>> Hello,
>>
>> I am trying to build libepoxy but the do_compile tasks breaks.
>> I found following error messages in the logs:
>>
>> arm-poky-linux-gnueabi-gcc -march=armv6
On 18 January 2018 at 08:58, Andrea Galbusera wrote:
> Looks like my first guess was not that bad. Reverting below commit,
> which switched to meson build system brought my build back to green.
> Also CC-ing the patch author who might suggest further investigations.
>
So you've implicated the Me
On 01/18/2018 10:58 AM, Andrea Galbusera wrote:
Looks like my first guess was not that bad. Reverting below commit,
which switched to meson build system brought my build back to green.
Also CC-ing the patch author who might suggest further investigations.
libepoxy: convert to meson build
Add bbclass to BBFILES doesn't make any sense.
Signed-off-by: Robert Yang
---
meta-security-compliance/conf/layer.conf | 2 +-
meta-tpm/conf/layer.conf | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/meta-security-compliance/conf/layer.conf
b/meta-security
FWIW: here nativesdk-libepoxy fails in do_configure already since meson
conversion
FileNotFoundError: [Errno 2] No such file or directory:
'TOPDIR/tmp-glibc/work/x86_64-nativesdk-oesdk-linux/nativesdk-libepoxy/1.4.3-r0/build/meson-private/sanitycheckc.exe'
http://errors.yoctoproject.org/Errors/De
On 01/18/2018 12:00 PM, Martin Jansa wrote:
FWIW: here nativesdk-libepoxy fails in do_configure already since meson
conversion
FileNotFoundError: [Errno 2] No such file or directory:
'TOPDIR/tmp-glibc/work/x86_64-nativesdk-oesdk-linux/nativesdk-libepoxy/1.4.3-r0/build/meson-private/sanitycheck
Hi
2018-01-18 10:05 GMT+01:00 Alexander Kanavin <
alexander.kana...@linux.intel.com>:
> On 01/18/2018 10:58 AM, Andrea Galbusera wrote:
>
>>
>> Looks like my first guess was not that bad. Reverting below commit,
>> which switched to meson build system brought my build back to green.
>> Also CC-in
On Thu, Jan 18, 2018 at 2:13 PM, Max Krummenacher wrote:
> Hi
>
> 2018-01-18 10:05 GMT+01:00 Alexander Kanavin
> :
>>
>> On 01/18/2018 10:58 AM, Andrea Galbusera wrote:
>>>
>>>
>>> Looks like my first guess was not that bad. Reverting below commit,
>>> which switched to meson build system brought
On 01/18/2018 03:41 PM, Andrea Galbusera wrote:
Yes, this is coherent with what Alexander's commit message says. We
started building stuff in test/ while switching to meson...
If we can't easily fix the upstream ourself and/or reproduce outside
of OE to ask for help from upstream devels, IMO we s
2018-01-17 20:30 GMT+01:00 Bartosz Golaszewski :
> Hi,
>
> I'm working on a project in which a base linux distribution is built
> using yocto while a set of proprietary components is built with the
> generated SDK (-c populate_sdk).
>
> These components use cmake for building. While they build just
On Thu, Jan 18, 2018 at 4:05 AM, Alexander Kanavin <
alexander.kana...@linux.intel.com> wrote:
> On 01/18/2018 10:58 AM, Andrea Galbusera wrote:
>
>>
>> Looks like my first guess was not that bad. Reverting below commit,
>> which switched to meson build system brought my build back to green.
>> Al
Hi all,
I want to add the Python 3 custom package foo to my native host tools to execute
its executable in a class. How could I do that? I already inherited distutils3
to my foo recipe, but when I launch foo with oe-run-native, the error
pkg_resources.DistributionNotFound: The 'foo=1.0' distribut
Hi,
I've updated my recipe to use a review from a non master branch:
Old version [python3-senichub_git.bb]:
inherit setuptools3
PROVIDES += "python3-senic-hub"
RPROVIDES_${PN} += "python3-senic-hub"
S = "${WORKDIR}/git"
SRC_URI = "git://github.com/getsenic/senic-hub.git;"
I'd check (using oe-pkgdata-util and/or buildhistory-diff) that the new
package is building the same files and packages as the old one. If PN
wasn't being generated, that would explain why the provides isn't working.
Ross
On 18 January 2018 at 14:46, Alan Martinovic
wrote:
> Hi,
> I've updated
I can confirm adding #include to test/egl_common.c gets past
the original error, but then fails with:
Log data follows:
| DEBUG: Executing shell function do_compile
| [1/2] Compiling c object 'test/glx_beginend@exe/glx_beginend.c.o'
| [2/2] Linking target test/glx_beginend
| FAILED: test/glx_beg
A release candidate build for yocto-2.2.3.rc2 is now available at:
https://autobuilder.yocto.io/pub/releases/yocto-2.2.3.rc2
Please begin QA on this build as soon as possible.
Build hash information:
meta-intel : c781510a5a6b45e60cc32b6614ddcce3f1452121
meta-qt4 : f389368dc86e745df14ca
On Mon, Jan 15, 2018 at 9:20 PM, Trevor Woerner wrote:
> On Thu, Jan 11, 2018 at 12:26 AM, Robert Yang
> wrote:
>>
>> BUILD_ID = "${@time.strftime('%Y-%m-%d %H:%M:%S',time.localtime())}"
>
> Brilliant! Why isn't this the default?
Using localtime could cause confusion for teams which span differe
On Thu, Jan 18, 2018 at 10:05 AM, Michael Gloff wrote:
> I can confirm adding #include to test/egl_common.c gets past
> the original error, but then fails with:
>
>
thank you for checking :-)
>
>
> Log data follows:
> | DEBUG: Executing shell function do_compile
> | [1/2] Compiling c object 't
Set RPATH to ORIGIN as supported by gcc/ld (-rpath=\$ORIGIN)
Observed issue on poky master was:
ld: warning: libconnectivity_abstraction.so, \
needed by out/yocto/x86_64/release/liboctbstack.so,
not found (try using -rpath or -rpath-link)
out/yocto/x86_64/release/liboctbstack.so: \
unde
Note that SECURITY is now enabled but might cause issues on some examples.
Bug: https://jira.iotivity.org/browse/IOT-2651
Signed-off-by: Philippe Coval
---
README | 2 +-
...ging-Return-false-boolean-instead-of-enum.patch | 40 ++
recipes-core/iotiv
Since IoTivity-1.3.0
Signed-off-by: Philippe Coval
---
.../files/0002-build-Use-pkg-config.patch | 43 ++
.../iotivity-simple-client_1.1.0.bb| 8 +++-
2 files changed, 50 insertions(+), 1 deletion(-)
create mode 100644
recipes-apps/iotivity-simple-
Since IoTivity-1.3.0
Signed-off-by: Philippe Coval
---
.../files/0003-server-Port-to-iotivity-1.2.0.patch | 68 ++
.../files/0004-build-Use-pkg-config.patch | 48 +++
.../iotivity-sensorboard_1.0.0.bb | 11
3 files changed, 127 inser
Note that fail on warning flag has been added,
and can be used in .bbappend if needed after reporting bugs:
http://wiki.iotivity.org/report
Bug: https://jira.iotivity.org/browse/IOT-2651
Signed-off-by: Philippe Coval
---
Origin:
https://github.com/tizenteam/meta-oic/tree/sandbox/pcoval/on/maste
From: Chin Huat Ang
Signed-off-by: Chin Huat Ang
Signed-off-by: Tim Orling
---
scripts/setup.sh | 26 +-
1 file changed, 13 insertions(+), 13 deletions(-)
diff --git a/scripts/setup.sh b/scripts/setup.sh
index 340364f..4b160ea 100755
--- a/scripts/setup.sh
+++ b/script
Thanks Trevor - going in the right direction. There are no "GL" includes or
libs in the recipe sysroot becuase userland does not provide it. Adding
mesa-gl to DEPENDS allows it to complete. Not sure if this is the correct
solution though.
Michael Gloff
On Thu, Jan 18, 2018 at 2:48 PM, Trevor Woer
From: Jackie Huang
'\>' is to matches the end of a word, but the executable is
not always a 'word', e.g. /usr/lib64/busybox/usr/bin/[
then such alternatives can not be removed.
So change to use '\s' in the pattern since the following
character of the $path is whitespace.
Signed-off-by: Jackie
From: Jackie Huang
'\>' is to matches the end of a word, but the executable is
not always a 'word', e.g. /usr/lib64/busybox/usr/bin/[
then such alternatives can not be removed.
So change to use '\s' in the pattern since the following
character of the $path is whitespace.
Signed-off-by: Jackie
Sorry I forgot adding opkg-devel, so I just re-sent with opkg-devel added in.
Thanks,
Jackie
> -Original Message-
> From: yocto-boun...@yoctoproject.org [mailto:yocto-
> boun...@yoctoproject.org] On Behalf Of jackie.hu...@windriver.com
> Sent: Friday, January 19, 2018 10:54
> To: yocto@yo
On Thu, Jan 18, 2018 at 5:49 AM, Alexander Kanavin
wrote:
> On 01/18/2018 03:41 PM, Andrea Galbusera wrote:
>>
>> Yes, this is coherent with what Alexander's commit message says. We
>> started building stuff in test/ while switching to meson...
>> If we can't easily fix the upstream ourself and/or
Hi,
I was looking for a way to analyze in more detail how packages of different
licenses was used in an image, and stumbled upon this old mail-thread:
https://lists.yoctoproject.org/pipermail/yocto/2015-January/023307.html
My end goal is pretty much the same as Clemens, that I want to be able t
2018-01-17 17:11 GMT+01:00 Herman van Hazendonk :
> Hi Philippe,
>
> You might want to try to patch your kernel for newer GCC versions. We've
> done that successfully with our 3.4 based kernels. See for example the
> commits we used on our LG Hammerhead (Nexus 5) kernel.
> https://github.com/Halium
On 01/19/2018 05:29 AM, Andre McCurdy wrote:
Note that this same test does build fine in poky, so disabling the tests is
not a good fix. You should figure out what is about the non-poky EGL headers
that is causing the failure, and whether you need to configure the provider
of those headers differ
32 matches
Mail list logo
