Hi Kai,
I played around with the new meta-security-isafw layer and
the cve-check-tool. In readline the cve CVE-2014-2524 is marked as
'missing' by the framework and I was confused to start with, since I saw
that this commit was included. But after looking at the actual patch I
realized that it
On 6 October 2015 at 09:11, Petter Mabäcker wrote:
> I played around with the new meta-security-isafw layer and the
> cve-check-tool. In readline the cve CVE-2014-2524 is marked as 'missing' by
> the framework and I was confused to start with, since I saw that this
> commit was included. But afte
Petter Mabäcker
Technux
www.technux.se
2015-10-06 12:06 skrev Burton, Ross:
> On 6 October 2015 at 09:11, Petter Mabäcker
wrote:
>
>> I played around with the new meta-security-isafw layer and
the cve-check-tool. In readline the cve CVE-2014-2524 is marked as
'missing' by the framework an
Hello,
I'm looking into the possibility of adding gobject introspection support
directly to oe-core for Yocto 2.1 release (Spring 2016). This work would
of course be based on meta-gir, but with the mandatory goal of producing
patches of sufficient quality that can be sent upstream.
I know th
On 05-10-15 15:22, Richard Purdie wrote:
On Mon, 2015-10-05 at 13:49 +0200, Mike Looijmans wrote:
On 05-10-15 12:18, Richard Purdie wrote:
On Mon, 2015-10-05 at 11:34 +0200, Mike Looijmans wrote:
...
For the bigger picture:
If I have a recipe that says:
X = "x"
And I refactor it a bit to
On 6 October 2015 at 12:23, Petter Mabäcker wrote:
> The patch must be applied by something/someone.. For example Debian
> solves it by doing their own .diff patch (
> http://http.debian.net/debian/pool/main/r/readline6/readline6_6.3-8.debian.tar.xz).
> I can send a suggestion about how to solve
This file wasn't named as a patch, nor told to apply explicity, so it was just
unpacked to the work directory and not applied. Rename the file so the patch is
applied correctly.
(thanks to Petter Mabäcker for spotting this)
Signed-off-by: Ross Burton
---
.../readline/readline-6.3/{readline63-
The error patch in rpm-check-rootpath-reasonableness.patch did a bare return
from a function that should be returning an int. As this is the error path,
return -1 instead.
Signed-off-by: Ross Burton
---
meta/recipes-devtools/rpm/rpm/rpm-check-rootpath-reasonableness.patch | 2 +-
1 file changed
* it was added only to hf cortexa7 in:
commit e97d152ca13556b41a236c1a4cfb11e77ff857d7
Author: Kristof Robot
Date: Sun Jan 26 10:03:56 2014 +0100
Add Cortex A7 support for NEONv2 & FPv4
* add it to softfp cortexa7 and both versions for cortexa15 and
cortexa17 tunes
* we should al
* it was added only to hf cortexa7 in:
commit e97d152ca13556b41a236c1a4cfb11e77ff857d7
Author: Kristof Robot
Date: Sun Jan 26 10:03:56 2014 +0100
Add Cortex A7 support for NEONv2 & FPv4
* add it to softfp cortexa7 and both versions for cortexa15 and
cortexa17 tunes
Signed-off-by:
2015-10-06 14:58 skrev Burton, Ross:
> On 6 October 2015 at 12:23,
Petter Mabäcker wrote:
>
>> The patch must be
applied by something/someone.. For example Debian solves it by doing
their own .diff patch
(http://http.debian.net/debian/pool/main/r/readline6/readline6_6.3-8.debian.tar.xz
[1]).
On Tue, 2015-10-06 at 15:36 +0200, Martin Jansa wrote:
>
> * we should also update Cortex-A7 and Cortex-A15, to use
> -march=armv7ve,
> but the problem is that oe-core has gcc-4.[89] and gcc-5.2 and gcc
> -4.8
> doesn't support it yet,
Or you could make it use -mcpu=cortex-a15, which works f
On 6 October 2015 at 14:43, Petter Mabäcker wrote:
> Great. As you will notice also when formatted properly it will not apply
> due to that readline63-001 and readline63-002 isn't applied so
> 'patchlevel' is incorrect. That makes me wondering what the patching
> strategy is? In my opinion we sho
On Tue, Oct 06, 2015 at 02:52:21PM +0100, Phil Blundell wrote:
> On Tue, 2015-10-06 at 15:36 +0200, Martin Jansa wrote:
> >
> > * we should also update Cortex-A7 and Cortex-A15, to use
> > -march=armv7ve,
> > but the problem is that oe-core has gcc-4.[89] and gcc-5.2 and gcc
> > -4.8
> > does
Changelog since 2015-09-27 until 2015-10-04. Projects included in this report:
bitbake: git://git.openembedded.org/bitbake
openembedded-core: git://git.openembedded.org/openembedded-core
meta-openembedded: git://git.openembedded.org/meta-openembedded
meta-angstrom: git://github.com/Angstrom-distr
* The Xorg server needs to load the GLX extension in order to
enable proper OpenGL support.
* Before this patch, glxinfo aborted with:
root@qemux86:~# glxinfo
name of display: :0.0
Error: couldn't find RGB GLX visual or fbconfig
* After this patch, it works as expecte
* be aware that this -march value is available only in gcc-4.9 and
newer:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57907
Signed-off-by: Martin Jansa
---
meta/conf/machine/include/arm/arch-armv7ve.inc | 123 +
.../conf/machine/include/arm/feature-arm-thumb.inc |
* since:
commit cffda9a821a3b83a8529d643c567859e091c6846
Author: Martin Jansa
Date: Tue Sep 11 17:05:45 2012 +
arch-arm: define different ARMPKGARCH when different CCARGS are used
we don't need to worry about e.g. cortexa7 device upgrading
binary package from armv7a feed whi
On 2 October 2015 at 18:43, Andreas Oberritter wrote:
> Hello Jussi,
Hi, and thanks for the help.
> On 02.10.2015 14:41, Jussi Kukkonen wrote:
> > Automatic dependency tracking does not notice this (understandable
> > with the dlopen trickery epoxy does).
> >
> > [YOCTO #8371]
> >
> > Signed
2015-10-06 16:08 skrev Burton, Ross:
> On 6 October 2015 at 14:43,
Petter Mabäcker wrote:
>
>> Great. As you will
notice also when formatted properly it will not apply due to that
readline63-001 and readline63-002 isn't applied so 'patchlevel' is
incorrect. That makes me wondering what the p
On Tue, Oct 6, 2015 at 5:55 AM, Mike Looijmans
wrote:
> On 05-10-15 15:22, Richard Purdie wrote:
>
>> On Mon, 2015-10-05 at 13:49 +0200, Mike Looijmans wrote:
>>
>>> On 05-10-15 12:18, Richard Purdie wrote:
>>>
On Mon, 2015-10-05 at 11:34 +0200, Mike Looijmans wrote:
>>> ...
>
>> For t
On 6 October 2015 at 16:00, Carlos Alberto Lopez Perez
wrote:
> root@qemux86:~# glxinfo | grep " render"
> direct rendering: Yes
> OpenGL renderer string: Software Rasterizer
>
"Works" being a relative term for the old non-LLVM software renderer ;)
Ross
--
___
On 06/10/15 18:12, Burton, Ross wrote:
> On 6 October 2015 at 16:00, Carlos Alberto Lopez Perez
> wrote:
>
>> root@qemux86:~# glxinfo | grep " render"
>> direct rendering: Yes
>> OpenGL renderer string: Software Rasterizer
>>
>
> "Works" being a relative term for the old non-LL
On Sat, Oct 03, 2015 at 03:33:43PM +0200, Martin Jansa wrote:
> On Fri, Sep 18, 2015 at 01:54:58PM +0200, Martin Jansa wrote:
> > On Wed, Aug 26, 2015 at 03:56:04PM +0200, Martin Jansa wrote:
> > > Time for even more PNBLACKLISTs..
> >
> > And it got even worse.
>
> PNBLACKLISTs sent to ML, they
gcc packages use a shared source directory, this causes an issue since the
archiver will
try to patch the same source several times (one for each gcc package),
producing an error,
the archiver class used stamp-base to check this, nonetheless our gcc packages
no longer
use stamp-base, they use gc
As the image isn't a "core" image
[YOCTO #7664]
Signed-off-by: Alex Franco
---
meta-selftest/recipes-test/images/core-image-empty.bb | 7 ---
meta-selftest/recipes-test/images/empty-image.bb | 7 +++
2 files changed, 7 insertions(+), 7 deletions(-)
delete mode 100644 meta-selftest
As the empty image isn't a "core" image
[YOCTO #7664]
Signed-off-by: Alex Franco
---
meta-selftest/recipes-test/images/core-image-empty.bb | 7 ---
meta-selftest/recipes-test/images/empty-image.bb | 7 +++
2 files changed, 7 insertions(+), 7 deletions(-)
delete mode 100644 meta-se
27 matches
Mail list logo
