Now that the bootstrap sequence for pypa/build is just
python3-packaging, and python3-pyproject-hooks, we can use build instead
of picobuild.
The only change visible outside of this class is that the variable
PEP517_PICOBUILD_OPTS is now PEP517_BUILD_OPTS, but I'm only aware of one
recipe that used that variable.
(From OE-Core rev: 202c2e3c9481a8841af2556862a76e27d703246d)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This is the PEP517 build frontend blessed by the Python Packaging
Authority, and now that Python 3.11 has been released and enough
packages have ported to flit, it can be used without a huge bootstraping
problem.
(From OE-Core rev: 00254501b9b024032032c9fb068d957de4ef7dde)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This used to be known as python3-pep517 and is a key library used to
build modern Python code.
It is currently vendored into python3-picobuild but I plan to remove
that.
(From OE-Core rev: 877c4d5e4cd5ceb71d2ecfdc35a625f50752bec0)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Previously, if "showSignature" is present in user gitconfig, parsing
of the timestamp will fail.
Ideally we should replace this command with a git plumbing command.
(From OE-Core rev: 3bd6f78f79b3d3e87d8db1e11f58d8021f929843)
Signed-off-by: Benoît Mauduit <bmauduit@beneth.fr>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The create_spdx code relies on patched code, if files are changed
or added during the do_configure phase they will be missed by the
create_spdx process. So we need to ensure files modifications/additions
happen in the do_patch phase.
(From OE-Core rev: 227c46fe48b64de7574f7b6b407b8c13be71b392)
Signed-off-by: Saul Wold <saul.wold@windriver.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
In oe-core 27824261 --enable-debug was added to the configure arguments
to turn on debugging symbols. However, enabling debug mode does more
than turn on debugging symbols and introduces some codepaths that can be
controlled with environment variables. Bluntly, the curl maintainer
says that --enable-debug should not be used in production:
https://curl.se/mail/lib-2023-01/0039.html
I did a build and verified that the curl-dbg package doesn't massively
shrink, so the debug symbols are still being built.
Remove the debug options and hide them behind a PACKAGECONFIG, with a
comment that it should not be used in production.
(From OE-Core rev: 3ed3b2ffeeaa5d888f77dd30cb8cd81d3275398a)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Fixed an error when Bash's unbound variable protection is enabled (set -u) and variable "LD_LIBRARY_PATH" does not exist.
(From OE-Core rev: 85685370b0ad93291cda59fb091a15eeecf5e0d5)
Signed-off-by: Jan Kircher <openembedded@hetsh.de>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
In case of nodistro, dhcpcd gives us 'Bad system call'
error and exits. This is because there are syscalls that
should be allowed but not in privsep. Backport two patches
to fix this issue.
(From OE-Core rev: f1e6a0c16d6685096ec9313301aa431e73d02c07)
Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
NEON is enabled for aarch64 by default, so, to ensure consistency with
arm32, reference to libpng-1.6.38/configure, added
enable_hardware_optimizations option for aarch64.
(From OE-Core rev: 12e68d5824849fa20f0e3fe8fc1921da111bb6fb)
Signed-off-by: Lei Maohui <leimaohui@fujitsu.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Currently, the opkg-key utility calls gpg with --no-options,
which uses /dev/null as the configuration file. This means
any configurations in /etc/opkg/gpg/gpg.conf were being
ignored. This change applies a patch to remove the
--no-options flag.
(From OE-Core rev: 3699096f3214e77fe4aa1daebe85308d02940f2f)
Signed-off-by: Charlie Johnston <charlie.johnston@ni.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Changelog:
===========
- implement a fix for CVE-2022-4170 (reported and analyzed by David Leadbeater).
While present in version 9.30, it should not be exploitable. It is exploitable
in versions 9.25 and 9.26, at least, and allows anybody controlling output to
the terminal to execute arbitrary code in the urxvt process.
- the background extension no longer requires off focus fading support
to be compiled in.
- the confirm-paste extension now offers a choice betwene pasting the original
or a sanitized version, and also frees up memory used to store the paste text
immediately.
- fix compiling without frills.
- fix rewrapMode: never.
- fix regression that caused urxvt to no longer emit responses
to OSC color queries other than OSC 4 ones.
- fix regression that caused urxvt to no longer process OSC 705.
- restore CENTURY to be 1900 to "improve" year parsing in urclock (or at
least go back to the old interpretation) (based on an analysis
by Tommy Pettersson).
- exec_async (used e.g. by the matcher extension to spawn processes) now
sets the URXVT_EXT_WINDOWID variable to the window id of the terminal.
- implement -fps option/refreshRate resource to change the default 60 Hz
maximum refresh limiter. I always wanted an fps option, but had to
wait for a user requesting it.
- new clickthrough extension.
- perl now also requires Xext.
- X region and shape extension functionality has been exposed to perl
extensions.
- RENDER extension no longer depends on ENABLE_XIM_ONTHESPOT.
(From OE-Core rev: 9caf2cbd7dd82e72d0a04052fc93435f62e249ce)
Signed-off-by: Wang Mingyu <wangmy@fujitsu.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Changelog:
==========
- The "fondue savoyarde" release.
- Binary compatible with MPFR 4.0.* and 4.1.*, though some minor changes in
the behavior of the formatted output functions may be visible, regarded
as underspecified behavior or bug fixes (see below).
- New functions mpfr_cosu, mpfr_sinu, mpfr_tanu, mpfr_acosu, mpfr_asinu,
mpfr_atanu and mpfr_atan2u.
- New functions mpfr_cospi, mpfr_sinpi, mpfr_tanpi, mpfr_acospi, mpfr_asinpi,
mpfr_atanpi and mpfr_atan2pi.
- New functions mpfr_log2p1, mpfr_log10p1, mpfr_exp2m1, mpfr_exp10m1 and
mpfr_compound_si.
- New functions mpfr_fmod_ui, mpfr_powr, mpfr_pown, mpfr_pow_uj, mpfr_pow_sj
and mpfr_rootn_si (mpfr_pown is actually a macro defined as an alias for
mpfr_pow_sj).
- Bug fixes.
In particular, for the formatted output functions (mpfr_printf, etc.),
the case where the precision consists only of a period has been fixed
to be like ".0" as specified in the ISO C standard, and the manual has
been corrected and clarified.
The macros of the custom interface have also been fixed: they now behave
like functions (except a minor limitation for mpfr_custom_init_set).
(From OE-Core rev: 7df43a56b0146ac2a73f7bb97aeac8f11629878f)
Signed-off-by: Wang Mingyu <wangmy@fujitsu.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Changelog:
==========
- Add 'xkb_context' flag 'XKB_CONTEXT_NO_SECURE_GETENV' and 'rxkb_context' flag
'RXKB_CONTEXT_NO_SECURE_GETENV'.
xkbcommon uses 'getenv_secure()' to obtain environment variables. This flag
makes xkbcommon use 'getenv()' instead.
This is useful for some clients that have relatively benign capabilities set,
like CAP_SYS_NICE, that also want to use e.g. the XKB configuration from the
environment and user configs in XDG_CONFIG_HOME.
Contributed by Ronan Pigott.
- Fix crash in 'xkbcli interactive-wayland' under a compositor which supports
new versions of the xdg-shell protocol.
Contributed by Jan Alexander Steffens (heftig).
- Fix some MSVC build issues.
- Fix some issues when including xkbcommon as a meson subproject.
- meson>=0.51 is now required.
- New API:
XKB_CONTEXT_NO_SECURE_GETENV
RXKB_CONTEXT_NO_SECURE_GETENV
(From OE-Core rev: 3aff7e09bacdc53896e5149f494846ef95c78408)
Signed-off-by: Wang Mingyu <wangmy@fujitsu.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
- The qemux86 port for helloworld-baremetal builds in the standard way, however,
it uses NASM syntax for the startup code, hence we include a dependency to
nasm-native, QEMU forces us to use an ELF file rather than a bin file to boot
from this architecture using the -kernel parameter.
- QEMU refuses to boot using the -kernel parameter for files containing an ELF64
header [1], instead, it requires a multiboot2 compatible image.
We could create an image that contains a multiboot2 header by piggybacking
into grub2-native, specifically grub-mkrescue, but it requires some extra
runtime dependencies (xorriso which is currently part of meta-oe), and assumes
a grub installation exists on the host.
Due to host contamination and dependency complications, we dont rely on grub2,
but rather do this process manually instead, the x86-64 port contains a stage1
bootloader, stage2 bootloader and a 64 bit baremetal app (multiboot2
compatible), booting into real (16 bit), protected (32 bit) and long (64 bit)
modes, eventually running the helloworld-baremetal app. This is the reason why
we need the code changes to use a separate Makefile, and create an image
specifically for qemux86-64.
$ runqemu nographic
Booting from ROM..
Hello OpenEmbedded on x86!
$ runqemu nographic
Starting Stage 1 Bootloader
Loading Stage 2 Bootloader
Stage 2 Loaded.
Jumping to Stage2 Bootloader
In Stage 2
Done
Hello OpenEmbedded on x86-64!
[1] https://gitlab.com/qemu-project/qemu/-/blob/v7.2.0/hw/i386/multiboot.c#L199
(From OE-Core rev: 1dffd81b2991f90ab95cb36d8ff7626efd21434f)
Signed-off-by: Alejandro Enedino Hernandez Samaniego <alejandro@enedino.org>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* use Skylake-Client to match QB_CPU_KVM as changed in:
https://git.openembedded.org/openembedded-core/commit/?id=6f2af1e5d1537b4d31e14946292bf58f0fd76fc9
* explicitly set -cpu instead of letting qemu to choose based
on host cpu
* check=false is still useful as e.g. on on AMD Threadripper 3970X:
orc/0.4.33-r0 $ PSEUDO_UNLOAD=1 qemu-x86_64 -r 3.2.0 -cpu Skylake-Client -L recipe-sysroot -E LD_LIBRARY_PATH=recipe-sysroot//usr/lib:recipe-sysroot//lib
orc/0.4.33-r0/build/meson-private/sanitycheckc_cross.exe
qemu-x86_64: warning: TCG doesn't support requested feature: CPUID.01H:ECX.pcid [bit 17]
qemu-x86_64: warning: TCG doesn't support requested feature: CPUID.01H:ECX.x2apic [bit 21]
qemu-x86_64: warning: TCG doesn't support requested feature: CPUID.01H:ECX.tsc-deadline [bit 24]
qemu-x86_64: warning: TCG doesn't support requested feature: CPUID.07H:EBX.hle [bit 4]
qemu-x86_64: warning: TCG doesn't support requested feature: CPUID.07H:EBX.invpcid [bit 10]
qemu-x86_64: warning: TCG doesn't support requested feature: CPUID.07H:EBX.rtm [bit 11]
qemu-x86_64: warning: TCG doesn't support requested feature: CPUID.07H:EBX.rdseed [bit 18]
qemu-x86_64: warning: TCG doesn't support requested feature: CPUID.80000001H:ECX.3dnowprefetch [bit 8]
qemu-x86_64: warning: TCG doesn't support requested feature: CPUID.0DH:EAX.xsavec [bit 1]
* if this still doesn't work for you on your host, you might need to downgrade
DEFAULTTUNE to e.g. corei7-64 (all all the way back to core2-64), for
more details see:
https://www.openembedded.org/pipermail/openembedded-core/2018-April/150178.html
* the leading space shouldn't be needed, I've kept it for consistency
with other QEMU_EXTRAOPTIONS
(From OE-Core rev: d1a52559670921389a66a4c26d37481d6611042a)
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
off_t is always 64bit on musl regardless of 32bit or 64bit
architectures. autoconf has AC_SYS_LARGEFILE to detect correct off_t
size but it only work with glibc since it defines feature macros
_FILE_OFFSET_BITS=64 and _LARGEFILE_SOURCE but these macros are
not used on musl headers.
(From OE-Core rev: 09b3e8417d362b75f3b43a5a97b47700f97bf643)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Cc: Nicolas Dechesne <nicolas.dechesne@linaro.org>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Otherwise gnome-chess will fail like this:
| error: Package `librsvg-2.0' not found in specified Vala API directories or GObject-Introspection GIR directories
| Compilation failed: 1 error(s), 0 warning(s)
(From OE-Core rev: ed814eff90677f894d9eb480d8d4389c64a35820)
Signed-off-by: Markus Volk <f_l_k@t-online.de>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
With the dim-sum approach to patching we had the same patch applied in
many places, but not all, so that there were no guarantees that we were
actually building agaginst the same thing in all recipes.
(From OE-Core rev: 550c273f38d8e6d2d431908023e213c6b018d7ed)
Signed-off-by: Alex Kiernan <alex.kiernan@gmail.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
- remove unneded backport patches
- partly import the patch to fix ssh_agent option from gcr4 recipe
- convert from gtk-doc to gi-docgen
gcr 3.41.1:
- meson: Fix unknown kw argument in gnome.generate_gir [GNOME/gcr!68]
- gcr: Add G_SPAWN_CLOEXEC_PIPES flag to all the g_spawn commands
- docs: Port from gtk-doc to gi-docgen [GNOME/gcr!76]
- Unbreak build without systemd [GNOME/gcr!75]
- Several CI fixes
- Updated translations
gcr 3.41.0:
- Port ssh-agent from gnome-keyring [GNOME/gcr!67]
- build: Fix parallel build failure due to missing marshal dependency [GNOME/gcr!68]
- Fix warnings by dropping `volatile` for g_once_init_inter locations [GNOME/gcr!69]
- tests: More robust against GTask unref race condition [GNOME/gcr!72,GNOME/gcr#84]
- Updated translations
(From OE-Core rev: 9d66a3e9b9908592050ad706a950d76b6499a49e)
Signed-off-by: Markus Volk <f_l_k@t-online.de>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This is a follow-up to commit 846ff49465 to remove the extra whitespace
that is no longer needed after converting :append and :prepend to += and
=+.
(From OE-Core rev: 5a38be49e451c9f9d973b10a33c3972507f7b18a)
Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Allow user to select the default DTB for FIT image when multiple
dtb's exists.
From machine.conf or local.conf user can specify the default dtb
for FIT image as shown below.
FIT_CONF_DEFAULT_DTB = "board-default.dtb"
Also fallback to avaialable dtb when FIT_CONF_DEFAULT_DTB doesn't
exits or empty.
(From OE-Core rev: 160f2c58d68a049a87ddc7aedb2055152ac6ff4e)
Signed-off-by: Sandeep Gundlupet Raju <sandeep.gundlupet-raju@amd.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The dtb files must be before the dtbo files, otherwise the overlays may
not be applied correctly.
From Bruce Ashfield:
We can split between dtbs and dtbos, they just need to be sorted
for reproducibility reasons.
Of course, this was only working by luck previously (before the
sort), since it has always been gathering dtbs and dtbo's with
find, depending on filesystem ordering for the order in the
fitimage).
(From OE-Core rev: bcb3c0272f6ab846c3232548df1e1182bcc67486)
Signed-off-by: Sandeep Gundlupet Raju <sandeep.gundlupet-raju@amd.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
In some scenarios (e.g. when "glib" removed from PACKAGECONFIG),
"${D}${bindir}" might not exist which caused `rmdir` to fail.
(From OE-Core rev: 21261072cbe0056e85550a0710de142fab8943e4)
Signed-off-by: Petr Kubizňák <kubiznak@2n.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Rather than risk the heartbeat event code locking up the server control
socket, handle it in the 'idle' thread with the other work. The aim
is to remove it as a possible issue with some ongoing hangs.
(Bitbake rev: 0f9a0c7853b181817bf01863a26da21412376294)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Often, '--buildfile/-b' is used to mean "Do not execute anything but
this recipe", so it make sense to have it in the "Execution control
options" group.
Fixes [YOCTO #12018].
(Original suggestion by Ross Burton)
(Bitbake rev: 412a6d8701a92efe4dd6db8ec713c0013f7db64d)
Signed-off-by: Yoann Congal <yoann.congal@smile.fr>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The shutdown() call should definitely not be waiting for idle, since we
expect execution and events to continue even after setting either shutdown
state. This was causing the UI to appear to hang at Ctrl+C interrupts.
Also ensure that if we reset cooker, we stop any active parser processes
since these currently appear to be being left behind.
(Bitbake rev: 4f73c2eb12ee074f3b7d4717380649f6ca8f3def)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
There are three levels of shutdown, the initial "wait for current tasks",
then "stop current tasks" and "exit now". Change the code so that we don't
instantly exit after "stop current tasks" but allow the events to come
through from the server first. The new shutdown level allows that to then
be broken out of too.
(Bitbake rev: af38345b91cfc8a6bb5c38f5753255e7635bfe2b)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If for some reason the bitbake server dies, we shouldn't loop indefinitely
waiting for events within tinfoil. Add a ping test and exit if things
have somehow failed.
(Bitbake rev: 32da768ae67cfe0b2d154ce4667a7cfdfa5bf4b0)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Effectively revert "qemux86-64: build for x86-64-v3 (2013 Haswell and later) rather than Core 2 from 2006"
(commit 6f2af1e5d1537b4d31e14946292bf58f0fd76fc9)
Much as I'd love us to use the latest tuning, we do have some autobuilder
hardware which isn't ready for this yet which breaks KVM and some qemu
user mode usage as there appear to be TCG bugs too. I suspect we're not
the only ones with such hardware.
Drop the tune back to core2-64, anyone can easily customise it
themselves if they need it. We can revisit this in a year or two
as we should be ready then. It has beena good test of the rest of the
support which all seems ready.
I'd have preferred to use corei7-64 but that causes
runqemu.RunqemuTests.test_boot_machine_iso to hang.
Leave the newer tune file inclusion so people can change tunes
more easily.
(From OE-Core rev: 369b1dfa28b1791d45f068acc765190defecd460)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The curl-related deprecation errors affect all builds not just native,
so set CFLAGS instead of BUILD_CFLAGS.
(From OE-Core rev: 64ddce0cdbda4efe65f59a04ecb999e9fd3f82a4)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Primarily, before running the debuginfod-find tool, check that the
debuginfod server has finished sweeping the deploy directory. If we
make the request too soon then there's a rare chance that we run the
client before it has scanned the right packages, and the log gets
swamped with warnings from sqlite due to a race.
Also:
- unset DEBUGINFOD_URLS so the debuginfod doesn't proxy to an upstream
server provided by the host distro
- Lower concurrency to reduce system load and handle systems with lower
maximum open file counts but lots of cores (as the concurrency means
cores*2*2 open files)
- Set the refresh times to 0 so we never rescan during the test
- Only scan the packages for the format which the image is using
- Log the commands that are being invoked
(From OE-Core rev: d65729748253eaa640333198ca8aec05946cb9e8)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Recent changes in bitbake mean the datastore is not always reset between
ConfigParsed and BuildStarted. This means in a fresh buiild, with memory
resident bitbake active, uninative may end up disabled.
Update the code so the enable code is always run at BuildStarted if
needed.
(From OE-Core rev: db743cc78fe5172bb4a4dac9c1dad4f5aa9e1491)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
currentAsyncCommand currently doesn't have any locking and we have
a conflict in "idle" conditions since the idle functions count needs
to be zero *and* there needs to be no active command.
Move the changes/checks of currentAsyncCommand to within the lock
and then we can add it to the condition for idle, simplifying some
of the code.
(Bitbake rev: b5215887d2f8ea3f28f1ebda721bd5b8f93ec7f3)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Indirecting the async command handler via cooker is confusing and no
longer needed. Drop it to make things slightly clearer.
(Bitbake rev: 4a41a7d0594e6a84a67b9de70a505858aebcd84a)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The new uninative tarball is segfaulting in quilt (the underlying
patch binary). We see errors in dmesg like:
(patch): Uhuuh, elf segment at 0000000000400000 requested but the memory is mapped already
This patch submitted to patchelf upstream looks like an appropriate fix
for that.
(From OE-Core rev: cccd4bcaf381c2729adc000381bd89906003e72a)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
