Re: [OE-core] [PATCH 0/1] mesa: Contain configure search for llvm

Why is it needed? Without this change mesa was finding llvm-config correctly, that's why I've just reverted this to continue building. On Fri, Mar 31, 2017 at 5:57 PM, Khem Raj wrote: > On Fri, Mar 31, 2017 at 8:08 AM, Martin Jansa > wrote: > > On

[OE-core] [PATCH] python: remove stale link to "Python for Embedded Systems Site"

Reference url is a stale, non existent site that returns a 404, so get rid of it Change impacts both the manifest files and the scripts that generate the manifests Run the following from within recipes-devtools/python ../../../scripts/contrib/python/generate-manifest-2.7.py >

Re: [OE-core] [PATCH] ncurses_6.0: Improve reproducibility

On Fri, Mar 31, 2017 at 3:50 PM Richard Purdie < richard.pur...@linuxfoundation.org> wrote: > On Fri, 2017-03-31 at 22:27 +, Khem Raj wrote: > > > > On Fri, Mar 31, 2017 at 2:29 PM Juro Bystricky > com> wrote: > > > Build static libraries without the binutils "ar" -U

Re: [OE-core] [PATCH] ncurses_6.0: Improve reproducibility

On Fri, Mar 31, 2017 at 3:27 PM, Khem Raj wrote: > > On Fri, Mar 31, 2017 at 2:29 PM Juro Bystricky > wrote: >> >> Build static libraries without the binutils "ar" -U option. >> This option deliberately breaks deterministic mode. > > While this patch

Re: [OE-core] [meta-clang] oe-core and meta-clang llvm coexsting?

On 03/30/2017 04:58 PM, Martin Kelly wrote: On 03/30/2017 12:31 PM, Khem Raj wrote: On 3/30/17 12:20 PM, Martin Kelly wrote: Hi, I'm trying to integrate the meta-clang version of LLVM 4.0 (used for recipes that need a newer LLVM version) alongside the oe-core version of LLVM 3.3 (used for

Re: [OE-core] [PATCH] ncurses_6.0: Improve reproducibility

On Fri, 2017-03-31 at 22:27 +, Khem Raj wrote: > > On Fri, Mar 31, 2017 at 2:29 PM Juro Bystricky com> wrote: > > Build static libraries without the binutils "ar" -U option. > > This option deliberately breaks deterministic mode. > While this patch is ok it would be

Re: [OE-core] [PATCH] ncurses_6.0: Improve reproducibility

On Fri, Mar 31, 2017 at 2:29 PM Juro Bystricky wrote: > Build static libraries without the binutils "ar" -U option. > This option deliberately breaks deterministic mode. While this patch is ok it would be better if we configured binutils with

[OE-core] [PATCH] ncurses_6.0: Improve reproducibility

Build static libraries without the binutils "ar" -U option. This option deliberately breaks deterministic mode. The option seems to be a relic from 2015, intended as a workaround for some unspecified build problems. [YOCTO#11247] Signed-off-by: Juro Bystricky ---

Re: [OE-core] [PATCH] dpkg: Add PACKAGECONFIG for liblzma and enable it

On Fri, Mar 31, 2017 at 7:09 AM, Richard Purdie wrote: > liblzma is part of xz and we already build it but configure it out. This makes > no sense. Enabling it means we gain multithreaded compression and it speeds > dpkg-deb up massively. It also removes the

[OE-core] [PATCH] binutils: Detect 64bit mips target for gold

Signed-off-by: Khem Raj --- meta/recipes-devtools/binutils/binutils-2.28.inc | 1 + .../binutils/0016-Detect-64-bit-MIPS-targets.patch | 50 ++ 2 files changed, 51 insertions(+) create mode 100644

Re: [OE-core] [PATCH morty v2] wic: partition: Run fsck on EXT file systems

On 3/31/17 5:51 AM, Daniel Schultz wrote: > Mkfs may create EXT file systems which can only be optimized by fsck > and not by itself, e.g. directory optimization (in Pass 3A). > > To prevent those optimizations during runtime, it will be performed after > the creation of an EXT file system. >

Re: [OE-core] [PATCH v2 1/2] runqemu: Automatically add a TFTP directory for slirp boot

On Fri, Mar 24, 2017 at 1:38 PM, Alistair Francis wrote: > When booting QEMU with slirp networking we want to use QEMUs TFTP server > to make the images in deploy accessible to the guest. > > Signed-off-by: Alistair Francis Ping? > ---

Re: [OE-core] [meta-clang] oe-core and meta-clang llvm coexsting?

On 03/31/2017 01:51 AM, Burton, Ross wrote: On 30 March 2017 at 20:20, Martin Kelly > wrote: I'm trying to integrate the meta-clang version of LLVM 4.0 (used for recipes that need a newer LLVM version) alongside the oe-core version of LLVM

Re: [OE-core] [PATCH 0/1] mesa: Contain configure search for llvm

On Fri, Mar 31, 2017 at 8:08 AM, Martin Jansa wrote: > On Thu, Mar 23, 2017 at 10:31:07AM -0700, Khem Raj wrote: >> On Thu, Mar 23, 2017 at 12:51 AM, Martin Jansa >> wrote: >> > I'm not sure if this is the root cause, but last qemux86 build shows:

[OE-core] [PATCH v5 2/2] automake: Adjust shebang lines to remove interpreter path hardcode

If build host perl (and other tools) is old and we use some kind of toolchain to provide recent perl/python/etc to the OE build we still locked to use build host perl due to hardcoded shebang lines in automake scripts. Behaviour was observed with Enterprise Linux 6 and devtoolset toolchain from

[OE-core] [PATCH v5 0/2] automake/autoconf: avoid path to perl interpreter hardcoding

Hi, This is updated series of changes to autoconf/automake where I address all questions from previous review session. Sorry for noise. Please review again. Thanks. Cc: XE-Linux Serhii Popovych (2): autoconf: Adjust shebang lines to remove interpreter path

[OE-core] [PATCH v5 1/2] autoconf: Adjust shebang lines to remove interpreter path hardcode

If build host perl (and other tools) is old and we use some kind of toolchain to provide recent perl/python/etc to the OE build we still locked to use build host perl due to hardcoded shebang lines in autoconf scripts. Behaviour was observed with Enterprise Linux 6 and devtoolset toolchain from

Re: [OE-core] [PATCH] glibc: Support building with 2.6.32 kernels on x86 / x86_64

> >> >>> >>> >>> On 3/28/17 11:57 AM, Serhii Popovych wrote: While glibc states that 2.6.32 kernels still supported for x86 / x86_64 builds are failing due to out of date LIBC_LINUX_VERSION macro checks for such architectures. This macro statically defined to 3.2.0 with

Re: [OE-core] [PATCH 0/1] mesa: Contain configure search for llvm

On Thu, Mar 23, 2017 at 10:31:07AM -0700, Khem Raj wrote: > On Thu, Mar 23, 2017 at 12:51 AM, Martin Jansa wrote: > > I'm not sure if this is the root cause, but last qemux86 build shows: > > > > > > | configure: error: --enable-gallium-llvm selected but llvm-config is not

Re: [OE-core] Subscribing to openembedded-architecture list

Philip, Philip Balister wrote on 2017-03-30: > You should be able to join. Did you get any messages at all? No responses at all. Neither for web interface nor for mail requests to openembedded-architecture-{request|join}. The only time I've got a response was when I tried to send the

[OE-core] [PATCH] dpkg: Add PACKAGECONFIG for liblzma and enable it

liblzma is part of xz and we already build it but configure it out. This makes no sense. Enabling it means we gain multithreaded compression and it speeds dpkg-deb up massively. It also removes the fork overhead of separate xz processes. Turning the existing config into a PACKAGECONFIG and

[OE-core] [PATCH 1/2] scripts: add oe-build-perf-report script

A new tool for pretty-printing build perf test results stored in a Git repository. The scripts is able to produce either simple plaintext report showing the difference between two commits, or, an html report that also displays trendcharts of the test results. The script uses Jinja2 templates for

[OE-core] [PATCH 0/2] Tools for visualizing build performance test results

This patchset implements two new scripts for analyzing and reporting build performance test results. The first script is a tool that is able to generate test reports from build perf test data stored in a Git repository. Both plain text and html output formats are supported. The second script is a

[OE-core] [PATCH 2/2] scripts/contrib: add oe-build-perf-report-email

Script for sending build perf test reports as an email. Mangles an html report, generated by oe-build-perf-report, into a format suitable for html emails. Supports multipart emails where a plaintext alternative can be included in the same email. Dependencies required to be installed on the host:

Re: [OE-core] [PATCH] openssl: add a "openssl10" PROVIDES

Alexander, On 03/31/2017 02:31 AM, Alexander Kanavin wrote: In 2.4 development cycle openssl 1.1 will replace openssl 1.0 as the default openssl version. Openssl 1.0 will stay but will be renamed to openssl10, and eventually it will be removed (hopefully much sooner than the official end of

[OE-core] [PATCH morty v2] wic: partition: Run fsck on EXT file systems

Mkfs may create EXT file systems which can only be optimized by fsck and not by itself, e.g. directory optimization (in Pass 3A). To prevent those optimizations during runtime, it will be performed after the creation of an EXT file system. Signed-off-by: Daniel Schultz ---

[OE-core] ✗ patchtest: failure for busybox: make SYSLOGD optionnal

== Series Details == Series: busybox: make SYSLOGD optionnal Revision: 1 URL : https://patchwork.openembedded.org/series/6101/ State : failure == Summary == Thank you for submitting this patch series to OpenEmbedded Core. This is an automated response. Several tests have been executed on the

[OE-core] ✗ patchtest: failure for "[v3,1/2] autoconf: Adjust sheb..." and 1 more (rev2)

== Series Details == Series: "[v3,1/2] autoconf: Adjust sheb..." and 1 more (rev2) Revision: 2 URL : https://patchwork.openembedded.org/series/6033/ State : failure == Summary == Thank you for submitting this patch series to OpenEmbedded Core. This is an automated response. Several tests

Re: [OE-core] [PATCH] systemd: check 'efi' in MACHINE_FEATURES

On 30/03/17 19:15, Burton, Ross wrote: On 30 March 2017 at 07:59, Mikko Ylinen > wrote: I'm fine. Perhaps 'efi' should not be a PACKAGECONFIG at all (and unconditionally disabled here) and the functionality (just

Re: [OE-core] [PATCH] u-boot: Update to 2017.03 release

On 30 March 2017 at 19:06, Denys Dmytriyenko wrote: > "Known devil is better than unknown angel"? :) > Agreed, fwiw. It's late and u-boot is quite important: cherry-pick the patch for Pyro and master can upgrade once it has branched. Ross --

[OE-core] [PATCH v3 0/2] automake/autoconf: avoid path to perl interpreter hardcoding

Hi, This is updated series of changes to autoconf/automake where I address all questions from previous review session. Please review again. Thanks. Cc: XE-Linux Serhii Popovych (2): autoconf: Adjust shebang lines to remove interpreter path hardcode automake:

[OE-core] [PATCH v3 2/2] automake: Adjust shebang lines to remove interpreter path hardcode

If build host perl (and other tools) is old and we use some kind of toolchain to provide recent perl/python/etc to the OE build we still locked to use build host perl due to hardcoded shebang lines in automake scripts. Behaviour was observed with Enterprise Linux 6 and devtoolset toolchain from

[OE-core] [PATCH v4 1/2] autoconf: Adjust shebang lines to remove interpreter path hardcode

If build host perl (and other tools) is old and we use some kind of toolchain to provide recent perl/python/etc to the OE build we still locked to use build host perl due to hardcoded shebang lines in autoconf scripts. Behaviour was observed with Enterprise Linux 6 and devtoolset toolchain from

[OE-core] [PATCH] busybox: make SYSLOGD optionnal

Some distros might choose another syslogd provider like rsyslogd. update-alternative will update the link from syslogd to the right provider. However the syslogd feature is still present and enabled in busybox. This commit adds a new configuration fragment to make syslogd optionnal in busybox.

Re: [OE-core] [PATCH] ca-certificates: Fix symlinks to the certificates in nativesdk

> > On Thu, Mar 30, 2017 at 11:30 AM, Serhii Popovych > wrote: > > > > > On 29 March 2017 at 13:51, Serhii Popovych > > >> wrote:

Re: [OE-core] [PATCH] glibc: Support building with 2.6.32 kernels on x86 / x86_64

> >> >> >> On 3/28/17 11:57 AM, Serhii Popovych wrote: >>> While glibc states that 2.6.32 kernels still supported >>> for x86 / x86_64 builds are failing due to out of date >>> LIBC_LINUX_VERSION macro checks for such architectures. >>> >>> This macro statically defined to 3.2.0 with commit

Re: [OE-core] [PATCH] busybox: drop unmaintained _git recipe

On 31 March 2017 at 02:57, ChenQi wrote: > This git recipe is maintained as far as I know. It was added so that it > would be easier to hack with busybox. As busybox is broadly used in our > project, an easier way to hack with it seems reasonable. > git log doesn't really

[OE-core] [PATCH] openssl: add a "openssl10" PROVIDES

In 2.4 development cycle openssl 1.1 will replace openssl 1.0 as the default openssl version. Openssl 1.0 will stay but will be renamed to openssl10, and eventually it will be removed (hopefully much sooner than the official end of support date of Dec 2019, as we do not want an unsupported openssl

Re: [OE-core] [meta-clang] oe-core and meta-clang llvm coexsting?

On 30 March 2017 at 20:20, Martin Kelly wrote: > I'm trying to integrate the meta-clang version of LLVM 4.0 (used for > recipes that need a newer LLVM version) alongside the oe-core version of > LLVM 3.3 (used for mesa). I'd like some recipes to use LLVM 4.0 and some to > use

Re: [OE-core] [PATCH] libjpeg-turbo: fix build on aarch64 or non-intel build hosts

On 31 March 2017 at 08:43, Tristan Van Berkom < tristan.vanber...@codethink.co.uk> wrote: > So just to get things straight, does this mean we no longer need the > patch to remove nasm-native from the jpeg turbo dependencies on non- > intel targets ? > > I think "-native" here only means "build an

Re: [OE-core] [PATCH] libjpeg-turbo: fix build on aarch64 or non-intel build hosts

On Thu, 2017-03-30 at 12:21 +0100, Burton, Ross wrote: > > > Agree with Andre here. I would suggest to update nasm recipe to > > support > > build for other archs as well (tested on arm and it works as > > expected. Will > > require more testing on other archs). > > Yes.  Simply deleting the