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>
Layers could be located anywhere. The eSDK should work with them even if
they are not located in TOPDIR or in the same parent directory as
COREBASE.
For layers located in the same parent directory as COREBASE this preserves
the intent from the previous
copy_buildsystem: include layer tree during build structure creation
commit.
Related OE-Core rev: 5a59a6997f41e606d088e3e86812de56f72f543b
(From OE-Core rev: 16d330d42e03085769eddb1b60ba1df7228baf36)
Signed-off-by: Daniel Wagenknecht <dwagenknecht@emlix.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Fixing documentation and updating examples containing "prelink"
in their output.
(From yocto-docs rev: 8927b8fff55fac1bd1fefcff2d16141dbd1ebc51)
Signed-off-by: Michael Opdenacker <michael.opdenacker@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
mkpasswd output requires to be escaped before being used as password in
a Bitbake variable. It was explicitly stated after the command, but to
be sure it's not missed, let's give the printf command which does escape
the string for us.
Cc: Quentin Schulz <foss+yocto@0leil.net>
(From yocto-docs rev: 13064e7bea18e999d4a294e298a7980a4dcbe69e)
Signed-off-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
Reviewed-by: Michael Opdenacker <michael.opdenacker@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Add the new variables used to install Python `wheel` binary archives:
* PIP_INSTALL_ARGS
* PIP_INSTALL_DIST_PATH
* PIP_INSTALL_PACKAGE
* PYPA_WHEEL
(From yocto-docs rev: cb213b5682e37873ac0ec457d6f5a52639c4b24a)
Signed-off-by: Tim Orling <tim.orling@konsulko.com>
Reviewed-by: Michael Opdenacker <michael.opdenacker@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Add the new classes used for Python packaging:
* flit_core
* pip_install_wheel
* setuptools_build_meta
(From yocto-docs rev: f78fe71f634cbf39857c42e90f8c16e511ba2076)
Signed-off-by: Tim Orling <tim.orling@konsulko.com>
Reviewed-by: Michael Opdenacker <michael.opdenacker@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The distutils* classes and DISUTILS* terms are no longer defined so
replace their usage with ``text``.
(From yocto-docs rev: c0e0e0b9416cb7a2fed3efe9d32ee905b6391f24)
Signed-off-by: Tim Orling <tim.orling@konsulko.com>
Reviewed-by: Michael Opdenacker <michael.opdenacker@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The distutils* classes and DISUTILS* terms are no longer defined so
replace their usage with ``text``.
(From yocto-docs rev: 6be0ab803e6dd64e4a044b7c605acfdd45caa280)
Signed-off-by: Tim Orling <tim.orling@konsulko.com>
Reviewed-by: Michael Opdenacker <michael.opdenacker@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The distutils*.bbclasses have been removed from oe-core and moved to
meta-python, so remove them from ref-manual/classes.rst.
(From yocto-docs rev: 9da8fd7d436ac3eb3b66409cf0e53218d6e41822)
Signed-off-by: Tim Orling <tim.orling@konsulko.com>
Reviewed-by: Michael Opdenacker <michael.opdenacker@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The distutils*.bbclasses have been moved to meta-python, so remove
mention of them from ref-manual/variables.rst
(From yocto-docs rev: af3d465c5d50edd27957c205dd26aae6843ee3b2)
Signed-off-by: Tim Orling <tim.orling@konsulko.com>
Reviewed-by: Michael Opdenacker <michael.opdenacker@bootlin.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>
Version 3.7.1
* Fix building packages which need execution to get the version number,
and have a relative import in __init__.py (:ghpull:`531`).
Version 3.7
* Support for :ref:`external data files <pyproject_toml_external_data>`
such as man pages or Jupyter extension support files (:ghpull:`510`).
* Project names are now lowercase in wheel filenames and .dist-info folder
names, in line with the specifications (:ghpull:`498`).
* Improved support for :doc:`bootstrapping <bootstrap>` a Python environment,
e.g. for downstream packagers (:ghpull:`511`). flit_core.wheel is usable
with python -m to create wheels before the build tool is available, and
flit_core sdists also include a script to install itself from a wheel
before installer is available.
* Use newer importlib APIs, fixing some deprecation warnings (:ghpull:`499`).
(From OE-Core rev: 3f6768cf23e4215d99f7279b8ec6ee73ba00a656)
Signed-off-by: Tim Orling <tim.orling@konsulko.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Drop the setup.py workaround as it is no longer needed.
(From OE-Core rev: 88fc6ec6859e5aa1b97125fd7b692569665875f6)
Signed-off-by: Tim Orling <tim.orling@konsulko.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Some of these are hard to know what to do with since the original source
files for the checksum aren't present. The safe option is to use "-only"
as often the main license is ambiguous and the source files themselves
determine the "or-later" possibility. The "-only" option therefore is
realistically what we need to use in this code.
(From OE-Core rev: 2b0cbafc7854de0308a624b17b8aaba704b031d5)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The configure checks /etc/dbus-1 and set DBUSDIR is null:
if test -d /etc/dbus-1 -a "x$DBUSDIR" = x; then
DBUSDIR="/etc/dbus-1"
fi
So that the build resutl would be different w/o /etc/dbus-1:
/etc/dbus-1/system.d/cups.conf (Only exists when DBUSDIR is set)
Add --with-dbusdir to EXTRA_OECONF to fix the issue
(From OE-Core rev: 0e4b2464138601c4c20882c001ef11eef5100395)
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Otherwise, the build results would be different w/o host's /usr/sbin/sendmail:
1) The /usr/share/quilt/compat/sendmail will be genrated if no
/usr/sbin/sendmail on host
2) No /usr/share/quilt/compat/sendmail if host's has /usr/sbin/sendmail
Use --without-sendmail to make it always generate /usr/share/quilt/compat/sendmail.
(From OE-Core rev: 3f9320816ac9f9ec8815754d1951cecb58612f70)
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
It checks host's path such as /dev/log and uses it, this doesn't make sense for
cross build, and it causes undeterministic, for example, the contianer os
usually doesn't have /dev/log which leads to a different build result since
other host usually has /dev/log, so make it always use the default value to fix
the issue.
(From OE-Core rev: 977b493e5040db8e000c6565bb29f3ac260ca0e1)
Signed-off-by: Robert Yang <liezhi.yang@windriver.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>
Among other things, fix misspellings of:
- absolute
- deprecated
- suitable
- handle
and a bunch of other things.
(From OE-Core rev: c3773cd6c44dfe82be9ecd248120e7d6c753f891)
Signed-off-by: Robert P. J. Day <rpjday@crashcourse.ca>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The statx requires glibc >= 2.28 and linux kernel >= 4.11, but coreutils's
configure only checks glibc compatibility for statx syscall but fail to check
kernel support, e.g.:
RedHat Enterprise Linux Server 7.6 (Maipo)
Host kernel: 3.10.0-1127.8.2.el7.x86_64
Docker OS: Ubuntu 20.04.1 LTS
$ bitbake coreutils-native
find the binary ls and run it as "ls -l ."
The result is something like: "?????????. ? ? ? ? ? foo"
This is because glibc is 2.31 (Ubunut 20.04 in docker) which has statx,
but host's kernel is 3.10.0 (CentOS 7) which doesn't support statx.
Disable statx for native build to fix the problem.
Original from: Davi Poyastro <davi.poyastro@nokia.com>
(From OE-Core rev: 6c120d8856fab044e7b8e09d6de91c2b228a2dd9)
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
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>
Changelog:
=========
* sar/sadf: Make sure that datafiles with unknown activities can
be read by sar and sadf.
* sar/sadf: Don't reallocate buffers for activities not present
in file.
* sar: Make sure that all buffers are copied in copy_structures()
function.
(From OE-Core rev: 7ec2ed62ea64e5a3652b436e7772216159ae4466)
Signed-off-by: Wang Mingyu <wangmy@fujitsu.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
