On Tue, Feb 6, 2018 at 2:44 PM, Martin Jansa wrote:
> * https://github.com/iputils/iputils/blob/master/RELNOTES.old
> mentiones that IDN was enabled by default in:
> [s20160308] and surprisingly the same in [s20150815]
> but there are no release notes for s20151218 version we were using unti
On Wed, 2018-02-07 at 10:53 +0530, avinash.reddy.pall...@intel.com
wrote:
> From: Avinash Reddy Palleti
>
> Adding reference to iwlwifi-8000c firmware which was removed
> erroneously in
> commit 3e4b382c0c687a76f824cd84b478c4f778e15e3e
>
Blame me!
> Signed-off-by: Avinash Reddy Palleti >
Ack
From: Avinash Reddy Palleti
Adding reference to iwlwifi-8000c firmware which was removed erroneously in
commit 3e4b382c0c687a76f824cd84b478c4f778e15e3e
Signed-off-by: Avinash Reddy Palleti
---
meta/recipes-kernel/linux-firmware/linux-firmware_git.bb | 3 ++-
1 file changed, 2 insertions(+), 1
On Tue, 2018-02-06 at 15:39 -0800, Martin Kelly wrote:
> (ping)
>
> Paul, what do you about the options we have here for making meson
> work
> properly in the SDK?
>
> To recap, here are the available options. I'm wondering if you could
> give your opinion on the best fit for how OE SDKs work:
autoconf-doc package contains autoconf.info.
This file contains date when this file was created, i.e:
"This manual (31 January 2018) .."
Therefore, two builds done on two different days will show different dates for
otherwise identical files, hence breaking reproducibility.
The date is obtai
(ping)
Paul, what do you about the options we have here for making meson work
properly in the SDK?
To recap, here are the available options. I'm wondering if you could
give your opinion on the best fit for how OE SDKs work:
- Generate meson.cross toolchain file at SDK extraction time.
- Wra
* https://github.com/iputils/iputils/blob/master/RELNOTES.old
mentiones that IDN was enabled by default in:
[s20160308] and surprisingly the same in [s20150815]
but there are no release notes for s20151218 version we were using until
now, don't know how it really relates to [s20150815].
*
https://github.com/iputils/iputils/blob/master/RELNOTES.old
mentiones that IDN was enabled by default in:
[s20160308] and surprisingly the same in [s20150815]
but there are no release notes for s20151218 version we were using until
now, don't know how it really relates to [s20150815].
https://git
== Series Details ==
Series: Fix support for Icecream
Revision: 1
URL : https://patchwork.openembedded.org/series/10867/
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 propos
When files are added to the environment, multiple aliases can be given
for the file (by calling add_path multiple times with a second
argument). All of these names will end up with a symlink to the original
file.
Signed-off-by: Joshua Watt
---
.../icecc-create-env/icecc-create-env |
If icecc is inherited, generated SDKs will automatically have optional
support for compiling using the IceCream distributed compiler
Signed-off-by: Joshua Watt
---
meta/classes/icecc.bbclass | 7 +++
1 file changed, 7 insertions(+)
diff --git a/meta/classes/icecc.bbclass b/meta/classes/icec
IceCream can now be optionally included in the generated SDK by
including nativesdk-icecc-toolchain to TOOLCHAIN_HOST_TASK. When the SDK
is installed, it will check if icecc exists, and if so will generate the
toolchain environment.
Signed-off-by: Joshua Watt
---
.../icecc-toolchain/icecc-toolch
icecc-create-env can now be built as a nativesdk recipe, allowing the
script to be included as part of an SDK
Signed-off-by: Joshua Watt
---
.../{icecc-create-env-native_0.1.bb => icecc-create-env_0.1.bb} | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
rename meta/recipes-devtoo
Recipes can now install post-relocation scripts which will be run when
the SDK is installed.
Signed-off-by: Joshua Watt
---
meta/classes/toolchain-scripts.bbclass | 15 +++
meta/files/toolchain-shar-extract.sh | 8
meta/recipes-core/meta/meta-environment.bb | 2 +
ldd cannot always be used to determine a programs dependencies
correctly, particularly when the program specifies an alternate program
interpreter (dynamic loader). This commonly happens when using a
uninative tarball. Instead, determine the program's requested
interpreter, and ask it to list the d
Taring up the toolchain is now done by adding the entire working
directory, instead of listing all the files individually. This is done
because the list of files may contain ".." entries, which tar does not
like and strips out, resulting in bad archives. This should result in an
identical archive t
Executables in the toolchain archive occasionally contain runtime
library search paths (RPATH) that use the $ORIGIN placeholder. However,
in order for that placeholder to work, /proc must be mounted. When
iceccd executes the toolchain in the chroot environment, it doesn't
mount /proc, so it is unab
Instead of renaming files to a new path in the toolchain archive, keep
the files with their original paths and create a relative symbolic link
from the new path to the original file.
Signed-off-by: Joshua Watt
---
.../icecc-create-env/icecc-create-env | 64 +++---
1
icecream daemons execute /bin/true from the environment as a check to
determine if the environment is valid at all, so it needs to be
included.
Signed-off-by: Joshua Watt
---
.../icecc-create-env/icecc-create-env/icecc-create-env | 10 ++
1 file changed, 10 insertions(+)
diff --
The environment script used an annoying mix of tabs and spaces, and no
mapping of tabs to spaces would produce pleasant indentation. Reformat
to eliminate tab characters and settle on 4 spaces for indentation
(which matches the upstream icecream script from which this is derived)
Signed-off-by: Jo
STAGING_BINDIR_TOOLCHAIN is actually a path list, not a single path. Fix
icecc.bbclass to try all the paths in the variable instead of treating
it as a single path.
Signed-off-by: Joshua Watt
---
meta/classes/icecc.bbclass | 17 -
1 file changed, 8 insertions(+), 9 deletions(-)
icecc.bbclass will no longer attempt to distribute cross-canadian
compiles. While technically possible to generate a toolchain that runs
on the build system and generates executables for the host system, this
is not the normal way that icecc operates and there are so few of these
recipes that it is
Generate the icecc toolchains in a shared work directory. This class was
already setup to correctly synchronize creating the toolchains in a
shared location before the RSS changes, so return to that behavior
instead of generated the toolchains in each recipe's sysroot.
Additionally, it makes no sen
Doesn't this new version depend on libidn?
Maybe it should be new PACKAGECONFIG or something, but here all builds fail
with:
| In file included from ping_common.c:1:0:
| ping.h:39:10: fatal error: idna.h: No such file or directory
| #include
| ^~~~
I'm running another build with
Fix up support for using Icecream to do distributed builds, which
appears to have been broken for some time.
In addition, Icecream support can now be enabled in the SDK. When
enabled, the SDK install process will check if the host supports icecc
and if so will construct a proper environment tarbal
From: Denys Dmytriyenko
This resolves a conflict when both python-nose and python3-nose are pulled
into an image and try to install ${bindir}/nosetests binary.
This matches with how other distros are solving this problem, e.g. Debian:
https://packages.debian.org/jessie/all/python3-nose/filelist
From: Khem Raj
Fix build when PIE is turned on. It tries to build
.so file using -pie and -shared flags together because
its doing compile and link in same step CFLAGS and LDFLAGS
are combined and does not work, ending in errors e.g.
|
/mnt/a/oe/build/tmp/work/cortexa7t2hf-neon-vfpv4-bec-linux-
Shortly after leaving work last night I realized that this error should
have nothing to do with the initrd/initramfs, as this wic image is not
using one.
Also, in 300 runs of this test the error didn't occur once, so it
appears to be very rare.
---
Cal
On 02/05/2018 05:52 PM, Cal Sullivan w
> This “| xargs” at the end seems redundant. xargs what? xargs is used to run a
> command on each word of > the input..
It forces the words into one line:
$ echo "zebra fox elephant elephant lion wolf fox " | xargs -n1 | sort -u |
xargs
elephant fox lion wolf zebra
$echo "zebra fox elephant e
Hi,
You wrote:
> 2018-02-05 16:55 keltezéssel, Matthijs Vader írta:
> > Hi,
> >
> > 2018-02-05 15:07, zboszor wrote:
> >> I have already sent this patch (although a little extended) last week:
> >> http://lists.openembedded.org/pipermail/openembedded-core/2018-
> >> February/147071.html
> >
> > T
== Series Details ==
Series: yocto-bsp: delete bbappends for removed kernels
Revision: 1
URL : https://patchwork.openembedded.org/series/10862/
State : failure
== Summary ==
Thank you for submitting this patch series to OpenEmbedded Core. This is
an automated response. Several tests have been
4.4/4.9/4.10 are gone from oe-core master, so we can drop our
bbappends.
4.12 will be removed in the future and 4.14/4.15 added, but all
default versions should be 4.12+ now.
Signed-off-by: Bruce Ashfield
---
.../recipes-kernel/linux/linux-yocto_4.10.bbappend | 27 --
.../re
Ensure that the qemu* machines are building the latest available
kernel in master.
Signed-off-by: Bruce Ashfield
---
meta/conf/machine/include/x86-base.inc | 2 +-
meta/conf/machine/qemuarm.conf | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/meta/conf/machine/incl
As was previously announced, anything older than 4.14 is being
dropped in the master/release branches to better support newer
processors and to ensure that safe/secure kernels are the
defaults for all builds. The time required to update the older
kernels with constant updates (more than just CVEs)
As was previously announced, anything older than 4.14 is being
dropped in the master/release branches to better support newer
processors and to ensure that safe/secure kernels are the
defaults for all builds. The time required to update the older
kernels with constant updates (more than just CVEs)
As was previously announced, anything older than 4.14 is being
dropped in the master/release branches to better support newer
processors and to ensure that safe/secure kernels are the
defaults for all builds. The time required to update the older
kernels with constant updates (more than just CVEs)
Signed-off-by: Bruce Ashfield
---
.../lttng/{lttng-modules_2.10.4.bb => lttng-modules_2.10.5.bb}| 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
rename meta/recipes-kernel/lttng/{lttng-modules_2.10.4.bb =>
lttng-modules_2.10.5.bb} (90%)
diff --git a/meta/recipes-kernel/lttng/l
Backporting the following pinctrl commits to enable controllers on
Intel Cannon Lake:
4b7a5c1b4ec5 pinctrl: intel: Add Intel Cannon Lake PCH-H pin controller
support
044631ce1937 pinctrl: intel: Add Intel Cannon Lake PCH pin controller support
2054b0ea59a7 pinctrl: intel: Make it possible t
Signed-off-by: Bruce Ashfield
---
meta/conf/distro/include/tcmode-default.inc| 2 +-
...mpat.h-fix-some-issues-arising-from-in6.h.patch | 29 -
...t.h-prevent-redefinition-of-struct-ethhdr.patch | 36 +++---
...aders_4.14.13.bb => linux-libc-headers_4.15.b
This commit makes the 4.15 kernel available for use with the
Yocto configuration fragments and qemu* BSPs.
It has been tested for x86,arm,mips and powerpc against the lsb, core*
and glibc/mulsc test matrix.
This will serve as the "latest" kernel in master, with others being
removed in subsequent
This commit makes the 4.14 kernel available for use with the
Yocto configuration fragments and qemu* BSPs.
It has been tested for x86,arm,mips and powerpc against the
lsb, core* and glibc/mulsc test matrix.
This will serve as the LTS kernel in master, with others being
removed in subsequent commi
Hi all,
Here is my first proposed set of kernel updates for the April release. Some
elements that I'd like to point out:
- I've moved to a single/branch versioned linux-yocto repository that I first
proposed in the 4.8 kernel cycle, no one objected, so I've moved v4.14 and
v4.15 into that
Signed-off-by: Alexander Kanavin
---
meta/recipes-extended/iputils/files/0001-Fix-build-on-MUSL.patch | 2 ++
1 file changed, 2 insertions(+)
diff --git a/meta/recipes-extended/iputils/files/0001-Fix-build-on-MUSL.patch
b/meta/recipes-extended/iputils/files/0001-Fix-build-on-MUSL.patch
index c8
The test runs a scriptlet that has an intentionally failing command in the
middle
and checks for two things:
1) that bitbake does warn the user about the failure
2) that scriptlet execution stops at that point.
The test is run for all three package types: rpm, deb, ipk.
Signed-off-by: Alexander
This allows catching errors in the scriptlets which would otherwise
go unnoticed, e.g. this sequence:
bogus_command
proper_command
would work just fine without any visible warnings or errors.
This was previously done only for rpm packages; this patch replaces
the rpm-specific tweak with
Previously this was done only for rpm packages; now also ipk/deb scriptlet
failures are reported.
In the future this will become a hard error, but it can't yet happen
due to the legacy 'exit 1' way of deferring scriptlet execution to first boot
which
needs a deprecation period.
Signed-off-by: Al
I'm sorry, I haven't seen this one, because I have packagegroup-core-lsb
blacklisted for long time.
What is preferred fix?
1) add the same restriction to packagegroup-core-lsb and core-image-lsb and
someone will fix poky-lsb build (it doesn't seem like separate distro), to
include pam in DISTRO_FE
Back in 2010 the expat 2.0.1 tarball wouldn't unpack correctly with old gzip
releases (prior to 1.4). The fix was to explicitly depend on gzip-native to use
our binary instead of the host[1].
We don't ship expat 2.0.1 anymore, and even Centos 7 ships gzip 1.5, so this
workaround can be removed.
Signed-off-by: Ross Burton
---
meta/recipes-extended/pigz/pigz_2.4.bb | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/meta/recipes-extended/pigz/pigz_2.4.bb
b/meta/recipes-extended/pigz/pigz_2.4.bb
index 20e4154434f..6e6da9c3c56 100644
--- a/meta/recipes-extended/pigz
Whilst pigz is effectively a parallel gzip, the command line arguments are not
the same so pigz isn't a drop-in replacement for gzip.
[ YOCTO #12139 ]
[ YOCTO #12410 ]
Signed-off-by: Ross Burton
---
meta/conf/distro/include/default-providers.inc | 1 -
meta/recipes-extended/pigz/pigz_2.4.bb
Signed-off-by: Ross Burton
---
meta/recipes-core/expat/expat.inc | 25 -
meta/recipes-core/expat/expat_2.2.5.bb | 28 +++-
2 files changed, 27 insertions(+), 26 deletions(-)
delete mode 100644 meta/recipes-core/expat/expat.inc
diff --git a/me
2018-02-05 16:55 keltezéssel, Matthijs Vader írta:
Hi,
2018-02-05 15:07, zboszor wrote:
I have already sent this patch (although a little extended) last week:
http://lists.openembedded.org/pipermail/openembedded-core/2018-
February/147071.html
Thanks! The second patch you sent in with that ac
On 6 February 2018 at 02:03, Anuj Mittal wrote:
> +SRC_URI = "https://github.com/intel/${BPN}/releases/download/${PV}/$
> {BPN}-${PV}.tar.bz2"
>
For convenience bitbake.conf defines BP:
BP = "${BPN}-${PV}"
Don't bother sending a V3 as I'll just make this change when merging.
Ross
--
Ping?
On Mon, Jan 29, 2018 at 4:38 PM, Stefan Stanacar wrote:
> do_unpack is by default in SRCTREECOVEREDTASKS so this append can't run,
> since
> do_unpack gets removed by when externalsrc is enabled.
>
> This was hidden because externalsrc does actually run do_fetch and
> do_unpack if
> there
On Tuesday, 6 February 2018 11:25:08 AM NZDT Burton, Ross wrote:
> On 5 February 2018 at 22:13, Denys Dmytriyenko wrote:
>
> > On Mon, Feb 05, 2018 at 09:53:44PM +, Burton, Ross wrote:
> > > On 5 February 2018 at 18:21, Denys Dmytriyenko wrote:
> > >
> > > > Am I supposed to see bunch of the
55 matches
Mail list logo