Integrating the following commit(s) to linux-yocto/.:
7a012dfacdc features/zram: remove CONFIG_ZRAM_DEF_COMP
(From OE-Core rev: a8fcece853475bede5d442120bc38f17751ed9a1)
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Integrating the following commit(s) to linux-yocto:
commit e1b976ee4fb5af517cf01a9f2dd4a32f560ca894
Author: Bruce Ashfield <bruce.ashfield@gmail.com>
Date: Tue Feb 15 23:27:31 2022 -0500
riscv64: drop MAXPHYSMEM_128GB
The MAXPHYSMEM config options have been removed upstream via the
following commit, so we drop our setting.
commit 6250ecf5ba42292b652cd01c9fcb2239010c5c44
Author: Alexandre Ghiti <alexandre.ghiti@canonical.com>
Date: Mon Jan 17 10:57:16 2022 +0100
riscv: Get rid of MAXPHYSMEM configs
commit db1503d355a79d1d4255a9996f20e72848b74a56 upstream.
CONFIG_MAXPHYSMEM_* are actually never used, even the nommu defconfigs
selecting the MAXPHYSMEM_2GB had no effects on PAGE_OFFSET since it was
preempted by !MMU case right before.
In addition, the move of the kernel mapping at the end of the address
space broke the use of MAXPHYSMEM_2G with MMU since it defines PAGE_OFFSET
at the same address as the kernel mapping.
Reported-by: Geert Uytterhoeven <geert@linux-m68k.org>
Fixes: 2bfc6cd81bd1 ("riscv: Move kernel mapping outside of linear mapping")
Signed-off-by: Alexandre Ghiti <alexandre.ghiti@canonical.com>
Tested-by: Geert Uytterhoeven <geert@linux-m68k.org>
Tested-by: Conor Dooley <Conor.Dooley@microchip.com>
Cc: stable@vger.kernel.org
Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(From OE-Core rev: da19366b44af8521b0f311581793fc89d554cd40)
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
inherit setuptools_build_meta
v4.11.2
369: Fixed bug where EntryPoint.extras was returning match objects and not the extras strings.
v4.11.1
367: In Distribution.requires for egg-info, if requires.txt is empty, return an empty list.
v4.11.0
bpo-46246: Added __slots__ to EntryPoints.
v4.10.2
365 and bpo-46546: Avoid leaking method_name in DeprecatedList.
(From OE-Core rev: 16873202f4fc9409b3b853ad2275c1068eb16ecd)
Signed-off-by: Tim Orling <tim.orling@konsulko.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
setuptools3 pulls this in, so there's no need to explicitly inherit it.
(From OE-Core rev: 24446a8a7b1b16c5afe3a9878a99cce04dfba2f4)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The only thing which needs perlcross-native will depend upon it directly
so we can optimise this out everywhere else for small space/speed gains.
(From OE-Core rev: 3b86109a2571be39f9cfa85bd4db22f4df025ab2)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The asciidoc-py3 repository has been renamed to asciidoc-py.
(From OE-Core rev: f78dd3f4c5f0cd738783e75f3796e1da2a2a2ba1)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Only libuuid is needed by python so reduce the dependency and hence
reduce the amount pulled into the syroot for the native case in particular.
(From OE-Core rev: 35246dec1c9690371ef0656b21f18567772dab2e)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Currently, libarchive-native pulls e2fsprogs and all it's dependencies into
the sysroot. Since only headers are needed at buildtime and there is no
runtime dependency, we can avoid this and shrink the native sysroots.
(From OE-Core rev: 66a6b2080e4a65632c5dc02c8ef0cbe01d5b5082)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Where a recipe has depends on native docs tools, in most cases
we don't need recipes that depend on that recipe to also install
these things into the sysroot. We can rely on recipes wanting these
tools to have direct dependencies instead.
This massively reduced dependency creep in simple recipes (e.g. an
allarch one) and reduced the size of builds with the api-documentation
feature substancially.
gperf-native is also included since that would normally have a direct
dependency in a recipe which needs it too.
(From OE-Core rev: 9bbb5334e1d1884e042dc3b3ec0eb274664f2c25)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This reverts commit feb8893e0f52c7ab2d5efd456901a2bb91839d44.
This is no longer needed after the compiler fix for libical.
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>
This reverts commit 1b114fa2d221c9810852526f8b45a3d2c856a502.
Unfortunately this breaks on cento7 as libunwind-native doesn't appear to build there.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This fixes this CMake configuration error:
| -- Checking for one of the modules 'libunwind'
| CMake Error at [...]/build/tmp/work/x86_64-linux/libsdl2-native/2.0.20-r0/recipe-sysroot-native/usr/share/cmake-3.22/Modules/FindPkgConfig.cmake:890 (message):
| None of the required 'libunwind' found
| Call Stack (most recent call first):
| CMakeLists.txt:1367 (pkg_search_module)
This error happens even if libunwind is installed complete with its C
headers and development .so files (in Ubuntu, this means libunwind-dev
is installed).
(From OE-Core rev: 1b114fa2d221c9810852526f8b45a3d2c856a502)
Signed-off-by: Carlos Rafael Giani <crg7475@mailbox.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
0001-btrfs-progs-kerncompat-add-local-definition-for-alig.patch
removed since it's included in 5.16.2
Changelog:
=========
mkfs: fix detection of profile type for zoned mode when creating DUP
build:
- add missing stub for zoned mode helper when zoned mode not enabled
- fix 64bit types on MIPS and PowerPC
- improved zoned mode support autodetection, for systems with existing blkzone.h
header but missing support for zone capacity
other: doc updates, test updates
(From OE-Core rev: ec04580374ed6cc26471a338f84794f41931eca1)
Signed-off-by: Wang Mingyu <wangmy@fujitsu.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>
These are only used with python when the -O or -OO options are passed
and I'm not aware of runtime use of that. They otherwise just waste a
ton of space.
(From OE-Core rev: 5ac7b8c030daf30b2be93abebfedbc36c395e6d7)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This removes a further 1600 files from sstate handling and lets python
create the ones it wants at runtime which is likely much better overall
for performance.
(From OE-Core rev: 2d6490fa23cce58922a1b54f87c8369925ff8f90)
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>
This ensures that right sysroot is used during build, otherwise we see
warnings in build about using wrong sysroot and it fails explicitly with
clang
x86_64-yoe-linux-ld: warning: library search path "/usr/lib/gcc/x86_6
4-pc-linux-gnu/11.2.0/../../../../lib64" is unsafe for cross-compilation
x86_64-yoe-linux-ld: cannot find /usr/lib/clang/14.0.0/lib/linux/libc
lang_rt.builtins-x86_64.a: No such file or directory
(From OE-Core rev: e591b462227ded84f3f8e7273200824ad63313c4)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This ensures that right sysroot is used during build, otherwise we see
warnings in build about using wrong sysroot and it fails explicitly with
clang
x86_64-yoe-linux-ld: warning: library search path "/usr/lib/gcc/x86_6
4-pc-linux-gnu/11.2.0/../../../../lib64" is unsafe for cross-compilation
x86_64-yoe-linux-ld: cannot find /usr/lib/clang/14.0.0/lib/linux/libc
lang_rt.builtins-x86_64.a: No such file or directory
(From OE-Core rev: feb8893e0f52c7ab2d5efd456901a2bb91839d44)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This drops the file count for cmake-native from ~3000 to ~1700
which is a decent chunk of files not to be copying to each native
sysroot for no reason.
(From OE-Core rev: 6e561619a2a2b688735deae968eb66027fd4b9f0)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
There are over 3,000 of these in python3-native (of 8,000+ files total) and
copying them to sysroots all the time seems pointless, particularly since
they're only used if python is run with the -O or -OO parameters.
Get rid of them and save the overhead. This is particularly pronounced in
builds using the api-documentation distro feature.
(From OE-Core rev: fd66de439273b245c1d0bcfb32f2c847e3cddd6b)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The recent upgrade regressed codec support since opus is missing and
this caused several codecs to be disabled. Add a patch to work around
the issue whilst it is discussed with upstream.
(From OE-Core rev: d1aba25b2559041c96735b58424baf8862796095)
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>
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>
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>
