This makes it possible to enable 'repo_gpgcheck' in dnf.conf. That is, do
GPG signature check on repository metadata. Without gnupg dnf fails with
"error: Invalid crypto engine."
[YOCTO #11209]
(From OE-Core rev: 8a7154cfe150840b451bc56951f0fa31cb8d6fa0)
Signed-off-by: Markus Lehtonen <markus.lehtonen@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
getentropy/random() is only available in glibc 2.25+ and uninative may relocate
binaries onto systems that don't have this function. For now, force the code to
the older codepaths until we can come up with a better solution for this kind of
issue.
(From OE-Core rev: 92bda0024d85ae78345665cc2f9646c9881ed61b)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The compiled .pyc files contain time stamp corresponding to the compile time.
This prevents binary reproducibility. This patch allows to achieve binary
reproducibility by overriding the build time stamp by the value
exported via SOURCE_DATE_EPOCH.
Patch by Bernhard M. Wiedemann.
[YOCTO#11241]
(From OE-Core rev: 2175aec10a764bfc925a3fb447547982d0ae662f)
Signed-off-by: Juro Bystricky <juro.bystricky@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When compressing by gzip, do not save the original file name and time stamp.
[YOCTO #11916]
(From OE-Core rev: c32d526a056adb8ed1eb8beb9d495bfd01af2342)
Signed-off-by: Juro Bystricky <juro.bystricky@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
python3-docutils recipe must be upgraded to latest stable release.
LIC_FILES_CHKSUM changed due to a typo fix from previous version,
but license type and information remained the same.
This change was tested on qemu with core-image-minimal.
(From OE-Core rev: f99247335485e15c820991e3ea20b766364111fc)
Signed-off-by: Jose Lamego <jose.a.lamego@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Both python-setuptools and python3-setuptools must be updated
to latest stable release.
These changes were tested on qemu with core-image-minimal
(From OE-Core rev: 147d9260eb79edfdf7a91fb8bc3d915f141dc685)
Signed-off-by: Jose Lamego <jose.a.lamego@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
In case a systemd service disables itself while init is still in its
boot sequence the reloading of the service files can be problematic.
In that case: It seems that systemd looses the state of .device units,
and some services depend on such units (namely serial consoles such as
serial-getty@ttymxc0.service). As a result no getty is spawned on the
affected serial tty.
After a power-cycle the second boot (which does not disable services)
succeeds.
The following sequence shows this problem:
| Jan 09 16:36:28 apalis-t30 systemctl[162]: Removed /etc/systemd/system/sysinit.target.wants/run-postinsts.service.
| Jan 09 16:36:28 apalis-t30 systemd[1]: Reloading.
| ...
| And then the failing one:
| Feb 22 15:33:15 apalis-t30 systemd[1]: dev-ttyS0.device: Job dev-ttyS0.device/start timed out.
| Feb 22 15:33:15 apalis-t30 systemd[1]: Timed out waiting for device dev-ttyS0.device.
| Feb 22 15:33:15 apalis-t30 systemd[1]: Dependency failed for Serial Getty on ttyS0.
| Feb 22 15:33:15 apalis-t30 systemd[1]: serial-getty@ttyS0.service: Job serial-getty@ttyS0.service/start failed with result 'dependency'.
| Feb 22 15:33:15 apalis-t30 systemd[1]: dev-ttyS0.device: Job dev-ttyS0.device/start failed with result 'timeout'.
| Feb 22 15:33:15 apalis-t30 systemd[1]: Reached target Login Prompts.
(the time has been updated between this two events, but that does not
influence the issue)
Using --no-reload in the service file avoids the "Reloading." message
above and seems to not cause such issues anymore.
Reported-by: Stefan Agner <stefan.agner@toradex.com>
(From OE-Core rev: 23b359b6e26d0b17037bf955bd15a16a3fd9ab8f)
Signed-off-by: Max Krummenacher <max.krummenacher@toradex.com>
(cherry picked from commit 4a425d05bac5dcba023b67aa3d726f7e7869404f)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
In case a systemd service disables itself while init is still in its
boot sequence the reloading of the service files can be problematic.
In that case: It seems that systemd looses the state of .device units,
and some services depend on such units (namely serial consoles such as
serial-getty@ttymxc0.service). As a result no getty is spawned on the
affected serial tty.
After a power-cycle the second boot (which does not disable services)
succeeds.
The following sequence shows this problem:
| Jan 09 16:36:28 apalis-t30 systemctl[162]: Removed /etc/systemd/system/sysinit.target.wants/run-postinsts.service.
| Jan 09 16:36:28 apalis-t30 systemd[1]: Reloading.
| ...
| And then the failing one:
| Feb 22 15:33:15 apalis-t30 systemd[1]: dev-ttyS0.device: Job dev-ttyS0.device/start timed out.
| Feb 22 15:33:15 apalis-t30 systemd[1]: Timed out waiting for device dev-ttyS0.device.
| Feb 22 15:33:15 apalis-t30 systemd[1]: Dependency failed for Serial Getty on ttyS0.
| Feb 22 15:33:15 apalis-t30 systemd[1]: serial-getty@ttyS0.service: Job serial-getty@ttyS0.service/start failed with result 'dependency'.
| Feb 22 15:33:15 apalis-t30 systemd[1]: dev-ttyS0.device: Job dev-ttyS0.device/start failed with result 'timeout'.
| Feb 22 15:33:15 apalis-t30 systemd[1]: Reached target Login Prompts.
(the time has been updated between this two events, but that does not
influence the issue)
Using --no-reload in the service file avoids the "Reloading." message
above and seems to not cause such issues anymore.
Reported-by: Stefan Agner <stefan.agner@toradex.com>
(From OE-Core rev: 059bc9b164d239f0ba319f8e6a54b5edf7761b22)
Signed-off-by: Max Krummenacher <max.krummenacher@toradex.com>
(cherry picked from commit 16b7b455ee40fd1be5bb9aacf24b106df0d9325e)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
In case a systemd service disables itself while init is still in its
boot sequence the reloading of the service files can be problematic.
In that case: It seems that systemd looses the state of .device units,
and some services depend on such units (namely serial consoles such as
serial-getty@ttymxc0.service). As a result no getty is spawned on the
affected serial tty.
After a power-cycle the second boot (which does not disable services)
succeeds.
The following sequence shows this problem:
| Jan 09 16:36:28 apalis-t30 systemctl[162]: Removed /etc/systemd/system/sysinit.target.wants/run-postinsts.service.
| Jan 09 16:36:28 apalis-t30 systemd[1]: Reloading.
| ...
| And then the failing one:
| Feb 22 15:33:15 apalis-t30 systemd[1]: dev-ttyS0.device: Job dev-ttyS0.device/start timed out.
| Feb 22 15:33:15 apalis-t30 systemd[1]: Timed out waiting for device dev-ttyS0.device.
| Feb 22 15:33:15 apalis-t30 systemd[1]: Dependency failed for Serial Getty on ttyS0.
| Feb 22 15:33:15 apalis-t30 systemd[1]: serial-getty@ttyS0.service: Job serial-getty@ttyS0.service/start failed with result 'dependency'.
| Feb 22 15:33:15 apalis-t30 systemd[1]: dev-ttyS0.device: Job dev-ttyS0.device/start failed with result 'timeout'.
| Feb 22 15:33:15 apalis-t30 systemd[1]: Reached target Login Prompts.
(the time has been updated between this two events, but that does not
influence the issue)
Using --no-reload in the service file avoids the "Reloading." message
above and seems to not cause such issues anymore.
Reported-by: Stefan Agner <stefan.agner@toradex.com>
(From OE-Core rev: e735c176361fca43420565dcb8900bbff2f3664e)
Signed-off-by: Max Krummenacher <max.krummenacher@toradex.com>
(cherry picked from commit 94fabe4b03e899d8876027ee2ced649737a9e522)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Under some rare circumstances we may end up with GCC segmentation fault.
This was observed with versions of sysmacros.h, which contain macros
with embedded warning messages :
When trying to actually display the warning, we may end up with a segmentation
fault instead. The reason is the actual warning message gets parsed (the text is
unquoted) and words in the message such as "not", "and" etc. are interpreted as
operators CPP_NOT, CPP_AND. When the time comes to display the warning, the code
uses wrong structure to access the "name" corresponding to the operators.
[YOCTO #11738]
(From OE-Core rev: 6f81fe4f3a1177c0049b26a070e43546bc6fe974)
Signed-off-by: Juro Bystricky <juro.bystricky@intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Add a patch to force a native build for a helper binary
(which is not installed or used outside of the build process).
(From OE-Core rev: 35e3ed68fd25941e3d76e5a063299b1d1cee0e70)
Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
In upstream, the following commit:
e711cafab1
...
commit e711cafab13efc9c1fe6c5cd75826401445eb585
Author: Benjamin Peterson <benjamin@python.org>
Date: Wed Jun 11 16:44:04 2008 +0000
Merged revisions 64104,64117 via svnmerge from
svn+ssh://pythondev@svn.python.org/python/trunk
...
(see diff in setup.py)
It assigned libraries for multiprocessing module according
the host_platform, but not pass it to Extension.
In glibc, the following commit caused two definition of
sem_getvalue are different.
https://sourceware.org/git/?p=glibc.git;a=commit;h=042e1521c794a945edc43b5bfa7e69ad70420524
(see diff in nptl/sem_getvalue.c for detail)
`__new_sem_getvalue' is the latest sem_getvalue@@GLIBC_2.1
and `__old_sem_getvalue' is to compat the old version
sem_getvalue@GLIBC_2.0.
If not explicitly link to library pthread (-lpthread), it will
load glibc's sem_getvalue randomly at runtime.
Such as build python on linux x86_64 host and run the python
on linux x86_32 target. If not link library pthread, it caused
multiprocessing bounded semaphore could not work correctly.
...
>>> import multiprocessing
>>> pool_sema = multiprocessing.BoundedSemaphore(value=1)
>>> pool_sema.acquire()
True
>>> pool_sema.release()
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
ValueError: semaphore or lock released too many times
...
And the semaphore issue also caused multiprocessing.Queue().put() hung.
(From OE-Core rev: ca1542cdf6b6437a2f3dcdb33ac5216bf841c04a)
Signed-off-by: Hongxu Jia <hongxu.jia@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This was needed when we were conflicting with clang-native
but this is solved via append PN to binaries of llvm-native
(From OE-Core rev: 82ea78bd2f03b6ba4d720595d3a3fbd96e0232f9)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When parsing this recipe on an unsupported or non-mappable architecture
an error is generated despite no dependencies on the recipe. E.g.
ERROR: .../llvm_git.bb: cannot map 'microblazeel' to a supported llvm architecture
Instead of generating an error which might confuse users, raise a
SkipRecipe exception similar to other arch-style mapping functions (e.g.
go_map_arch). This avoids showing the error during parse, and prevents
the use of the recipe on unsupported targets. Resulting in an error like
so when trying to build llvm:
ERROR: Nothing PROVIDES 'llvm'
llvm was skipped: Cannot map 'microblazeel' to a supported LLVM architecture
(From OE-Core rev: d796abac982f368aa088a291560b565cc47a2c27)
Signed-off-by: Nathan Rossi <nathan@nathanrossi.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We have a variable YOCTO_ALTERNATE_EXE_PATH to point to
target sysroot, utilize this in mesa to use native version
of llvm-config to report values from target sysroot.
(From OE-Core rev: 1c4444f7b2f5cbcaaf6f9d21d7b4f86555ed746a)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Alioth always redirects, so we might as well save time by looking in the right
place.
(From OE-Core rev: e681e25fb8fb97a8592df69180d2fd85d136352c)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This is highlighted when CC is passing flags like -fPIE
which are stripped by libtool when building shared libs
and replaced with -fPIC, this actually results in CC
not matching the CC computed from cmdline created for
compiling and as a result libtool heuristic to compute
tags auotmatically fails.
(From OE-Core rev: 519c34adeb0735f6ff606addd00a7bbe19f4b15c)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Fixes
| /mnt/a/oe/build/tmp/work/corei7-64-bec-linux/python3-pycairo/1.10.0-r2/recipe-sysroot-native/usr/bin/x86_64-bec-linu
x/x86_64-bec-linux-ld: src/cairomodule.c.1.o: relocation R_X86_64_PC32 against symbol `CairoError' can not be used whe
n making a shared object; recompile with -fPIC
(From OE-Core rev: 058b155a66c5f81573379d258250323c72901ff7)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
External compilers will explicitly pass -fPIE -pie flags
unlike internal toolchain which does not use them, so the build
fails with external toolchains because, its passing these
flags to linker when building with -r option and fails to link
| /mnt/a/oe/build/tmp/work/corei7-64-bec-linux/go/1.8.3-r0/recipe-sysroot-native/usr/bin/x86_64-bec-linux/x86_64-bec-linux-ld: -r and -pie may not be used together
(From OE-Core rev: bb89849b5edb05a953586d190826a67ba87c1c5a)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
libtool tries to guess the --tag value based on CC/CXX environment
variables and the compile commandline generated by makefiles. This
heuristics however fails when we construct CC variables in OE
and add security flags to it, especially -fPIE -pie which are added
by external compilers e.g. clang particularly. It fails because
libtool removed PIE flags from compiler cmdline intelligently
if it figures out that its building a library, which means that
the CC variable passed from cmdline does not match with the compiler
cmdline constructed by libtool and we end up with errors like
| arm-bec-linux-musleabi-libtool: compile: unable to infer tagged configuration
| arm-bec-linux-musleabi-libtool: error: specify a tag with '--tag'
This works with internal gcc toolchain because we configure gcc for
PIE when hardening is selected and dont pass -fPIE -pie options explicitly
but this is not an option for clang, and some external gcc toolchains
using older gcc
This patch adds the --tag option to help libtool set correct tags
in packages where it cant get it right via its heuristics
(From OE-Core rev: 0505075ae8d339ba097aebb82b4d0ae62f87c0a9)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Instead of moving aclocal.m4 to acinclude.m4 in a custom do_configure, simply
tell autoreconf not to run aclocal.
(From OE-Core rev: 5cc53ea9347035f96a721ab057a338eded5c5c67)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The Invisible Mirror FTP service is currently down, and FTP is horrible, so
switch to the HTTP mirror.
(From OE-Core rev: f31461f8ea11e82dbe14454a1149d9ec2120404d)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Although 'test' is listed in the python module list
(https://docs.python.org/3/py-modindex.html) it is meant only to be
used 'internally' by folks developing python itself. Per the
documentation:
Note The test package is meant for internal use by Python only. It
is documented for the benefit of the core developers of Python. Any
use of this package outside of Python’s standard library is
discouraged as code mentioned here can change or be removed without
notice between releases of Python.
Per the above it is best not to include this module to discourage
folks who might not head the above warnings. Additionally this module
is one of the largest py modules going, by dropping this unneeded
module from the 'modules' package we can reduce overall image size,
something which is important for many embedded deployments.
The generator scripts as well as the manifests have thus been modified
accordingly, providing a generic mechanism to exclude modules from the
'all modules' package.
(From OE-Core rev: a5bb13a5d7d7a668ca61da6b17884e3b05b95355)
Signed-off-by: Mark Asselstine <mark.asselstine@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The COPYING file specifies pure GPLv3, not GPLv2 & GPLv3, with the
autoconf exception in COPYING.EXCEPTION. OE-core currently has
GPL-3.0-with-GCC-exception for this in meta/conf/licenses.conf, so
this is used here despite the deprecation note for that license
identifier in https://spdx.org/licenses/GPL-3.0-with-autoconf-exception.
(From OE-Core rev: 5849391a1854743af26503db603ad578d8d19e25)
Signed-off-by: Patrick Ohly <patrick.ohly@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Based on recipe from meta-oe and clang recipe from meta-clang
Needed by mesa
Fixes
[YOCTO #11529]
(From OE-Core rev: 8724ef9c53e7804ead9ba0f019369b0e4daada63)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
llvm is using it, therefore move it from meta-oe
(From OE-Core rev: fc3aef67a95a90e9a485c6b0e93db8cdeab5d3ab)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Rather than requiring each user to handle this individually, handle
addto_recipe_sysroot in the core class. As well as preserving the
sysroot directory, this also ensures the stamp is preserved rather
than rerunning the task every time as currently happens.
(From OE-Core rev: bf8b9858d9ccce27173d13938a83d249294cc473)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The COPYING file specifies pure GPLv3, not GPLv2 & GPLv3. There is
also the COPYING.EXCEPTION file with the autotools exception, which
gets ignored here in the recipe to keep it simpler.
All of the explicit dependencies seem unnecessary, and RDEPENDS_${PN}
doesn't do anything for native recipes either, so all of that gets
removed.
It also built fine without the m4 and parallel build workarounds.
There's no need to have a separate .inc file.
(From OE-Core rev: 5002004b891895654cbad53555ee46e2ed188630)
Signed-off-by: Patrick Ohly <patrick.ohly@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Having common macros in OE-core that are needed by autotools based
projects makes sense. For example, tpm2.0-tools in meta-measured
depended on meta-oe only because of autoconf-archive.
This is a verbatim copy of the autoconf-archive recipe in
meta-openembedded rev 1cbd1bc1, with just one change: the patch which
disabled the installation of ax_code_coverage.m4 and
ax_check_enable_debug.m4 and the dependency on gnome-common were
removed.
So now autoconf-archive in OE-core provides them. gnome-common in
meta-oe will be changed to not install them and instead depend on
autoconf-archive.
(From OE-Core rev: 40711432b82fc6efb9e40748532ed68a64fbe628)
Signed-off-by: Patrick Ohly <patrick.ohly@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Put it in goarch.bbclass which all go related recipes inherit.
(From OE-Core rev: 9e899bbc081cb932c1492f6d6802b908d70ef42f)
Signed-off-by: Joe Slater <jslater@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
RPM file signing is enabled with --with-imaevm during configuration.
If enabled, the RPM signing tool rpmsign will call libimaevm.so provided
by the recipe ima-evm-utils.
(From OE-Core rev: 9d7797e4374c111f0dff523fd49354bcc33dc2af)
Signed-off-by: Lans Zhang <jia.zhang@windriver.com>
Signed-off-by: Jia Zhang <lans.zhang2008@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
FTP is inferiour to HTTP is all respects, so use the HTTP URL for the tarball.
(From OE-Core rev: 6a9e38be6e9dcbeff033944f9a3a18e3838af10d)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
