crtsavres need to be available for scripts to be regenerated
in 6.12+:
commit 699d53f04829d6b8855ff458f86e4b75ef3e5f0c
Author: Christophe Leroy <christophe.leroy@csgroup.eu>
Date: Thu Sep 19 20:55:57 2024 +0200
powerpc/vdso32: Fix use of crtsavres for PPC64
(From OE-Core rev: ecf72da891ebb08807a694967caccb51805813f2)
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Add a check for a SECURITY.md file (or similar) to yocto-check-layer, as
knowing where to report security issues is important.
(From OE-Core rev: c7cb22ac4ceed60f88452e83c907a4c4f33660e4)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
While two projects share one sstate cache, the 1st project builds kernel-devsrc without
setting SPDX_INCLUDE_SOURCES, and 2nd project build kernel-devsrc with setting
SPDX_INCLUDE_SOURCES = "1". Then the 2nd build failed with kernel-source not found
1. In 1st build
$ cd path-to-first-build
$ bitbake kernel-devsrc
2. In 2nd build, share sstate cache of 1st build and SPDX_INCLUDE_SOURCES = "1"
$ cd path-to-second-build
$ echo 'SSTATE_DIR = "path-to-first-build/sstate-cache"' >> conf/local.conf
$ echo 'SPDX_INCLUDE_SOURCES = "1"' >> conf/local.conf
$ bitbake kernel-devsrc
...
NOTE: copyhardlinktree path-to-second-build/tmp-glibc/work-shared/axxiaarm64/kernel-source to path-to-second-build/tmp-glibc/work/axxiaarm64-wrs-linux/kernel-devsrc/1.0/spdx/3.0.1/work/kernel-source
ERROR: Error executing a python function in exec_func_python() autogenerated:
...
0208: bb.note(f"copyhardlinktree {share_src} to {src_dir}")
*** 0209: oe.path.copyhardlinktree(share_src, src_dir)
...
tar: path-to-second-build/tmp-glibc/work-shared/axxiaarm64/kernel-source: Cannot open: No such file or directory
...
The recipe kernel-devsrc or the recipe to inherit kernelsrc.bbclass, they do not
have task do_shared_workdir but depends on virtual/kernel:do_shared_workdir.
In this situation(the ${S} == ${STAGING_KERNEL_DIR}), explicitly make do_create_spdx
depends on virtual/kernel:do_shared_workdir could fix the racing issue
(From OE-Core rev: b05ff49de1e58f5696e8ee28fceaf9319be70e1f)
Signed-off-by: Hongxu Jia <hongxu.jia@windriver.com>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
I noticed a typo while looking at the file. It doesn't change a value but
worth fixing since I spotted it.
(From OE-Core rev: 84b407ca5542a6fa828c4b0c62ff60964db73901)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We've seen cases where a ptest (strace) has a 43GB sparse file in the test
directory. busybox tar doesn't work well with this. The resulting 1.4GB archive
takes hours to extract too.
Ensure tar is added to our full images and use the sparse option to collect
files for debugging. This stops crazy build hangs.
Since tar is GPLv3, we have to exclude it from that test code. We don't boot
any of those images so the debug collection code is safe there, at least for now.
(From OE-Core rev: fefeb919696b6ac76f0997acfb0f612203ef7f1b)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We remove this file in the python_pep517 class now, so we don't need to
do it here.
(From OE-Core rev: 717b9e08d6a19ee31a217ceeb255aaed6a395de4)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
TL;DR version:
with this, and the previous compression level changes
I am seeing drastic speedups in package_write_rpm completion times:
webkitgtk goes from 78 seconds to 37 seconds
glibc-locale goes from 399 seconds to 58 seconds (!)
The long version:
rpm uses multithreading for two purposes:
- spawning compressors (which are nowadays themselves
multi-threaded, so the feature is not as useful as it once
was)
- parallel file classification
While the former behaves well on massively parallel CPUs
(it was written and verified here :), the latter was then added
by upstream and only benchmarked on their very old, slow laptop,
apparently:
41f0e214f2
On anything more capable it starts showing pathologic behavior,
presumably from spawning massive amount of very short-lived threads,
and then having to synchronize them. For example classifying glibc-locale
takes
5m20s with 256 threads (default on my machine!)
1m49s with 64 threads
59s with 16 threads
48s with 8 threads
Even a more typical recipe like webkitgtk is affected:
47s with 256 threads
32s with 64 threads
27s with 16 or 8 threads
I have found that the optimal amount is actually four: this also
means that only four compressors are running at a time, but
as they're themselves using threads, and typical recipes are dominated
by just two or three large packages, this does not affect overall
completion time.
(From OE-Core rev: 286d456e71ee2730c197ce394d6be2c7eeced18d)
Signed-off-by: Alexander Kanavin <alex@linutronix.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
zstd uses 3 by default (and ZSTD_COMPRESSION_LEVEL is set to that),
while 19 is the highest and slowest.
It's not clear why 19 was picked to begin with, possibly
I copy-pasted it from rpm's examples without thinking:
https://git.yoctoproject.org/poky/commit/?h=master-next&id=4a4d5f78a6962dda5f63e9891825c80a8a87bf66
This brings significant speedups in rpm's compression step:
for example compressing webkitgtk takes 11s instead of 36s.
The rpm size increases from 175648k to 234860k. I think it's
a worthy default tradeoff.
(From OE-Core rev: f1c7d76361425c85d68ad1f61be1e7ff05df4bab)
Signed-off-by: Alexander Kanavin <alex@linutronix.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This allows using it where only a number is needed, such as rpm compression
setting.
(From OE-Core rev: 9c284b4c661566855f15ba3f4508982c2a60b147)
Signed-off-by: Alexander Kanavin <alex@linutronix.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When /var/log is volatile, capturing just the symlink isn't useful. Fix this.
(From OE-Core rev: 06bb8069b023c6b71f3c7dd87a6c2bebc5820083)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The current code is not fit for purpose when handling large files via ssh. In the strace
ptest case, we can end up with a 1.4GB archive being transferred for which every
byte is printed into the task logfile twice over. This is then sent over bitbake IPC
which compounds the problems.
Make the following improvements:
* when the output is large (over 64kb), don't print it
* use a bytearray for better concat performance since strings are slow for this
* when there is no ssh output, say that
* print periodic size status output rather than the data itself since this could be binary and/or large
* fix the killed process message logic which appeared broken
(From OE-Core rev: e7dd009a17dc902852983a82bce41bf78bb1e242)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
bb.fatal() exists right away while bb.error() does some cleanup
before exiting. Fixes running tests during image build with TESTIMAGE_AUTO
multiple times in a row when some of the tests fail:
$ killall -9 Cooker ; bitbake -c clean core-image-base ; \
bitbake core-image-base ; \
bitbake core-image-base
With bb.fatal() something in cleanup is not done and second
image build builds an empty rootfs into .wic image.
Workaround is to kill Cooker processes between bitbake calls,
or to switch testimage.bbclass from bb.fatal() to bb.error()
logging which is done here.
(From OE-Core rev: 077bdd26e6c5bd161f082524ceee9e90d56315b5)
Signed-off-by: Mikko Rapeli <mikko.rapeli@linaro.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
First, this is likely not the final implementation, but a RFC and
prototype.
Some binaries don't dynamically link to libraries, but instead at runtime
dlopen() them. This means extra work for distributions as the dependencies
are not detected automatically, so libraries may be missing.
systemd is one such project which does this, and in an attempt to solve
the packaging problem it also embeds the names of the libraries that can
potentially be opened at runtime into ELF notes. These can be read to
generate package dependencies. For example:
packages/cortexa57-poky-linux/systemd/libsystemd-shared: RRECOMMENDS: added "libkmod (['>= 33']) libzstd (['>= 1.5.6'])"
packages/cortexa57-poky-linux/systemd/libsystemd: RRECOMMENDS: added "libzstd (['>= 1.5.6'])"
I expect this code to be changed before merging. Whilst systemd is the
main user of his approach right now, I expect to see it used in more
places in the future so there's a reasonably good argument to merge it
into the core shlibs code. Also it currently manually extracts and
parses the data, whereas maybe we should incorporate pyelftools into
meta/lib/oe and use that to parse ELF files across all of OE.
This also means we can remove the explicit dependency on libkmod in udev,
which now comes in via libsystemd-shared.
(From OE-Core rev: 905da779bcfe98f105adac708e0045ce8ffe5636)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When running patchreview with --blame, the scripts runs a git log
command on the analyzed patch. When trying to analyse a layer which is
not in poky tree, we might be running the git log command from outside
the git workspace where the file is located, which results in such
failures:
Missing Signed-off-by tag ([truncated]/meta-qcom-hwe/recipes-devtools/partition-utils/qcom-ptool/0001-ptool.py-Generate-zero-files-in-output-folder-when-s.patch)
fatal: not a git repository (or any parent up to mount point /local/mnt)
Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set).
Fix this situation by setting the current work dir inside the git
workspace of the patch when running git log.
(From OE-Core rev: 8cc1c900b91d60e633f62bfe16a2ffc2d61c3f55)
Signed-off-by: Nicolas Dechesne <nicolas.dechesne@oss.qualcomm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Recently the systemd recipe grew support for setting the epoch time
at image build time. Unfortunately this is unconditional, and our
use case for the set-time-epoch PACKAGECONFIG is we have a system
requirement that our product boot with the time set to the UNIX
epoch.
Instead of trying to complicate things with either an image hook or
overriding the systemd recipe, just make setting the epoch at image
time optional, with the same PACKAGECONFIG that controls hardcoding
the systemd build time as the default epoch.
(From OE-Core rev: ae433b35fb2d5475e33dea61e6bc65d83d3af56a)
Signed-off-by: Daniel McGregor <daniel.mcgregor@vecima.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
During the tcl_8.x removal[0] and its reintegration as tcl8_x[1], BPN
has changed from tcl to tcl8. But, recipes that depends on tcl headers
search the tcl8.6.15 directory where the current recipe generate a
tcl88.6.15 ($BPN+$VERSION) directory.
Fix this by hardcoding the base part of the directory name to "tcl".
(From OE-Core rev: dd8461f27b4a55dbf79baa4a71dc08b127801181)
Signed-off-by: Yoann Congal <yoann.congal@smile.fr>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Upstream has solved the absolute path problem differently by taking
paths relative to the top of the module. This appears to solve the
problem, at least I've not found any cases where it breaks.
Drop my patch, and backport the relevant commit from upstream.
(From OE-Core rev: 47f7808dd93e50fb3ecddbf980e40e51dd7376cb)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Following bitbake "cooker: Drop support for BB_DANGLINGAPPENDS_WARNONLY",
show warnings for use of the variable.
(From OE-Core rev: ab0f6898a0f3892a9c4536919adaa1d8d847bb7c)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When the recipe provided by (-r, --recipe) is not found
tinfoil raises an exception that is not catched for
readability, example:
Traceback (most recent call last):
File "/.../poky/bitbake/bin/bitbake-getvar", line 45, in <module>
d = tinfoil.parse_recipe(args.recipe)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/.../poky/bitbake/lib/bb/tinfoil.py", line 633, in parse_recipe
fn = self.get_recipe_file(pn)
^^^^^^^^^^^^^^^^^^^^^^^^
File "/.../poky/bitbake/lib/bb/tinfoil.py", line 550, in get_recipe_file
raise bb.providers.NoProvider('Unable to find any recipe file matching "%s"' % pn)
bb.providers.NoProvider: Unable to find any recipe file matching "aaa"
(Bitbake rev: 06aa6c292813a28c84736193b550fb2d18884d43)
Signed-off-by: Talel BELHAJSALEM <bhstalel@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Testing shows the worst case CDN response time can be up to 100s. The wget fetcher
is used for accessing sstate from the CDN so increase our timeouts there to match
our worst case repsonse times.
(Bitbake rev: 7aca591529e115bc277f93811d8c586630acc8c3)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The default pipe size is 64kb on builds, which can be inefficient
for larger log files from workers. Increase the pipe size to 512kb
since build systems have decent amounts of memory and this is a more
efficient way of batching the data.
Tweak the default read sizes to match the pipe size for efficiency.
Since the contstant is only present in python 3.10 onwards, add
some compatibility code.
(Bitbake rev: 69c14e46600ba5ae9703f67704ab2548875ae6d7)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If there are large amounts of data being transferred to the cooker
from the worker, recreating the bytearray becomes inefficient as it
happens for every pipesize block of data, defaulting to 64kb.
Instead we can use the deletion API for bytearrays to make this more
efficient and avoid the object recreation.
We noticed this with a strace ptest image taking days to complete the
build after having 6GB of data in the testimage log. Whilst there are
other issues there, making this code more efficient doesn't hurt.
(Bitbake rev: a4a72b7edb368f352784c856a647236a887010dd)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
DANGLINGAPPENDS_WARNONLY is a very poorly designed interface and
is commonly abused. The challenge is that once it is set, by any
layer, it applies everywhere.
Some layers rely on this to get notification they need to update
bbappend files and having the behaviour change from inclusion of an
antisocial layer is not good.
In addition, showing warnings as an accepted thing on the console
devalues them and trains the user to ignore them. I want to steer us
away from this mindset.
We could extend the functionality and make it apply only to certain
layers, or only to certain appends but then we've basically re-invented
BBMASK.
Given all the above, we should drop support for BB_DANGLINGAPPENDS_WARNONLY
and direct anyone with issues to BBMASK instead.
https://lists.openembedded.org/g/openembedded-architecture/message/2029
[YOCTO #14870]
(Bitbake rev: fca9c9e3cb6f8e9f99bf51dc5e8a8d83f4c84c69)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When --with-extra-version="oe" option is used, systemtap code
stop using GIT_PRETTY_REV that comes from
'git describe --dirty --always --abbrev=8' output in its version
and uses --with-extra-version value instead. 'git describe' output
has reproducibility issue since it depends on commits present in
lattest branch, and that may change. Thus using fixed value instead
addresses systemtap reproducibility issue.
[YOCTO #15288]
https://bugzilla.yoctoproject.org/show_bug.cgi?id=15288
(From OE-Core rev: 37fb7c4e469baf53f85319c3cbb75af41a6ddbe7)
Signed-off-by: Victor Kamensky <victor.kamensky7@gmail.com>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Patchtest applies patches on top of poky master branch by default;
this means selftest does the same, and any commits from the branch-under-test
are then discarded.
This can cause issues for example, if bitbake-server process started by selftest
from the master branch tries to parse bitbake.conf from the branch under test:
https://valkyrie.yoctoproject.org/#/builders/71/builds/460
(From OE-Core rev: 03c6b2e0277c00faf55c12c4d0b4b5e3a4898f8c)
Signed-off-by: Alexander Kanavin <alex@linutronix.de>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Previous commit added logic to move certain tasks to the end, but these
had no effect, because the result of the make_last() function was not
used to update the post_process_cmds variable.
Also, once this is fixed, it becomes evident that the commands need to
be joined using whitespace, otherwise they all run together, and cannot
be executed as individual commands anymore.
Fixes: 0ffff2c1f8 ("rootfs-postcommands: Try and improve ordering constraints")
(From OE-Core rev: 2a4e8f06bac1bff0a167f775f7babab94b32732a)
Signed-off-by: Ralph Siemsen <ralph.siemsen@linaro.org>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The custom do_fetch routine is ignoring BB_NO_NETWORK, add a check for this
as the correct behavior for the user is to set:
CVE_DB_UPDATE_INTERVAL = "-1"
If CVE_DB_UPDATE_INTERNAL is set to -1, check that a DB file exists, if not
we need to error so the user can deal with this.
Note, MIRRORs are NOT handled by this code.
(From OE-Core rev: 337c0806d2784d74bee8d6420fb8b4d48795d5fa)
Signed-off-by: Mark Hatle <mark.hatle@amd.com>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When systemd is started, it sets the system clock to epoch to ensure the
system clock is reasonably initialized if no working RTC.
As init process, systemd sets epoch very early to the more recent
timestamp of[1]:
- the build time of systemd (-Dtime-epoch)
- the modification time ("mtime") of /var/lib/systemd/timesync/clock
(systemd-timesyncd)
- the modification time ("mtime") of /usr/lib/clock-epoch (systemd)
The first epoch timestamp is hard-coded at build-time by the systemd
recipe (using either SOURCE_DATE_EPOCH, git-tag, or NEWS modification
time[2]).
The second epoch timestamp is maintained at run-time if the system runs
systemd-timesyncd.
This implements the third epoch timestamp at image build-time, by
touching the timestamp file /usr/lib/clock-epoch from the package
post-install script.
[1]: 863098fdc9
[2]: https://github.com/systemd/systemd/blob/v256/meson.build#L804-L825
(From OE-Core rev: 0f51fee4a5408c17cbaf827053f13d6c3b9dbc2c)
Signed-off-by: Gaël PORTAY <gael.portay+rtone@gmail.com>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Refer [1], upstream gdk-pixbuf disable some loaders by default from
2.42.11, this makes some format of icons not works well after upgrade
gdk-pixbuf, report error like:
matchbox-deskto[501]: Error loading icon: Failed to load /usr/share/pixmaps/xinput_calibrator.xpm: Unrecognized image file format
Add PACKAGECONFIG gif, others, and fix the same as some other sdks and
arch linux, disable these loaders by default, refer [2][3][4]
[1] e052a11207
[2] https://gitlab.gnome.org/GNOME/gnome-build-meta/-/issues/846
[3] 3ab7810255
[4] 4fa2d98a19
(From OE-Core rev: 10ea616e0aa0921e02c00689df5a7f2ec5e2b7ce)
Signed-off-by: Changqing Li <changqing.li@windriver.com>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Currently, file system images created with mkfs.vfat are not
reproducible, because both the file system creation time and the
volume id are derived from the current time.
Upstream has added a patch for deriving those from SOURCE_DATE_EPOCH,
when defined, many years ago, but unfortunately there is no official
release containing that patch.
The issue [1] is 2.5 years old, so there's no reason to believe such a
release would be just around the corner.
The patch applies cleanly, and e.g. Arch Linux already uses this exact
combination of source tarball and this single patch [2], so I think
this should be ok. It certainly works for the images I've tested on.
[1] https://github.com/dosfstools/dosfstools/issues/179
[2] https://gitlab.archlinux.org/archlinux/packaging/packages/dosfstools/-/blob/main/PKGBUILD?ref_type=heads
(From OE-Core rev: bf9e6bf884bc780547d3dc88c3977c8102e1faeb)
Signed-off-by: Rasmus Villemoes <ravi@prevas.dk>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This didn't seem to be possible considering the entire point of Cython
is to generate C bindings, but some Python build systems remove the
build tree once the wheel has been generated, so we never get to see the
sources. As xargs will call the specified command even without any files
this results in sed failing.
Pass --no-run-if-empty so that this case doesn't result in an error.
(From OE-Core rev: f1c1bdb05ea8f79a14a4b53e110889b70881f4d7)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If SLIRP is being used instead of TAP for networking to the guest then
the target IP will be localhost. There's no point in pinging localhost
to see if the target is up but whilst you'd think it is harmless, in
some containers ping doesn't actually have enough rights to work:
ping: socktype: SOCK_RAW
ping: socket: Operation not permitted
ping: => missing cap_net_raw+p capability or setuid?
Look at the target address and if it's localhost or 127.0.0.* return
immediately.
(From OE-Core rev: a06ef43d2a50e16c32bd6edbdc7b32c3528687d5)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
As sstate_archive_package just calls tar, writing the function in shell
is actually more complex and opaque than the equivalent python.
Don't check for zstd vs pzstd, we have pzstd in HOSTTOOLS so it will
always be available.
(From OE-Core rev: c9ac5d9d94f254292cf3cafdf273dd6b61d3baa7)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The CPE vendor is "denx" and the CPE product is "u-boot".
Set CVE_PRODUCT for properly matching in the NVD database.
(From OE-Core rev: d2e5d427de13b33694a1d802f5ac833b2c04ced6)
Signed-off-by: Maik Otto <m.otto@phytec.de>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Changelog:
===========
- Refactored the convert command to not need setuptools to be installed
- Don't configure setuptools logging unless running bdist_wheel
- Added a redirection from wheel.bdist_wheel.bdist_wheel to
setuptools.command.bdist_wheel.bdist_wheel to improve compatibility with
setuptools' latest fixes.
(From OE-Core rev: deba45d6d23aae40573b51e16716918f7841ef51)
Signed-off-by: Wang Mingyu <wangmy@fujitsu.com>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
