[yocto] Release Candidate Build for yocto-2.0.3.rc4.rc4 now available.

A release candidate build for yocto-2.0.3.rc4 is now available at: http://autobuilder.yoctoproject.org/pub/releases/yocto-2.0.3.rc4 Please begin QA on this build as soon as possible. Build hash information: meta-qt4 : 2c7f8df9039be498f8a2232d1428adb7f4e5e800 meta-intel :

Re: [yocto] ***SPAM*** Re: [meta-raspberrypi][PATCH] gstreamer1.0-plugins-bad: Don't hard wire use of userland

Hi Gary, That was a pretty crude way of doing something for testing purpose. If it works, obviously we should consider changing that in .bbappend in the meta-raspberrypi layer, and not outside. Cheers, Herve -Original Message- From: yocto-boun...@yoctoproject.org

[yocto] [[PATCH][yocto-autobuilder]] autobuilder/lib/buildsteps.py: BitbakeShellCommand fix errors on cmdComplete

In some cases commandComplete could be executed before stdio log observer creates a errors attribute. In order to avoid a crash adds hasattr validation. Signed-off-by: Aníbal Limón --- lib/python2.7/site-packages/autobuilder/lib/buildsteps.py | 2 +- 1 file

[yocto] Release Candidate Build for yocto-2.0.3.rc3.rc3 now available.

A release candidate build for yocto-2.0.3.rc3 is now available at: http://autobuilder.yoctoproject.org/pub/releases/yocto-2.0.3.rc3 Please begin QA on this build as soon as possible. Build hash information: meta-qt4 : 2c7f8df9039be498f8a2232d1428adb7f4e5e800 meta-intel :

Re: [yocto] Ignoring Fetch errors for optional source.

On Wed, Dec 7, 2016 at 5:13 AM, Beth 'pidge' Flanagan wrote: > > Yeah, unfortunately, people don't neccessarily know they're special if you > get my meaning. > > One way we've been trying this is like so: > > try: > fetcher = bb.fetch2.Fetch(extra_uri, d) >

Re: [yocto] Package depending on ATLAS, BLAS, libmetis, liblapack

On 12/07/2016 05:01 AM, Burton, Ross wrote: > On 7 December 2016 at 11:57, david bensoussan wrote: > >> Those are tuning libraries which cannot be cross compiled >> . >> > > One solution that really isn't too difficult is

Re: [yocto] cve-checker tool

On 7 December 2016 at 14:58, Mariano Lopez wrote: > > Those CVEs which are listed in the nvd.xml file under > "cpe:/a:haxx:libcurl: are not detected and reported by cve-check tool. > > In the case of libcurl, it is build using the curl recipe, and currently >

Re: [yocto] cve-checker tool

On 7 December 2016 at 14:58, Mariano Lopez wrote: > > We have more recipes which have CVE patches but they are not reported. > > I have analyzed these; some of these CVEs are still marked as reserved > on Mitre and are not present in the nvd.xml files (although

Re: [yocto] [meta-raspberrypi] Current master broken

On Wed, Dec 7, 2016 at 3:19 PM, Andrea Galbusera wrote: > On Tue, Dec 6, 2016 at 4:29 PM, Andrei Gherzan wrote: >> >> On Mon, Dec 5, 2016 at 4:50 PM, Khem Raj wrote: >> > On Sun, Dec 4, 2016 at 10:03 PM, Gary Thomas

Re: [yocto] [meta-raspberrypi] Current master broken

On Tue, Dec 6, 2016 at 4:29 PM, Andrei Gherzan wrote: > On Mon, Dec 5, 2016 at 4:50 PM, Khem Raj wrote: > > On Sun, Dec 4, 2016 at 10:03 PM, Gary Thomas wrote: > >> On 2016-12-05 01:54, Andrei Gherzan wrote: > >>> > >>> Hi Gary, > >>> >

Re: [yocto] cve-checker tool

On 06/12/16 08:41, Sona Sarmadi wrote: > Another qustion: > > We don't have recipes for libcurl, I guess both curl and libcurl CVEs are > patched in the curl recipes, right? > I think curl uses libcurl, and libcurl is built when building curl. > > Those CVEs which are listed in the nvd.xml

Re: [yocto] [matchbox-wm][PATCH 0/3] matchbox-window-manager fixes

On 7 December 2016 at 13:22, Jussi Kukkonen wrote: > One actual bug fix (YOCTO #10635) and a few build cleanups. > Looks good to me, push away. Ross -- ___ yocto mailing list yocto@yoctoproject.org

Re: [yocto] Ignoring Fetch errors for optional source.

On Wed, 2016-12-07 at 13:08 +, Burton, Ross wrote: > > On 7 December 2016 at 13:00, Beth 'pidge' Flanagan > om> wrote: > > I've an odd use case that I wonder if anyone has a work around/way > > of > > doing it. > > > > I've a client who has contractors who can't have access to a > > certain

[yocto] [matchbox-wm][PATCH 3/3] Fix "unused variable" warnings

Some were removed as unused, some just silenced with the gcc attribute since they were actually somehow used and fixing otherwise would have been more invasive. Signed-off-by: Jussi Kukkonen --- src/ewmh.c| 6 -- src/mbtheme.c | 7 --- src/wm.c | 2 +-

[yocto] [matchbox-wm][PATCH 2/3] matchbox-remote: Fix execvp() argument

The second argument is a NULL-terminated array. Signed-off-by: Jussi Kukkonen --- src/matchbox-remote.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/src/matchbox-remote.c b/src/matchbox-remote.c index 9f62523..e6cc076 100644 ---

[yocto] [matchbox-wm][PATCH 1/3] ewmh: Actually set _NET_CURRENT_DESKTOP

The property wasn't being set properly (both value and crucially number of elements were wrong), leading to an assert in debug chromium. Signed-off-by: Jussi Kukkonen --- src/ewmh.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/src/ewmh.c

[yocto] [matchbox-wm][PATCH 0/3] matchbox-window-manager fixes

One actual bug fix (YOCTO #10635) and a few build cleanups. Thanks, Jussi The following changes since commit 9fd1806dfa7c8f2202db18b7bc880857a3019f8c: Bump version, update bug-report URI (2016-06-02 14:46:42 +0300) are available in the git repository at:

Re: [yocto] Ignoring Fetch errors for optional source.

On 7 December 2016 at 13:00, Beth 'pidge' Flanagan wrote: > I've an odd use case that I wonder if anyone has a work around/way of > doing it. > > I've a client who has contractors who can't have access to a certain > segment of the code base. So for example, a recipe will

Re: [yocto] Package depending on ATLAS, BLAS, libmetis, liblapack

On 7 December 2016 at 11:57, david bensoussan wrote: > Those are tuning libraries which cannot be cross compiled > . > One solution that really isn't too difficult is to replace the places where it runs tests with simple

[yocto] Ignoring Fetch errors for optional source.

I've an odd use case that I wonder if anyone has a work around/way of doing it. I've a client who has contractors who can't have access to a certain segment of the code base. So for example, a recipe will have a SRC_URI for the main bit that everyone has access to, but an extra src_uri that some

[yocto] Package depending on ATLAS, BLAS, libmetis, liblapack

Hello, I am currently working on libraries which need *ATLAS, BLAS, libmetis, liblapack.* Those are tuning libraries which cannot be cross compiled . I created an image, compiled what I needed on it and then created recipes providing the libs

Re: [yocto] [meta-raspberrypi] Current master broken

On Wed, Dec 7, 2016 at 8:42 AM, Paul Barker wrote: > On Wed, 7 Dec 2016 07:25:23 + > Paul Barker wrote: > >> On Tue, 6 Dec 2016 21:17:55 -0500 >> Trevor Woerner wrote: >> >> > On Tue 2016-12-06 @ 11:00:34 PM, Paul Barker

Re: [yocto] yocto project in raspberry pi 3

On 2016-12-07 11:15, Rushin Thakkar wrote: hello there i am trying to do yocto project on raspberry pi 3. when i run bitbake rpi-basic-image. this task 0: bcm2835-bootfiles-20151021-r3 do_fetch (pid 4922) is taking too much time. after that You should use latest master where we

[yocto] yocto project in raspberry pi 3

hello there i am trying to do yocto project on raspberry pi 3. when i run bitbake rpi-basic-image. this task 0: bcm2835-bootfiles-20151021-r3 do_fetch (pid 4922) is taking too much time. after that You should use latest master where we have switched to tarball fetch especially

Re: [yocto] ***SPAM*** Re: [meta-raspberrypi][PATCH] gstreamer1.0-plugins-bad: Don't hard wire use of userland

On 2016-12-06 19:22, Herve Jourdain wrote: Hi Gary, Could you try a local to your layer gstreamer1.0-plugins-bad_%.bbappend, that would contain: PACKAGECONFIG_remove_rpi = " dispmanx" And see if it solves your problem? Yes, it does solve the problem, thanks. Although written this way and

Re: [yocto] [meta-raspberrypi] Current master broken

On Wed, 7 Dec 2016 07:25:23 + Paul Barker wrote: > On Tue, 6 Dec 2016 21:17:55 -0500 > Trevor Woerner wrote: > > > On Tue 2016-12-06 @ 11:00:34 PM, Paul Barker wrote: > > > Upstream effectively support one version, currently 4.4. When upstream > >

Re: [yocto] [meta-raspberrypi][PATCH] linux-raspberrypi-base.bbclass: allow -rt kernels

On Tue, Dec 6, 2016 at 7:37 PM, Andrei Gherzan wrote: > On Tue, Dec 06, 2016 at 06:27:32PM +, Andrei Gherzan wrote: >> On Mon, Nov 28, 2016 at 08:37:09PM -0500, Trevor Woerner wrote: >> > On Mon 2016-11-28 @ 03:16:11 PM, Khem Raj wrote: >> > > >> > > > On Nov 28, 2016, at