On 6/14/18 8:22 PM, Randy Li wrote:
> There are some addtional instructions apart from bare armv8,
> also there is armv8.1, armv8.2.
>
> Most the processor would support crc, except X-gene 1.
I have a concern with this approach, since its mirroring the prior arm
art, I think for v8 it would be
On 06/26/2018 03:54 PM, Andre McCurdy wrote:
> On Tue, Jun 26, 2018 at 3:33 PM, akuster808 wrote:
>> On 06/18/2018 12:20 PM, Daniel Díaz wrote:
>>> On 11 June 2018 at 16:46, Andre McCurdy wrote:
On Mon, Jun 11, 2018 at 2:38 PM, akuster808 wrote:
> On 06/11/2018 10:30 AM, Daniel Díaz
On 06/25/2018 12:48 PM, Andre McCurdy wrote:
> On Thu, May 17, 2018 at 3:19 PM, Andre McCurdy wrote:
>> An elevation of privilege vulnerability in libnl could enable a local
>> malicious application to execute arbitrary code within the context of
>> the Wi-Fi service. This issue is rated as
On Tue, Jun 26, 2018 at 3:33 PM, akuster808 wrote:
> On 06/18/2018 12:20 PM, Daniel Díaz wrote:
>> On 11 June 2018 at 16:46, Andre McCurdy wrote:
>>> On Mon, Jun 11, 2018 at 2:38 PM, akuster808 wrote:
On 06/11/2018 10:30 AM, Daniel Díaz wrote:
> Ping on this series for Morty.
this
Signed-off-by: Alejandro Enedino Hernandez Samaniego
---
meta/conf/distro/include/maintainers.inc | 2 ++
1 file changed, 2 insertions(+)
diff --git a/meta/conf/distro/include/maintainers.inc
b/meta/conf/distro/include/maintainers.inc
index 7547aef..1d3e059 100644
---
On 06/18/2018 12:20 PM, Daniel Díaz wrote:
> Hello!
>
>
> On 11 June 2018 at 16:46, Andre McCurdy wrote:
>> On Mon, Jun 11, 2018 at 2:38 PM, akuster808 wrote:
>>> On 06/11/2018 10:30 AM, Daniel Díaz wrote:
Ping on this series for Morty.
>>> this is in the stable/morty-next branch which is
Actually, it is a screw-up trying to deal with something that was already
fixed. At least it never gets executed.
Joe
From: Alexander Kanavin [alex.kana...@gmail.com]
Sent: Tuesday, June 26, 2018 12:19 PM
To: Slater, Joseph
Cc: OE-core
Subject: Re:
Although the ARM SWP instruction may exist for ARMv6 and above, it's
not guaranteed to work, especially on SMP systems where it's use may
lead to instability at runtime, etc:
https://community.arm.com/processors/b/blog/posts/locks-swps-and-two-smoking-barriers
Keeping the optimisation for
On Mon, Jun 4, 2018 at 2:33 PM, Andre McCurdy wrote:
> On Tue, May 22, 2018 at 3:33 AM, Khem Raj wrote:
>> On Tue, May 22, 2018 at 5:58 AM, wrote:
>>> Andre McCurdy wrote:
Although there may still be specific cases which can benefit from the
ARM instruction set, the Thumb2
Move packaging rules for cmake -dev files from cmake.bbclass into
bitbake.conf to handle recipes (e.g. harfbuzz 1.8.1) which build with
autotools but also install cmake -dev files.
Signed-off-by: Andre McCurdy
---
meta/classes/cmake.bbclass | 2 --
meta/conf/bitbake.conf | 4 ++--
2 files
The bug refers to a gstreamer bug with patches, which you should probably apply:
https://bugzilla.gnome.org/show_bug.cgi?id=784779
Alex
2018-06-26 20:55 GMT+02:00 Michael Gloff :
> I'm seeing the below errors when trying to build webkitgtk. I am using base
> poky distro on sumo branch without
2018-06-26 20:51 GMT+02:00 Joe Slater :
> -bindir=${bindir}
> +bindir=${bindir} || \
> +$INTERCEPT_DIR/postinst_intercept delay_to_first_boot ${PKG} \
> +mlprefix=${MLPREFIX}
Please read the postinst_intercept script. It does not actually
execute qemu at
Thanks, this seems to be fixing the issue I've reported long time ago:
http://lists.openembedded.org/pipermail/openembedded-commits/2018-March/220579.html
On Tue, Jun 26, 2018 at 2:10 PM Alex Kiernan wrote:
> If SOURCE_DATE_EPOCH is unset (in addition to the existing "0" behaviour)
> parse
I'm seeing the below errors when trying to build webkitgtk. I am using base
poky distro on sumo branch without any extra layers with qemuarm machine.
It looks similar to:
https://bugs.webkit.org/show_bug.cgi?id=175127
which reports that this was fixed upstream, but obviously not in 2.18.6.
Does
We might not be able to execute target code using qemu, so
defer to first boot in that case.
Signed-off-by: Joe Slater
---
meta/classes/gtk-immodules-cache.bbclass | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/meta/classes/gtk-immodules-cache.bbclass
On 26 June 2018 at 02:52, Jon Szymaniak wrote:
> What do you think about instead patching the configure script to just
> set the default to capstone=internal?
I'm just glancing at the configure and don't have time right now to
test, but wouldn't --enable-capstone=git --disable-git-update do the
The Yocto documentation has general information:
https://www.yoctoproject.org/docs/latest/dev-manual/dev-manual.html#testing-packages-with-ptest
Alex
2018-06-26 14:57 GMT+02:00 nick83ola :
> Hi all,
>
> I have a python3 package that launch a py.test test suite from
> setup.py and I have
On 06/26/2018 12:35 AM, Hong Liu wrote:
> 1.0001-top-Do-not-default-to-the-cwd-in-configs_read.patch fixed CVE-2018-1122
>
> 2.0001-ps-output.c-Fix-outbuf-overflows-in-pr_args-etc.patch fixed
> CVE-2018-1123
> ---
> ...put.c-Fix-outbuf-overflows-in-pr_args-etc.patch | 84 +
>
On 06/26/2018 04:27 AM, Burton, Ross wrote:
> It appears that these are fixed in 3.3.15, so let's just upgrade to
> that and get all the other security fixes too.
But I can take this for Sumo if I don't update too.
- armin
> Ross
>
> On 26 June 2018 at 08:35, Hong Liu wrote:
>>
Hi all,
I have a python3 package that launch a py.test test suite from
setup.py and I have created a recipe for it using setuptools3
Anyone has some hint about how to add a ptest target to run the tests
into the final image (or better in a qemu test image)?
there are some recipe/documentation
I'm migrating to "sumo" from rocko, and when building for multiple machines on
the build server, I get failures like the one below.
I'm suspecting this is a resurrection of the MACHINE/allarch problems that
i've seen in the past, but this time I cannot work around them since they
concern
If SOURCE_DATE_EPOCH is unset (in addition to the existing "0" behaviour)
parse out the top most commit timestamp from the kernel tree to use as the
timestamp.
Signed-off-by: Alex Kiernan
---
meta/classes/kernel.bbclass | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
When REPRODUCIBLE_TIMESTAMP_ROOTFS is unset and we want to parse one
from git, use COREBASE as the base for the git command so we have a
known repository which we're using. Without this the build may fail
if the current directory is not part of a git repository.
Signed-off-by: Alex Kiernan
---
Signed-off-by: Ross Burton
---
meta/conf/distro/include/maintainers.inc | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/meta/conf/distro/include/maintainers.inc
b/meta/conf/distro/include/maintainers.inc
index d569e0a7ec3..7dd5e658225 100644
---
It appears that these are fixed in 3.3.15, so let's just upgrade to
that and get all the other security fixes too.
Ross
On 26 June 2018 at 08:35, Hong Liu wrote:
> 1.0001-top-Do-not-default-to-the-cwd-in-configs_read.patch fixed CVE-2018-1122
>
>
I believe the culprit is likely this patch:
http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/recipes-devtools/rpm/files/0001-When-cross-installing-execute-package-scriptlets-wit.patch
As scriptlets are executed outside of rpm's chroot, they are being
written into system's /var/tmp, not
1.0001-top-Do-not-default-to-the-cwd-in-configs_read.patch fixed CVE-2018-1122
2.0001-ps-output.c-Fix-outbuf-overflows-in-pr_args-etc.patch fixed CVE-2018-1123
---
...put.c-Fix-outbuf-overflows-in-pr_args-etc.patch | 84 +
...Do-not-default-to-the-cwd-in-configs_read.patch | 101
glibc: fix CVE-2018-11237
Signed-off-by: Zheng Ruoqin
---
meta/recipes-core/glibc/glibc/CVE-2018-11237.patch | 83 ++
meta/recipes-core/glibc/glibc_2.27.bb | 1 +
2 files changed, 84 insertions(+)
create mode 100644
28 matches
Mail list logo
