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

2016-12-07 Thread Poky Build User 

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 : 28c774bf25eec43020983416ad02a3b4307aaf0c 
meta-qt3 : b08996efbfb3b26e62b608f34ebf5e671b36ec61 
poky : adb34b8ddcd8cc34ae7d2b1b2e4b4d291d790f56 

\nThis is an automated message from\nThe Yocto Project Autobuilder\nGit: 
git://git.yoctoproject.org/yocto-autobuilder\nEmail: pi...@toganlabs.com 
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

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

2016-12-07 Thread Herve Jourdain 
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 [mailto:yocto-boun...@yoctoproject.org]
On Behalf Of Gary Thomas
Sent: mercredi 7 décembre 2016 11:25
To: yocto@yoctoproject.org
Subject: 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
putting it in local.conf forced every package that uses PACKAGECONFIG to be
rebuilt :-(

Perhaps a softer approach might be:
   PACKAGECONFIG_remove_pn-gstreamer1.0-plugins-bad = "dispmax"

Too bad though that this needs to be disabled to get X11 to work as it would
seem to be very useful in a high-need graphic environment.

>
> I've never built for "vc-graphics-hardfp", as I'm not sure if there 
> are benefits in using it over either using the userland or vc4, so I'm 
> not sure whether it can work without dispmanx, nor why it would not 
> compile with dispmanx enabled.
> But if this works, then we might need to consider to add an additional 
> case for not enabling dispmanx.
>
> Cheers,
> Herve
>
> -Original Message-
> From: Gary Thomas [mailto:g...@mlbassoc.com]
> Sent: mardi 6 décembre 2016 16:58
> To: Andrei Gherzan 
> Cc: Herve Jourdain ; yocto@yoctoproject.org
> Subject: ***SPAM*** Re: [yocto] [meta-raspberrypi][PATCH]
> gstreamer1.0-plugins-bad: Don't hard wire use of userland
>
> On 2016-12-06 16:48, Andrei Gherzan wrote:
>> On Tue, Dec 06, 2016 at 04:02:20PM +0100, Gary Thomas wrote:
>>> On 2016-12-06 13:45, Herve Jourdain wrote:
 Hi Gary,

 But dispmanx is really only provided by userland, it does not exist 
 in other flavors of egl/libgles.
 Actually, dispmanx should not be selected in PACKAGECONFIG if 
 userland is not in use for EGL/GLES.
>>>
>>> Fine, but I'm looking for a solution where I can choose to use 
>>> vc-graphics-hardfp so X11 works again and I can also have gst-player 
>>> which depends on gstreamer-1.0-bad
>>>
>>> Any ideas?
>>>
>>
>> Disabling dispamanx is not working?
>
> How might I do that?  It's not clear from [at least] that recipe.

--

Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

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

2016-12-07 Thread Aníbal Limón 
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 changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/python2.7/site-packages/autobuilder/lib/buildsteps.py 
b/lib/python2.7/site-packages/autobuilder/lib/buildsteps.py
index af7d334..717fcf2 100644
--- a/lib/python2.7/site-packages/autobuilder/lib/buildsteps.py
+++ b/lib/python2.7/site-packages/autobuilder/lib/buildsteps.py
@@ -145,7 +145,7 @@ class BitbakeShellCommand(ShellCommand):
 
 def commandComplete(self, cmd):
 if cmd.didFail():
-if self.errors['bitbake']:
+if hasattr(self, 'errors') and self.errors['bitbake']:
 buildername = self.getProperty('buildername')
 buildnumber = self.getProperty('buildnumber')
 
-- 
2.1.4

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

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

2016-12-07 Thread Poky Build User 

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 : 28c774bf25eec43020983416ad02a3b4307aaf0c 
meta-qt3 : b08996efbfb3b26e62b608f34ebf5e671b36ec61 
poky : adb34b8ddcd8cc34ae7d2b1b2e4b4d291d790f56 

\nThis is an automated message from\nThe Yocto Project Autobuilder\nGit: 
git://git.yoctoproject.org/yocto-autobuilder\nEmail: pi...@toganlabs.com 
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

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

2016-12-07 Thread Andre McCurdy 
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)
> fetcher.download()
> except:
> pass
>
> But this doesn't seem to be catching the fetch error.

Even if it did work, how is sstate etc going to handle the effective
SRC_URI not being known until after you've tried to fetch all the
sources?

Perhaps better to run a test for "specialness" and set an
"I_AM_SPECIAL" variable from (a wrapper for) oe-init-build-env.

> -b
>
>
> That might work, and also add determinism.
>
> Ross
>
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

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

2016-12-07 Thread Philip Balister 
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 to replace the places where
> it runs tests with simple scripts that generate the relevant output, and
> provide that output in the recipe.  So if  you were building for ARM you'd
> build once on arm, determine what the results of the tests are, and then
> put those values in the recipe.

Numpy (I think) has a script you run to collect information about the
system. Our recipe carries the output file and inserts it in the correct
place before building. I've been wondering if we can do this with atlas.
I haven't made it past the thinking phase though.

Philip

> 
> Ross
> 
> 
> 
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] cve-checker tool

2016-12-07 Thread Burton, Ross 
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
> cve-check class will look for BPN, so it won't check against libcurl.
> Can you open a bug for this?
>

A fix for this is trivial but we need a variable name.  Any objections or
better suggestions to CVE_PRODUCT?

Ross
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] cve-checker tool

2016-12-07 Thread Burton, Ross 
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 they are
> public (e.g. Busybox:
> > https://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-2147).
>
> cve-check-tool will only check against the database that got from the
> nvd.xml files, and these files won't have information for not yet fully
> disclosed CVEs, so that is why you will find these cases frequently in
> OE recipes (Armin does a great job with CVEs).
>

A lot of CVEs get reserved but never actually updated in MITRE.  This is
why the planned successor to cve-check-tool plans to download the Debian /
RHEL / etc security databases to fill in the gaps (I'm not sure what the
state of this rewrite is as we didn't write this tool).

Ross
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

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

2016-12-07 Thread Andrei Gherzan 
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  wrote:
>> >> On 2016-12-05 01:54, Andrei Gherzan wrote:
>> >>>
>> >>> Hi Gary,
>> >>>
>> >>>
>> >>> On Sat, Dec 3, 2016 at 2:16 PM, Paul Barker 
>> >>> wrote:
>> 
>>  On Sat, 3 Dec 2016 08:33:40 +0100
>>  Gary Thomas  wrote:
>> 
>> > I'm currently unable to build for the RaspberryPi-3 using the master
>> > branch:
>> >
>> > Build Configuration:
>> > BB_VERSION= "1.32.0"
>> > BUILD_SYS = "x86_64-linux"
>> > NATIVELSBSTRING   = "universal"
>> > TARGET_SYS= "arm-amltd-linux-gnueabi"
>> > MACHINE   = "raspberrypi3"
>> > DISTRO= "amltd"
>> > DISTRO_VERSION= "2.2+snapshot-20161202"
>> > TUNE_FEATURES = "arm armv7ve vfp thumb neon vfpv4
>> > callconvention-hard cortexa7"
>> > TARGET_FPU= "hard"
>> > meta  =
>> > "master:9e63f81c78e284c9b325fe04a1b59e61c7ad8a1a"
>> > meta-amltd=
>> > "master:074120ab3a82cea0ac50d4e9eec89130a860a4fa"
>> > meta-raspberrypi  =
>> > "master:44d41bf3e94c4c8fe5ad5a3650572c8d17ef36c9"
>> >
>> > Initialising tasks: 100%
>> > |#|
>> > Time:
>> > 0:00:00
>> > Checking sstate mirror object availability: 100%
>> > |#| Time: 0:00:00
>> > NOTE: Executing SetScene Tasks
>> > NOTE: Executing RunQueue Tasks
>> > ERROR: linux-raspberrypi-1_4.4.28+gitAUTOINC+5afda48c34-r0
>> > do_kernel_metadata: Function failed: do_kernel_metadata (log
>> > file is located at
>> >
>> >
>> > /build/rpi3_2016-09-13/tmp/work/raspberrypi3-amltd-linux-gnueabi/linux-raspberrypi/1_4.4.28+gitAUTOINC+5afda48c34-r0/temp/log.do_kernel_metadata.5647)
>> > ERROR: Logfile of failure stored in:
>> >
>> >
>> > /build/rpi3_2016-09-13/tmp/work/raspberrypi3-amltd-linux-gnueabi/linux-raspberrypi/1_4.4.28+gitAUTOINC+5afda48c34-r0/temp/log.do_kernel_metadata.5647
>> > Log data follows:
>> > | DEBUG: Executing shell function do_kernel_metadata
>> > | [ERROR]: processing of file /tmp/tmp.bXPr8PVPz3 failed
>> > |
>> >
>> > /build/rpi3_2016-09-13/tmp/sysroots/x86_64-linux/usr/bin/scc-cmds/patch.cmd:
>> > line 29: : No such file or directory
>> > |
>> > | Context around the error is:
>> > |
>> > | #
>> > | prefix
>> >
>> > /local/poky-cutting-edge/meta-raspberrypi/recipes-kernel/linux/linux-raspberrypi/
>> > | kconf non-hardware
>> >
>> > /local/poky-cutting-edge/meta-raspberrypi/recipes-kernel/linux/linux-raspberrypi/defconfig
>> > | prefix
>> >
>> > /local/poky-cutting-edge/meta-raspberrypi/recipes-kernel/linux/linux-raspberrypi-4.4/
>> > | patch
>> >
>> > "/local/poky-cutting-edge/meta-raspberrypi/recipes-kernel/linux/linux-raspberrypi-4.4/0001-fix-dtbo-rules.patch"
>> > | # run time: 0 seconds
>> > | # processed files:
>> > | # _cfg
>> >
>> > /local/poky-cutting-edge/meta-raspberrypi/recipes-kernel/linux/linux-raspberrypi/defconfig
>> > | # _cfg
>> >
>> > /local/poky-cutting-edge/meta-raspberrypi/recipes-kernel/linux/linux-raspberrypi-4.4/0001-fix-dtbo-rules.patch
>> > |
>> > | See pre-processed file /tmp/tmp.bXPr8PVPz3 for more details
>> > | #
>> > | # scc v0.8
>> > | # processed: Fri Dec  2 04:12:25 CET 2016
>> > | #
>> > | # This is a scc output file, do not edit
>> > | #
>> > | [ERROR]: processing of file /tmp/tmp.eTLAT789Q2 failed
>> > | # _reloc_dir
>> > /local/poky-cutting-edge/meta-raspberrypi/recipes-kernel/linux
>> > | # _reloc_dir
>> > /local/poky-cutting-edge/meta-raspberrypi/recipes-kernel/linux
>> > |
>> >
>> > /build/rpi3_2016-09-13/tmp/sysroots/x86_64-linux/usr/bin/scc-cmds/patch.cmd:
>> > line 29: : No such file or directory
>> > |
>> > | Context around the error is:
>> > |
>> > | #
>> > | prefix
>> >
>> > /local/poky-cutting-edge/meta-raspberrypi/recipes-kernel/linux/linux-raspberrypi/
>> > | kconf non-hardware
>> >
>> > /local/poky-cutting-edge/meta-raspberrypi/recipes-kernel/linux/linux-raspberrypi/defconfig
>> > | prefix
>> >
>> > /local/poky-cutting-edge/meta-raspberrypi/recipes-kernel/linux/linux-raspberrypi-4.4/
>> > | patch
>> >
>> > "/local/poky-cutting-edge/meta-raspberrypi/recipes-kernel/linux/linux-raspberrypi-4.4/0001-fix-dtbo-rules.patch"
>> > | # run time: 1 seconds
>> > | # processed files:
>> > | #

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

2016-12-07 Thread Andrea Galbusera 
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,
> >>>
> >>>
> >>> On Sat, Dec 3, 2016 at 2:16 PM, Paul Barker 
> wrote:
> 
>  On Sat, 3 Dec 2016 08:33:40 +0100
>  Gary Thomas  wrote:
> 
> > I'm currently unable to build for the RaspberryPi-3 using the master
> > branch:
> >
> > Build Configuration:
> > BB_VERSION= "1.32.0"
> > BUILD_SYS = "x86_64-linux"
> > NATIVELSBSTRING   = "universal"
> > TARGET_SYS= "arm-amltd-linux-gnueabi"
> > MACHINE   = "raspberrypi3"
> > DISTRO= "amltd"
> > DISTRO_VERSION= "2.2+snapshot-20161202"
> > TUNE_FEATURES = "arm armv7ve vfp thumb neon vfpv4
> > callconvention-hard cortexa7"
> > TARGET_FPU= "hard"
> > meta  = "master:9e63f81c78e284c9b325fe04a1b59e
> 61c7ad8a1a"
> > meta-amltd= "master:074120ab3a82cea0ac50d4e9eec891
> 30a860a4fa"
> > meta-raspberrypi  = "master:44d41bf3e94c4c8fe5ad5a3650572c
> 8d17ef36c9"
> >
> > Initialising tasks: 100%
> > |#|
> Time:
> > 0:00:00
> > Checking sstate mirror object availability: 100%
> > |#| Time: 0:00:00
> > NOTE: Executing SetScene Tasks
> > NOTE: Executing RunQueue Tasks
> > ERROR: linux-raspberrypi-1_4.4.28+gitAUTOINC+5afda48c34-r0
> > do_kernel_metadata: Function failed: do_kernel_metadata (log
> > file is located at
> >
> > /build/rpi3_2016-09-13/tmp/work/raspberrypi3-amltd-linux-
> gnueabi/linux-raspberrypi/1_4.4.28+gitAUTOINC+5afda48c34-r0/
> temp/log.do_kernel_metadata.5647)
> > ERROR: Logfile of failure stored in:
> >
> > /build/rpi3_2016-09-13/tmp/work/raspberrypi3-amltd-linux-
> gnueabi/linux-raspberrypi/1_4.4.28+gitAUTOINC+5afda48c34-r0/
> temp/log.do_kernel_metadata.5647
> > Log data follows:
> > | DEBUG: Executing shell function do_kernel_metadata
> > | [ERROR]: processing of file /tmp/tmp.bXPr8PVPz3 failed
> > |
> > /build/rpi3_2016-09-13/tmp/sysroots/x86_64-linux/usr/bin/
> scc-cmds/patch.cmd:
> > line 29: : No such file or directory
> > |
> > | Context around the error is:
> > |
> > | #
> > | prefix
> > /local/poky-cutting-edge/meta-raspberrypi/recipes-kernel/
> linux/linux-raspberrypi/
> > | kconf non-hardware
> > /local/poky-cutting-edge/meta-raspberrypi/recipes-kernel/
> linux/linux-raspberrypi/defconfig
> > | prefix
> > /local/poky-cutting-edge/meta-raspberrypi/recipes-kernel/
> linux/linux-raspberrypi-4.4/
> > | patch
> > "/local/poky-cutting-edge/meta-raspberrypi/recipes-
> kernel/linux/linux-raspberrypi-4.4/0001-fix-dtbo-rules.patch"
> > | # run time: 0 seconds
> > | # processed files:
> > | # _cfg
> > /local/poky-cutting-edge/meta-raspberrypi/recipes-kernel/
> linux/linux-raspberrypi/defconfig
> > | # _cfg
> > /local/poky-cutting-edge/meta-raspberrypi/recipes-kernel/
> linux/linux-raspberrypi-4.4/0001-fix-dtbo-rules.patch
> > |
> > | See pre-processed file /tmp/tmp.bXPr8PVPz3 for more details
> > | #
> > | # scc v0.8
> > | # processed: Fri Dec  2 04:12:25 CET 2016
> > | #
> > | # This is a scc output file, do not edit
> > | #
> > | [ERROR]: processing of file /tmp/tmp.eTLAT789Q2 failed
> > | # _reloc_dir
> > /local/poky-cutting-edge/meta-raspberrypi/recipes-kernel/linux
> > | # _reloc_dir
> > /local/poky-cutting-edge/meta-raspberrypi/recipes-kernel/linux
> > |
> > /build/rpi3_2016-09-13/tmp/sysroots/x86_64-linux/usr/bin/
> scc-cmds/patch.cmd:
> > line 29: : No such file or directory
> > |
> > | Context around the error is:
> > |
> > | #
> > | prefix
> > /local/poky-cutting-edge/meta-raspberrypi/recipes-kernel/
> linux/linux-raspberrypi/
> > | kconf non-hardware
> > /local/poky-cutting-edge/meta-raspberrypi/recipes-kernel/
> linux/linux-raspberrypi/defconfig
> > | prefix
> > /local/poky-cutting-edge/meta-raspberrypi/recipes-kernel/
> linux/linux-raspberrypi-4.4/
> > | patch
> > "/local/poky-cutting-edge/meta-raspberrypi/recipes-
> kernel/linux/linux-raspberrypi-4.4/0001-fix-dtbo-rules.patch"
> > | # run time: 1 seconds
> > | # processed files:
> > | # _cfg
> > /local/poky-cutting-edge/meta-raspberrypi/recipes-kernel/
> linux/linux-raspberrypi/defconfig
> > | # _cfg
> > /local/poky-cutting-edge/meta-raspberrypi/recipes-kernel/
> linux/linux-raspberrypi-4.4/0001-fix-dtbo-rules.patch
> > |
> > | See pre-processed

Re: [yocto] cve-checker tool

2016-12-07 Thread Mariano Lopez 


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 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
cve-check class will look for BPN, so it won't check against libcurl.
Can you open a bug for this?

> [snip]


> It seems that this tool does not detect all CVEs, e.g. bind has some CVE 
> patches but it is not reported, I tried all options below nothing is reported 
> (no cve.log file):
> bitbake -c cve_check bind
> bitbake -k -c cve_check universe
> bitbake -k -c cve_check world
>
> There are some CVEs in bind (reported in nvd.xml file for our version 
> cpe:/a:isc:bind:9.10.3"/> ) but cve.check-tool does not report them ex: 
> (CVE-2016-2776). Do you know why?
>
>
> CVEs are reported for the following packages using e.g. "bitbake -k -c 
> cve_check universe"
> or  "bitbake -c cve_check perl"
>  
> tmp/work/i586-poky-linux/perl/5.22.1-r0/cve/cve.log
> tmp/work/i586-poky-linux/foomatic-filters/4.0.17-r1/cve/cve.log
> tmp/work/i586-poky-linux/flex/2.6.0-r0/cve/cve.log
> tmp/work/i586-poky-linux/glibc/2.24-r0/cve/cve.log
> tmp/work/i586-poky-linux/unzip/1_6.0-r5/cve/cve.log
> tmp/work/i586-poky-linux/expat/2.2.0-r0/cve/cve.log
> tmp/work/i586-poky-linux/gnutls/3.5.3-r0/cve/cve.log
> tmp/work/i586-poky-linux/glibc-initial/2.24-r0/cve/cve.log
> tmp/work/i586-poky-linux/libxml2/2.9.4-r0/cve/cve.log
> tmp/work/i586-poky-linux/bzip2/1.0.6-r5/cve/cve.log
>
> 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 they are public 
> (e.g. Busybox: 
> https://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-2147).

cve-check-tool will only check against the database that got from the
nvd.xml files, and these files won't have information for not yet fully
disclosed CVEs, so that is why you will find these cases frequently in
OE recipes (Armin does a great job with CVEs).

>
> I don't understand why for instance bind CVEs are not detected and reported 
> by cve-check tool?
> Is it because of cpe:/a:isc:bind? It looks for isc?

I need to check on this, unfortunately my proxies decided to not
download the database, I'll get back to you as soon as I can investigate
more.

>
> morty/poky/meta$ find . -name *CVE-201*.patch 
> ./recipes-connectivity/ppp/ppp/fix-CVE-2015-3310.patch
>
> ./recipes-connectivity/bind/bind/CVE-2016-2776.patch ?
> ./recipes-connectivity/bind/bind/CVE-2016-1286_2.patch
> ./recipes-connectivity/bind/bind/CVE-2016-1285.patch
> ./recipes-connectivity/bind/bind/CVE-2016-1286_1.patch
> ./recipes-connectivity/bind/bind/CVE-2016-2088.patch
> ./recipes-connectivity/bind/bind/CVE-2016-2775.patch
>
> ./recipes-extended/unzip/unzip/CVE-2015-7696.patch
> ./recipes-extended/unzip/unzip/06-unzip60-alt-iconv-utf8_CVE-2015-1315.patch
> ./recipes-extended/unzip/unzip/CVE-2015-7697.patch
> ./recipes-extended/xinetd/xinetd/xinetd-CVE-2013-4342.patch
> ./recipes-extended/cpio/cpio-2.12/0001-Fix-CVE-2015-1197.patch
> ./recipes-extended/cracklib/cracklib/0001-Apply-patch-to-fix-CVE-2016-6318.patch
> ./recipes-extended/bzip2/bzip2-1.0.6/CVE-2016-3189.patch
> ./recipes-extended/grep/grep-2.5.1a/grep-CVE-2012-5667.patch
> ./recipes-extended/foomatic/foomatic-filters-4.0.17/CVE-2015-8327.patch
> ./recipes-extended/foomatic/foomatic-filters-4.0.17/CVE-2015-8560.patch
> ./recipes-multimedia/libtiff/files/CVE-2016-3945.patch
> ./recipes-multimedia/libtiff/files/CVE-2016-3623.patch
> ./recipes-multimedia/libtiff/files/CVE-2016-5323.patch
> ./recipes-multimedia/libtiff/files/CVE-2016-5321.patch
> ./recipes-multimedia/libtiff/files/CVE-2016-3991.patch
> ./recipes-multimedia/libtiff/files/CVE-2016-3622.patch
> ./recipes-multimedia/libtiff/files/CVE-2015-8781.patch
> ./recipes-multimedia/libtiff/files/CVE-2015-8784.patch
> ./recipes-multimedia/libtiff/files/CVE-2016-3186.patch
> ./recipes-multimedia/libtiff/files/CVE-2016-3990.patch
> ./recipes-multimedia/libtiff/files/CVE-2015-8665_8683.patch
> ./recipes-core/systemd/systemd/CVE-2016-7795.patch
> ./recipes-core/busybox/busybox/CVE-2016-2147_2.patch  <<< Reserved on Mitre: 
> https://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-2147
> ./recipes-core/busybox/busybox/CVE-2016-2147.patch
> ./recipes-core/busybox/busybox/CVE-2016-2148.patch <<< 
> https://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-2148
> ./recipes-devtools/elfutils/elfutils-0.148/elf_begin.c-CVE-2014-9447-fix.patch
> ./recipes-devtools/python/python3/CVE-2016-5636.patch
> ./recipes-devtools/python/python3/python3-fix-CVE-2016-1000110.patch
> ./recipes-devtools/python/python/CVE-2016-5636.patch
>

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

2016-12-07 Thread Burton, Ross 
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
https://lists.yoctoproject.org/listinfo/yocto

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

2016-12-07 Thread Beth 'pidge' Flanagan 
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
> > 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 people won't have access to.
> > 
> > I want to be able to just ignore any fetch/unpack errors if that
> > extra
> > src is unfetchable. Thoughts on how to achieve this?
> > 
> One solution would be to have a global variable I_AM_SPECIAL which
> the recipes can use:
> 
> SRC_URI = "http://public.com/tarball.tar.gz
> ${@oe.types.boolean(d.getVar("I_AM_SPECIAL")) and
> 'http://private.com/tarball.tar.gz'}"
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)
fetcher.download()
except:
pass
But this doesn't seem to be catching the fetch error.
-b
> > That might work, and also add determinism.
> > Ross
> 
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

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

2016-12-07 Thread Jussi Kukkonen 
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 +-
 3 files changed, 5 insertions(+), 10 deletions(-)

diff --git a/src/ewmh.c b/src/ewmh.c
index 17ea48a..afcabe7 100644
--- a/src/ewmh.c
+++ b/src/ewmh.c
@@ -1257,8 +1257,9 @@ int
 ewmh_utf8_len(unsigned char *str) /* Only parse _validated_ utf8 */
 {
   unsigned char *p = str;
+  int len, result = 0;
+  __attribute__((unused)) int mask;
 
-  int mask, len, result = 0;
   while (*p != '\0')
 {
   UTF8_COMPUTE(*p, mask, len);
@@ -1273,8 +1274,9 @@ int
 ewmh_utf8_get_byte_cnt(unsigned char *str, int num_chars)
 {
   unsigned char *p = str;
+  int len, result = 0;
+  __attribute__((unused)) int mask;
 
-  int mask, len, result = 0;
   while (*p != '\0' && num_chars-- > 0)
 {
   UTF8_COMPUTE(*p, mask, len);
diff --git a/src/mbtheme.c b/src/mbtheme.c
index 42459a0..821195a 100644
--- a/src/mbtheme.c
+++ b/src/mbtheme.c
@@ -602,7 +602,6 @@ theme_frame_paint( MBTheme *theme,
   MBThemeFrame *frame;
   MBPixbufImage*img;
   MBThemeLayer *layer_label = NULL, *layer_icon = NULL;
-  struct list_item *layer_list_item;
   int   label_rendered_width;
   int   decor_idx = 0;
   MBDrawable   *drawable = NULL;
@@ -699,8 +698,6 @@ theme_frame_paint( MBTheme *theme,
   img = theme->img_caches[frame_type];
 }
 
-  layer_list_item = frame->layers;
-
   layer_label = (MBThemeLayer*)list_find_by_id(frame->layers, LAYER_LABEL);
 
   /* Figure out text alignment + positioning */
@@ -981,7 +978,6 @@ theme_frame_menu_highlight_entry(Client *c,
   MBDrawable*drw;
   MBThemeFrame  *frame;
   MBFont*font;
-  MBColor   *color;
   Client*entry = (Client *)button->data;
   intoffset, item_h;
 
@@ -991,7 +987,6 @@ theme_frame_menu_highlight_entry(Client *c,
 return;
 
   font  = frame->font;
-  color = frame->color;
 
   if (frame->hl_color)
 {
@@ -1982,7 +1977,6 @@ parse_color_tag (MBTheme *theme,
 XMLNode *node)
 {
   MBColor *color = NULL;
-  int alpha;
   char *id = get_attr(node, "id");
   char *spec   = get_attr(node, "def");
 
@@ -1990,7 +1984,6 @@ parse_color_tag (MBTheme *theme,
 {
   fprintf(stderr, "matchbox *warning*: alpha attribute in theme.xml color 
tar is depreciated\nUse def='rrggbbaa' format instead to 
specify alpha\n"); 
 }
-  else alpha = 0xff;
 
   dbg("%s() id : %s , def : %s\n", __func__, id, spec);
 
diff --git a/src/wm.c b/src/wm.c
index cb033c6..0823fef 100644
--- a/src/wm.c
+++ b/src/wm.c
@@ -2621,7 +2621,7 @@ wm_activate_client(Client *c)
   /* As matchbox works around 'main' windows ( apps/main and desktop wins).
 We need to sync extra stuff up when displaying a new one.
*/
-  Bool switching_from_to_fullscreen = False;
+  __attribute__((unused)) Bool switching_from_to_fullscreen = False;
 
   /* save focus state for transient dialogs of prev showing main win */
 
-- 
2.11.0

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

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

2016-12-07 Thread Jussi Kukkonen 
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
--- a/src/matchbox-remote.c
+++ b/src/matchbox-remote.c
@@ -143,11 +143,13 @@ mbcommand(int cmd_id, char *data) {
/* Check if desktop is running */
if (!XGetSelectionOwner(dpy, desktop_manager_atom))
 {
+  char *exec_args[] = { NULL };
+
   fprintf(stderr, "Desktop not running, exiting...\n");
   switch (fork())
 {
 case 0:
-  execvp ("mbdesktop", NULL);
+  execvp ("mbdesktop", exec_args);
   break;
 case -1:
   fprintf(stderr, "failed to exec mbdesktop");
-- 
2.11.0

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

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

2016-12-07 Thread Jussi Kukkonen 
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 b/src/ewmh.c
index a736037..17ea48a 100644
--- a/src/ewmh.c
+++ b/src/ewmh.c
@@ -137,7 +137,8 @@ void
 ewmh_init_props(Wm *w)
 {
   long num_desktops = 1;
-  
+  long current_desktop = 0;
+
   set_compliant(w);
   set_supported(w);
   
@@ -147,7 +148,7 @@ ewmh_init_props(Wm *w)
   
   XChangeProperty(w->dpy, w->root, w->atoms[_NET_CURRENT_DESKTOP],
  XA_CARDINAL, 32, PropModeReplace,
- (unsigned char *)_desktops, 0);
+ (unsigned char *)_desktop, 1);
 }
 
 int
-- 
2.11.0

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

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

2016-12-07 Thread Jussi Kukkonen 
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:

  git://github.com/jku/matchbox-window-manager net-current-desktop
  https://github.com/jku/matchbox-window-manager/tree/net-current-desktop

Jussi Kukkonen (3):
  ewmh: Actually set _NET_CURRENT_DESKTOP
  matchbox-remote: Fix execvp() argument
  Fix "unused variable" warnings

 src/ewmh.c| 11 +++
 src/matchbox-remote.c |  4 +++-
 src/mbtheme.c |  7 ---
 src/wm.c  |  2 +-
 4 files changed, 11 insertions(+), 13 deletions(-)

-- 
2.11.0

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

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

2016-12-07 Thread Burton, Ross 
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 have a SRC_URI
> for the main bit that everyone has access to, but an extra src_uri that
> some people won't have access to.
>
> I want to be able to just ignore any fetch/unpack errors if that extra
> src is unfetchable. Thoughts on how to achieve this?
>

One solution would be to have a global variable I_AM_SPECIAL which the
recipes can use:

SRC_URI = "http://public.com/tarball.tar.gz
${@oe.types.boolean(d.getVar("I_AM_SPECIAL")) and '
http://private.com/tarball.tar.gz'}"

That might work, and also add determinism.

Ross
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

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

2016-12-07 Thread Burton, Ross 
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 scripts that generate the relevant output, and
provide that output in the recipe.  So if  you were building for ARM you'd
build once on arm, determine what the results of the tests are, and then
put those values in the recipe.

Ross
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Ignoring Fetch errors for optional source.

2016-12-07 Thread Beth 'pidge' Flanagan 
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 people won't have access to.

I want to be able to just ignore any fetch/unpack errors if that extra
src is unfetchable. Thoughts on how to achieve this?

-b

-- 
Beth 'pidge' Flanagan 
www.toganlabs.com

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

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

2016-12-07 Thread david bensoussan 
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 letting me cross compile projects depending on it
successfully.

Did you ever need those libraries, if so, did you find any other way to
integrate them in Yocto?

Thanks
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

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

2016-12-07 Thread Andreas Müller 
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 wrote:
>> > > Upstream effectively support one version, currently 4.4. When upstream
>> > > made that the default branch, the changes to the 4.1 branch stopped -
>> > > there wasn't really much overlap. Everything post-4.4 is active
>> > > development and gets rebased at will. At some point they'll move to the
>> > > next LTS release (4.9) and 4.4 will be dropped.
>> >
>> > Are you speaking specifically about the kernel for raspberry pi, or in
>> > general?
>>
>> Raspberrypi specifically.
>>
>> > Because the kernel for raspberry pi has several branches that are all
>> > maintained and kept up-to-date. It's actually quite commendable how this
>> > repository is maintained. Branches for 4.4, 4.7, 4.8, 4.9 and others are 
>> > all
>> > usable (ignoring the constant rebasing thing...)
>>
>> 4.4 is stable and never gets rebased.
>>
FWIW: patch fixing 4.4 just arrived in oe-core

Andreas
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] yocto project in raspberry pi 3

2016-12-07 Thread Gary Thomas 

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 have switched to tarball fetch
especially

http://git.yoctoproject.org/cgit/cgit.cgi/meta-raspberrypi/commit/?id=716b6a9cd7f24a8bacd539bb40519d185e3f963a

i am getting message like




ERROR: Fetcher failure: Fetch command failed with exit code 128, output:
Cloning into bare repository 
'/home/rushin/yoctopi/poky/build/downloads/git2/github.com.raspberrypi.firmware.git'...
fatal: The remote end hung up unexpectedly
fatal: early EOF
fatal: index-pack failed

ERROR: Function failed: Fetcher failure for URL:
'git://github.com/raspberrypi/firmware.git;protocol=git;branch=master'. 
Unable to fetch URL from any source.
ERROR: Logfile of failure stored in:

/home/rushin/yoctopi/poky/build/tmp/work/raspberrypi2-poky-linux-gnueabi/bcm2835-bootfiles/20151021-r3/temp/log.do_fetch.3385
ERROR: Task 207 
(/home/rushin/yoctopi/poky/meta-raspberrypi/recipes-bsp/bootfiles/bcm2835-bootfiles.bb,
 do_fetch)
failed with exit code '1'

can you tell me how to download this file manually??


Doing it manually will take just as long and end up downloading 6GB+ of [mostly 
useless] data.

You really need to update to the latest version of this recipe which no longer
uses GIT to fetch the files (replaced by much smaller TAR files)



like in download folder there is file called
wpa_supplicant-2.4.tar.gz . i can download this file. but how to get these 
files like
wpa_supplicant-2.4.tar.gz.done,wpa_supplicant.sh.done??











--

Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] yocto project in raspberry pi 3

2016-12-07 Thread Rushin Thakkar 



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 

http://git.yoctoproject.org/cgit/cgit.cgi/meta-raspberrypi/commit/?id=716b6a9cd7f24a8bacd539bb40519d185e3f963a
 




i am getting message like 




ERROR: Fetcher failure: Fetch command failed with exit code 128, output: 
Cloning into bare repository 
'/home/rushin/yoctopi/poky/build/downloads/git2/github.com.raspberrypi.firmware.git'...
 
fatal: The remote end hung up unexpectedly 
fatal: early EOF 
fatal: index-pack failed 

ERROR: Function failed: Fetcher failure for URL: ' 
git://github.com/raspberrypi/firmware.git;protocol=git;branch=master '. Unable 
to fetch URL from any source. 
ERROR: Logfile of failure stored in: 
/home/rushin/yoctopi/poky/build/tmp/work/raspberrypi2-poky-linux-gnueabi/bcm2835-bootfiles/20151021-r3/temp/log.do_fetch.3385
 
ERROR: Task 207 
(/home/rushin/yoctopi/poky/meta-raspberrypi/recipes-bsp/bootfiles/bcm2835-bootfiles.bb,
 do_fetch) failed with exit code '1' 

can you tell me how to download this file manually?? 

like in download folder there is file called 
wpa_supplicant-2.4.tar.gz . i can download this file. but how to get these 
files like wpa_supplicant-2.4.tar.gz.done,wpa_supplicant.sh.done?? 









-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

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

2016-12-07 Thread Gary Thomas 

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
putting it in local.conf forced every package that uses PACKAGECONFIG to
be rebuilt :-(

Perhaps a softer approach might be:
  PACKAGECONFIG_remove_pn-gstreamer1.0-plugins-bad = "dispmax"

Too bad though that this needs to be disabled to get X11 to work as it would
seem to be very useful in a high-need graphic environment.



I've never built for "vc-graphics-hardfp", as I'm not sure if there are
benefits in using it over either using the userland or vc4, so I'm not sure
whether it can work without dispmanx, nor why it would not compile with
dispmanx enabled.
But if this works, then we might need to consider to add an additional case
for not enabling dispmanx.

Cheers,
Herve

-Original Message-
From: Gary Thomas [mailto:g...@mlbassoc.com]
Sent: mardi 6 décembre 2016 16:58
To: Andrei Gherzan 
Cc: Herve Jourdain ; yocto@yoctoproject.org
Subject: ***SPAM*** Re: [yocto] [meta-raspberrypi][PATCH]
gstreamer1.0-plugins-bad: Don't hard wire use of userland

On 2016-12-06 16:48, Andrei Gherzan wrote:

On Tue, Dec 06, 2016 at 04:02:20PM +0100, Gary Thomas wrote:

On 2016-12-06 13:45, Herve Jourdain wrote:

Hi Gary,

But dispmanx is really only provided by userland, it does not exist
in other flavors of egl/libgles.
Actually, dispmanx should not be selected in PACKAGECONFIG if
userland is not in use for EGL/GLES.


Fine, but I'm looking for a solution where I can choose to use
vc-graphics-hardfp so X11 works again and I can also have gst-player
which depends on gstreamer-1.0-bad

Any ideas?



Disabling dispamanx is not working?


How might I do that?  It's not clear from [at least] that recipe.


--

Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

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

2016-12-07 Thread Paul Barker 
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
> > > made that the default branch, the changes to the 4.1 branch stopped -
> > > there wasn't really much overlap. Everything post-4.4 is active
> > > development and gets rebased at will. At some point they'll move to the
> > > next LTS release (4.9) and 4.4 will be dropped.
> > 
> > Are you speaking specifically about the kernel for raspberry pi, or in
> > general?
> 
> Raspberrypi specifically.
> 
> > Because the kernel for raspberry pi has several branches that are all
> > maintained and kept up-to-date. It's actually quite commendable how this
> > repository is maintained. Branches for 4.4, 4.7, 4.8, 4.9 and others are all
> > usable (ignoring the constant rebasing thing...)
> 
> 4.4 is stable and never gets rebased.
> 
> 4.7 was last updated Oct 25th so it's now inactive.
> 
> 4.8 and 4.9 will be almost the same set of patches rebased on top of
> the mainline kernel. I think they do things this way to make
> upstreaming patches easier.
> 
> This is the pattern I've seen for the last couple of years - one stable
> branch that never gets rebased and one or two development branches
> which do get rebased.
> 

Sorry, quick follow up.

https://github.com/raspberrypi/linux/issues/1650 is a typical response from
the Raspberrypi folks about this:

Future rpi- branches (branches that aren't yet the main development
branch, currently rpi-4.4.y) are rebased against upstream commits.
Once we start making releases from a branch we stop rebasing and
start merging.

The commit you refer to still exists but with a different commit
ID. You need to tell whoever gave you the hash that bookmarking
commits in our future branches is futile because they are regularly
rebased.

Thanks,
Paul
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

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

2016-12-07 Thread Andreas Müller 
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 11:07 AM, Trevor Woerner  
>> > > > wrote:
>> > > >
>> > > > If the PREEMPT_RT patch is applied, the kernel version becomes, say,
>> > > > 4.4.32-rt43 (instead of 4.4.32). This confuses the version handling 
>> > > > code in
>> > > > this class. Update how the version string is processed so that 
>> > > > trailing rt-
>> > > > strings are properly handled, in addition to handling the existing 
>> > > > cases.
>> > > >
>> > >
>> > > This probably will solve the issue I see with 4.9-rcX recipes that are 
>> > > in my tree on kraj/master
>> >
>> > I'm not familiar with the issue you're seeing, but the existing and new 
>> > code
>> > are looking for 3 int()s separated by periods. If your recipes have the 
>> > string
>> > "4.9-rcX" then I'm guessing there might still be an issue since the third
>> > int() will be "-rcX" in your case. If this is true, you'll need to take a 
>> > look
>> > at where "int(min_ver[2])" is used further down in that bbclass file.
>>
>> I agreed this is not the best implementation of this. We should only get
>
> agree*
>
>> the version using a regex that would get X.Y.Z-R with an optional Z and
>> R.
>>
>> --
>> Andrei Gherzan
> --
> Andrei Gherzan
>
Question is if this version dance in get_dts is still necessary: We
don't have kernel < 3.18 or kernel 4.4.<6 around. Why not use what is
set in KERNEL_DEVICETREE?

Andreas
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto