There is no reason to include a path in foo[dirs] if it is also in
foo[cleandirs] (except if it is the last path in foo[dirs]).
(From OE-Core rev: d76a31a37c3b2253a6a8fdffd8581fc88987857d)
Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
There is no reason to include a path in foo[dirs] if it is also in
foo[cleandirs] (except if it is the last path in foo[dirs]).
(From OE-Core rev: 9d2dac56deda5afa4d77c5ddd7e1e8003f6d4725)
Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
There is no reason to include a path in foo[dirs] if it is also in
foo[cleandirs] (except if it is the last path in foo[dirs]).
(From OE-Core rev: a0566610034ca8abdb71eee999460eb90f805f9f)
Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
There is no reason to include a path in foo[dirs] if it is also in
foo[cleandirs] (except if it is the last path in foo[dirs]).
(From OE-Core rev: cb30a6cfa58072bbf5f5def36103fbcac920e168)
Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
There is a key difference between glibc and musl when it comes to
ppc/ppc64 and that is that musl does not support 128-bit long IBM doubles format
it only supports 128-bit long double IEEE format on ppc64 alone.
this change ensures that we account for this change, so far we have been
doing it a bit wrong for ppc/musl case.
(From OE-Core rev: 28cb148c1375ba242addba80b0f68e06d2a4d874)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Add ${IMAGE_ROOTFS} and ${IMGDEPLOYDIR} to do_rootfs[dirs] and
do_rootfs[cleandirs], this ensures do_rootfs run from a clean
workspace, with this change, we can now remove two bb.utils.mkdirhier
lines from meta/lib/oe/rootfs.py.
(From OE-Core rev: cb8b6f7eee4e059bb311330c57068e11bc477366)
Signed-off-by: Ming Liu <liu.ming50@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Now we have the start of a PEP-517 base class, the PEP517_SOURCE_PATH
variable can be defined in there instead of the classes that use it.
(From OE-Core rev: 69944121f49f613568bf0c62ae6b3b47af195dbe)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
pip_install_wheel shouldn't restricted to just using Pip to install
wheels (the installer module is simplier and likely a better option),
and in the future may be extended to also provide do_compile() using
the build module.
(From OE-Core rev: 3bdf64b97facce9706cc579bdbc9a80e0d48428f)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Use :append instead of += so that recipes can assign to RDEPENDS:${PN}.
This fixes missing RDEPENDS for sixteen recipes in oe-core alone.
Also instead of using obscure inline Python we can just use the
class-target override.
(From OE-Core rev: c4ecd63593df2ffd5c1b7ae1c50652ca57ebe219)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Several recipes are duplicating the same bootstrap logic for installing
a wheel without using any tools. Add an implementation to
pip_install_wheel to centralise the code, and remove the duplicated code
from the following recipes:
- python3-flit-core
- python3-pip
- python3-setuptools
- python3-wheel
(From OE-Core rev: d5d702a2cd06f863340f8e4cdce0904c9d86384d)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
PIP is not needed by this class directly, but is used by
pip_install_wheel which already depends on python3-pip-native.
(From OE-Core rev: 2f18b35b8da5dad471c325138be52191412e4100)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The conflict with the `package-managment` only happens if the
`overlayfs-etc` class overwrites `/sbin/init`, which is not the case
when `OVERLAYFS_ETC_USE_ORIG_INIT_NAME` is set to `0`.
(From OE-Core rev: c577382c6d155b3a784d06e4c916783cde7165c8)
Signed-off-by: Claudius Heine <ch@denx.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The 'FILES:${PN}' array is missing the systemd unit dir prefix causing
them to not be packaged and the build fails with the
`installed-vs-shipped` error.
This adds the `systemd_system_unitdir` variable in front of every unit
file added with this class.
(From OE-Core rev: d19166cbc567be0803eaf8d0a2a20f44758aae7b)
Signed-off-by: Claudius Heine <ch@denx.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This updates the QEMU sounds options for x86 emulation,
when "runqemu" is called with the "audio" argument,
to fix the below error:
runqemu - ERROR - Failed to run qemu: qemu-system-x86_64: warning: '-soundhw ac97' is deprecated, please use '-device AC97' instead
(From OE-Core rev: b802a5dd1a79c7be3bc790223a733ebc9be4f117)
Signed-off-by: Michael Opdenacker <michael.opdenacker@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Now that the build systems that use pip_install_wheel are all building
their wheel into a directory that we knew was empty before, we can just
install *.whl and not need to know the precise names.
By design a pyproject.toml will always build a single wheel, so there
shouldn't be any way for this to end up installing more than expected.
This obsoletes PIP_INSTALL_PACKAGE and PYPA_WHEEL, neither of which are
needed anymore.
(From OE-Core rev: e6e4c63bbdd09d91428e55cb5a852170511f05cc)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Set the wheel distribution location, PIP_INSTALL_DIST_PATH, to a
directory under WORKDIR to enhance out-of-tree builds.
(From OE-Core rev: 8e7ae4246aa8dedd8a128c34450d4c1f60e2224a)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
pip_install_wheel expects the wheels to be in PIP_INSTALL_DIST_PATH but
this class was writing to the same directory through chance not design.
Respect PIP_INSTALL_DIST_PATH as the output directory.
(From OE-Core rev: 12857a77ad424c3c3cbc37275374a603e528d9f1)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The PEP517[1] pyproject.toml doesn't have to be located at the top-level
of the source tree (for example, in recipes with multiple components), so
add a variable PEP517_SOURCE_PATH to set where the file is.
In the future there should be a pep517.bbclass to centralise the common
logic, but for now this can be defined in each of the relevant classes.
[1] https://www.python.org/dev/peps/pep-0517/
(From OE-Core rev: 891fab83683cf032d4849f2dfbcd03a3eb22f158)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
pip_install_wheel expects the wheels to be in PIP_INSTALL_DIST_PATH but
this class was writing to the same directory through chance not design.
Respect PIP_INSTALL_DIST_PATH as the output directory, and use
[cleandirs] to ensure that it exists and is empty.
(From OE-Core rev: 1a3625c576afe823efc50dc0b1071e4952339f8e)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The PEP517[1] pyproject.toml doesn't have to be located at the top-level
of the source tree (for example, in recipes with multiple components), so
add a variable PEP517_SOURCE_PATH to set where the file is.
In the future there should be a pep517.bbclass to centralise the common
logic, but for now this can be defined in each of the relevant classes.
[1] https://www.python.org/dev/peps/pep-0517/
(From OE-Core rev: f85b512e2ad39ec32f11f9b25b8c92bea20c844d)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
pip_install_wheel expects the wheels to be in PIP_INSTALL_DIST_PATH but
this class was writing to the same directory through chance not design.
Respect PIP_INSTALL_DIST_PATH as the output directory, and use
[cleandirs] to ensure that it exists and is empty.
Also call the flit_core.wheel module directly as this is a public entry
point to the wheel building logic.
(From OE-Core rev: a3d9eb8051bc2effb8130b1743ba251c1fe7c525)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Make do_configure do nothing by default as the base configure isn't
useful, and invoke the build API directly instead of writing a script.
In the future, this can simply call python3-build.
(From OE-Core rev: ccad9d0218ef69bdb8c708029445fcd661f1c490)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Make do_configure do nothing by default as the base configure isn't
useful, and invoke the build API directly instead of writing a script.
In the future, this can simply call python3-build.
(From OE-Core rev: 2d80529a486d25ad96c448499392547e82779de4)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If we expect users to extend this we should use =, as otherwise a recipe
that does += will replace the default value.
(From OE-Core rev: fdaf5e0027a52e44f2def0ef240134763660aa00)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
There's been a lot of work in this class lately, so a little spring
cleaning is needed.
Remove redundant creation of PYTHON_SITEPACKAGES_DIR, pip will do that.
Remove redundant export of PYPA_WHEEL.
Simplyify recompile code using "realpath --relative-to".
(From OE-Core rev: cb56166eef34ba4937dc487664c57815daeadbe8)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
There's been a lot of work in this class lately, so a little spring
cleaning is needed.
Create wheels verbosely to help debug problems.
Remove unused SETUPTOOLS_INSTALL_ARGS, these can't be passed to
bdist_wheel.
Remove duplicate manipulation of files in bindir as pip_install_wheel
does the same.
Remove obsolete deletion of easy-install.pth, wheels don't generate that.
Remove obsolete ${datadir}/share fixup, pip-installed wheels can't
generate that path combination.
Remove purging of ${D} references from *.py, these won't be written by
standard setuptools, and recipes can do it themselves to work around
specific issues if needed.
Remove obsolete vardepsexclude of MACHINE on do_install, as that variable
isn't referenced.
(From OE-Core rev: 57c477ca13e352b6f9b21385abbfaad9778c6398)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When inside the threadedpool we make a copy of the localdata
to avoid some race condition, so we need to use this new
localdata2 and stop write the shared localdata.
(From OE-Core rev: 1fa763b2022822a76fde541724e83e1977833d03)
Signed-off-by: Jose Quaresma <quaresma.jose@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
when building additional native python tools that should be used
for additional tasks in python3 package (class-target), the dependency
on target class python creates a dependency loop:
python3-foo-native_1.2.3.bb:do_prepare_recipe_sysroot
python3-pep8-native_1.7.1.bb:do_populate_sysroot
python3-wheel_0.37.1.bb:do_populate_sysroot
python3-bar-native_0.1.2.bb:do_populate_sysroot
python3-pip_22.0.3.bb:do_populate_sysroot
python3-pyflakes-native_2.4.0.bb:do_populate_sysroot
python3_3.10.2.bb:do_populate_sysroot
python3-foo-native_1.2.3_1.2.0.bb:do_fetch
python3-setuptools_59.5.0.bb:do_populate_sysroot
resolve this by removing python3 from DEPENDS.
The correct dependencies are already injected by
setuptools-base class
(From OE-Core rev: bd9f9a369160164beade2c12f344b7f5c2b18427)
Signed-off-by: Konrad Weihmann <kweihmann@outlook.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Following a good discussion with PyPA upstream[1] the migration of the
setuptools3.bbclass to use bdist_wheel+pip turns out to be more complex
than thought.
Essentially, we're midway through a lot of changes: the future of Python
packaging is wheels and pip, but those by design are not as flexible as
traditional distutils and setup.py.
Specifically, with traditional distutils the package can implement its
own install task and write arbitrary files (such as init scripts). With
wheels this is explicity impossible, so packages that do this cannot use
the new setuptools class and must continue to use the build/install tasks
as before.
This class is the old setuptools behaviour, bought back. However, as
distutils and the setuptools install task are both deprecated and will
soon be removed entirely, any users of this class should be moving to an
alternative build tool, be it a modern Python tool which works with
wheels, or a non-Pythonic tool such as Meson.
[1] https://github.com/pypa/packaging-problems/issues/576
(From OE-Core rev: 341d2b35986e48e4954c591be8bc037a5557452a)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
llvm-objdump emite MIPS_XHASH where as GNU objdump emits DT_MIPS_XHASH,
checking for shorted sequence makes this check work in both cases
mips-yoe-linux-objdump -p libx264.so.163 | grep XHASH
DT_MIPS_XHASH 0x00000168
mips-yoe-linux-llvm-objdump -p libx264.so.163 | grep XHASH
MIPS_XHASH 0x00000168
both are same things
(From OE-Core rev: 45390aee03ad0adfcabf6d96109e73136436acad)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This reverts commit 47594d59ec.
This patch was introduced 5 years ago as a temporary workaround
to fix an upstream bug.
Currently with that patch the following flags are duplicated:
OECMAKE_C_FLAGS ?= "${HOST_CC_ARCH} ${TOOLCHAIN_OPTIONS} ${CFLAGS}"
OECMAKE_C_LINK_FLAGS ?= "${HOST_CC_ARCH} ${TOOLCHAIN_OPTIONS} ${CPPFLAGS} ${LDFLAGS}"
OECMAKE_CXX_LINK_FLAGS ?= "${HOST_CC_ARCH} ${TOOLCHAIN_OPTIONS} ${CXXFLAGS} ${LDFLAGS}"
The duplicated flags is used in the toolchain.cmake:
set( CMAKE_C_FLAGS "${OECMAKE_C_FLAGS}" CACHE STRING "CFLAGS" )
set( CMAKE_CXX_FLAGS "${OECMAKE_CXX_FLAGS}" CACHE STRING "CXXFLAGS" )
set( CMAKE_CXX_LINK_FLAGS "${OECMAKE_CXX_LINK_FLAGS}" CACHE STRING "LDFLAGS" )
CC: Khem Raj <raj.khem@gmail.com>
(From OE-Core rev: a83623a54a375d3ae9198a135b94379881a2b7a5)
Signed-off-by: Jose Quaresma <quaresma.jose@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The systemd init manager support mount point configuration via mount
units and /etc/fstab. 'Mounts listed in /etc/fstab will be converted
into native units dynamically at boot and when the configuration of
the system manager is reloaded. In general, configuring mount points
through /etc/fstab is the preferred approach.' [1]
Read mount points from /etc/fstab to determine dynamic mount units.
[1] https://www.freedesktop.org/software/systemd/man/systemd.mount.html
(From OE-Core rev: 9db988dae6dbf6da7b066728bc13b59a5c45b75c)
Signed-off-by: Stefan Herbrechtsmeier <stefan.herbrechtsmeier@weidmueller.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Currently the TRANSLATED_TARGET_ARCH is not changed when trying
to set preferred version for canadian recipes.
e.g.
```
bitbake core-image-minimal -c populate_sdk -e > env
grep ^PREFERRED_VERSION_gcc-cross-canadian env
```
The result is:
"""
PREFERRED_VERSION_gcc-cross-canadian-x86-64="11.%"
"""
We need to explictly change DEFAULTTUNE to ensure TRANSLATED_TARGET_ARCH is
changed when trying to set the preferred version for multilib version of
the canadian recipes.
e.g.
```
bitbake core-image-minimal -c populate_sdk -e > env
grep ^PREFERRED_VERSION_gcc-cross-canadian env
```
The result is:
"""
PREFERRED_VERSION_gcc-cross-canadian-i686="11.%"
PREFERRED_VERSION_gcc-cross-canadian-x86-64="11.%"
"""
(From OE-Core rev: ab8ed74082ffaf3b3adca84f4c41465f89657e76)
Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
RUST_BUILD_ARCH contains the arch_to_rust_arch()-translated value of
BUILD_ARCH. This is necessary to acquire the correct snapshot artifacts
under Linux where `uname -m` reports "ppc64le" rather than
"powerpc64le".
Change-Id: I6aec23aced8e1c6f0bfc46fe52531b0c16bcf687
(From OE-Core rev: c13afbade8d480807b9de70c56dcd650496f06b2)
Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
On modern Power systems `uname -m` yields 'ppc64le' while the toolchain
knows the architecture as 'powerpc64le'. Provide a mapping from one to
the other to integrate with the existing architecture configuration
flags.
arch_to_rust_arch() only exists to map the OE *_ARCH variables before
any further processing, unlike arch_to_rust_target_arch() which is
specific to the internal triple handling of rust.
On Linux ppc64le systems the changes give the following config:
```
$ cat ./tmp/work/ppc64le-linux/rust-native/1.58.0-r0/targets/ppc64le-linux.json
{
"llvm-target": "powerpc64le-unknown-linux-gnu",
"data-layout": "e-m:e-i64:64-n32:64-v256:256:256-v512:512:512",
"max-atomic-width": 64,
"target-pointer-width": "64",
"target-c-int-width": "64",
"target-endian": "little",
"arch": "powerpc64",
"os": "linux",
"env": "gnu",
"vendor": "unknown",
"target-family": "unix",
"linker": "gcc",
"cpu": "generic",
"dynamic-linking": true,
"executables": true,
"linker-is-gnu": true,
"linker-flavor": "gcc",
"has-rpath": true,
"has-elf-tls": true,
"position-independent-executables": true,
"panic-strategy": "unwind"
}
```
Change-Id: Ief0c01189185d7d4da31d307270bec4e1de674ca
(From OE-Core rev: 9ab61e3cfef0157393cb870d606c2f362e190889)
Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When the BUILDHISTORY_RESET is enabled we need to move the
content from BUILDHISTORY_DIR to BUILDHISTORY_OLD_DIR but
when we start a clean build in the first run we don't have the
BUILDHISTORY_DIR so the move of files will fail.
| ERROR: Command execution failed: Traceback (most recent call last):
| File "/xxx/poky/bitbake/lib/bb/command.py", line 110, in runAsyncCommand
| commandmethod(self.cmds_async, self, options)
| File "/xxx/poky/bitbake/lib/bb/command.py", line 564, in buildTargets
| command.cooker.buildTargets(pkgs_to_build, task)
| File "/xxx/poky/bitbake/lib/bb/cooker.py", line 1481, in buildTargets
| bb.event.fire(bb.event.BuildStarted(buildname, ntargets), self.databuilder.mcdata[mc])
| File "/xxx/home/builder/src/base/poky/bitbake/lib/bb/event.py", line 214, in fire
| fire_class_handlers(event, d)
| File "/xxx/poky/bitbake/lib/bb/event.py", line 121, in fire_class_handlers
| execute_handler(name, handler, event, d)
| File "/xxx/poky/bitbake/lib/bb/event.py", line 93, in execute_handler
| ret = handler(event)
| File "/xxx/poky/meta/classes/buildhistory.bbclass", line 919, in buildhistory_eventhandler
| entries = [ x for x in os.listdir(rootdir) if not x.startswith('.') ]
| FileNotFoundError: [Errno 2] No such file or directory: '/xxx/buildhistory'
(From OE-Core rev: 97bc2168da7dbacdfbf79cd70db674363ab84f6b)
Signed-off-by: Jose Quaresma <quaresma.jose@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Currently when adding a user to a group ('m' type), the conditional
check to only create a user/group if it does not exist always resolves
to true. This causes a build exit failure if the user and/or group
defined in the sysusers configuration file were already created prior to
the execution of systemd_create_users().
This logic has been updated to instead fail silently (consistent with
'u' and 'g' type). Additionally, if a user doesn't exist it will be
created without the default group.
(From OE-Core rev: 65649be6b2196ab964c69605d0306bfc2481da33)
Signed-off-by: Tean Cunningham <tean.cunningham@digi.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The current wildcard handling is badly documented and inconsistently
used and understood.
Forcing users to have to use "GPL-3.0-only GPL-3.0-or-later" whilst
explict is not very user friendly. Equally, using the current wildcards
is ambigious. This supports pre-defined expansions only and at least makes
it clear what GPL-3.0* means (it doesn't include the exception licenses).
This is hopefully an acceptable compromise between literal meaning and
having something usable.
Non-SPDX forms of license in this field have been dropped and errors are
shown for unsupported expansions and unsupported old style license terms.
Users need to carefully consider how to migrate to the new syntax but
the meaning should be well defined and clear from here forward.
(From OE-Core rev: 724fc8047cae6ed6197d7deca887b1594871c90e)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We want to use SPDX identifiers in LICENSE variables. There is now a
conversion script to make most of the translations. Add a list of
strings which have been replaced so we can show warnings to users
if they're still used anywhere.
Add checks to the package as insane check. This is currently a warning
by default but can be turned off or made an error as per the other standard
checks.
(From OE-Core rev: 9379f80f484f94686a4d494e9e237fadfb72a938)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This re-writes the INCOMPATIBLE_LICENSE checking code to replace
the WHITELIST_<lic> with
INCOMPATIBLE_LICENSE_EXCEPTIONS = '<pkg>:<lic> <pkg>:<lic> ...'
This initial change leaves most of the code structure in place,
but the code in base.bbclass needs to be re-written to make
the check more consistent around packages (PKGS) and not recipe
names (PN). This also is taking into account the changes for SPDX
licenses.
The aim is to provide a mode consistent variable where the variable
name is known and can easily be queried.
(From OE-Core rev: 0d19c45ba6cf43518f380ca5afe9753a2eda0691)
Signed-off-by: Saul Wold <saul.wold@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
- replace python3 prefix when guessing the wheel name
as there are still plenty of recipes out there that do use
python3 prefixes
- remove all previously generated wheels matching the glob
to avoid installing any outdated blob via cleandirs
in setuptools3 class.
Unfortunetaly proposed dist-dir or bdist-dir are not
respected by setuptools, likely due because they
are overridable by the setup script
- don't use PV in glob, as PV doesn't necessarily align with the
version used inside of the setuptools configuration.
this will avoid having the user set PYPA_WHEEL in a lot
of recipes
- respect SETUPTOOLS_SETUP_PATH in PIP_INSTALL_DIST_PATH
and use B as a fallback only (in case this class is inherited
without setuptools3 class being there as well).
recipes like python3-smbus run in a subfolder of the
workspace and were failing in before this adjustment
(From OE-Core rev: 6f2d85a7b7d94101f2ce67115166fa86c185650f)
Signed-off-by: Konrad Weihmann <kweihmann@outlook.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The class should export the tasks so they can be extended or overriden
elsewhere (like what setuptools3.bbclass has).
(From OE-Core rev: 14c2dcbebccf072225a089518ffeb010401f479c)
Signed-off-by: Tim Orling <tim.orling@konsulko.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This is redundant (target arch is already in PN), and breaks
compiling a cross-canadian toolchain, as that needs populating the
sysroot with two different native-hosted toolchains built from
cross recipes. Inserting TARGET_ARCH allows only one or the other.
(From OE-Core rev: 33fc1792cd782feb8dbb4285e3006bb588f7978f)
Signed-off-by: Alexander Kanavin <alex@linutronix.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The icecc.bbclass needs network access to work properly.
Currently I build with icecc inside a container with network isolation and
my icecc daemon runs outside of the build container in my host.
The only thing I need to do for using the icecc inside my build container is
mounting the unix socket /var/run/icecc/iceccd.socket inside the container.
I think we need something like this mount functionality to have access to
some sockets connections inside the tasks that runs on the new namespace
created with unshare system call.
This patch is not a the real solution for the problem and is more like
an hack so we can use the icecc.bbclass again.
(From OE-Core rev: 25ea276a13a6ac2342c2b0945c8fafe878d56095)
Signed-off-by: Jose Quaresma <quaresma.jose@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
hashlib.md5() is not permitted on a FIPS enabled host system. This is due
to md5 not being an approved hash algorithm.
Instead use:
hashlib.new('MD5', usedforsecurity=False)
This is allowed, as it's clear the hash is used for a non-security purpose.
Using an md5 to identify when a license has changed is permitted, as we're
not using it for file integrity.
(From OE-Core rev: 7f7eb82ce47ede6ec6f50cbcb56cbfbe10e8d20c)
Signed-off-by: Mark Hatle <mark.hatle@xilinx.com>
Signed-off-by: Mark Hatle <mark.hatle@kernel.crashing.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
In commit ceda3238 (meta/meta-selftest/meta-skeleton: Update LICENSE
variable to use SPDX license identifiers) all LICENSE variables were
updated to only use SPDX license identifiers.
This does the same for comments and other variables where it is
appropriate to use the official SPDX license identifiers. There are
still references to, e.g., "GPLv3", but they are then typically in
descriptive text where they refer to the license in a generic sense.
(From OE-Core rev: 165759dced7fbe73b1db2ede67047896071dc6d0)
Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The code doesn't work if the variable is unset, fix that.
(From OE-Core rev: b5248cc232629b021d8934899326468c3ef46351)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
