We can disable floppy drive by BIOS on a hardware, but an empty floppy
drive is connected by default on qemu-system-x86. Linux usually detect
the device and modprode the matched floppy.ko at the boot stage. Due to
we don't specify a floppy deivce in qemu boot arguments, then the errors
about floppy reading comes out.
It is harmless and normal, so we could ignore this error message on
qemux86.
Seen if kernel-modules is included in the image which pulls in the
relavent kernel module.
https://lists.gnu.org/archive/html/qemu-devel/2021-04/msg01402.html
(From OE-Core rev: 3359f23ee9351c70997d5e0a17d17d1e47d59623)
Signed-off-by: Yanfei Xu <yanfei.xu@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Messages are currently being printed as:
Test requires dropbear, oropenssh-sshd to be installed
but should be
Test requires dropbear, or openssh-sshd to be installed
Adding the space after the 'or' corrects this.
(From OE-Core rev: 51596e0f8cebe1607ab64ffb018d51e815c0ee4b)
Signed-off-by: Jon Mason <jdmason@kudzu.us>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
grap2graph which converts a GRAP diagram into a cropped image fails
to run as below:
$ grap2graph
/usr/bin/grap2graph: line 89: convert: command not found
/usr/bin/grap2graph: warning: falling back to old '-crop 0x0' trim method
/usr/bin/grap2graph: line 104: convert: command not found
/usr/bin/grap2graph: line 103: grap: command not found
Considering we don't often need to convert a GRAP diagram into
a cropped image and the recipe ImageMagick which provides convert
command is in meta-oe layer, so don't ship the related files to
avoid the confusion about the above run time error.
(From OE-Core rev: 251be7279a475ee18c0c53fe9795bb37bffc2b45)
Signed-off-by: Mingli Yu <mingli.yu@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
0001-meson-Also-search-for-rst2man.py.patch
removed since it is included in 2.4.105
(From OE-Core rev: 7871f85a9fe610f600c4234fce38d24808f5a2fd)
Signed-off-by: Zheng Ruoqin <zhengrq.fnst@fujitsu.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
It has been reported that '%' characters in build paths break with python
exceptions, probably due to confusion with python string escaping. Whilst it
is probably fixable, showing the user a human readable error is better given
it doesn't work.
[YOCTO #14282]
(From OE-Core rev: 31a3cf78452270131a657be45e76569515cff7ef)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If BRANCH is defined in local.conf then that name is used to d/l sources
for binutils. You will get this error:
Fetcher failure for URL: 'git://sourceware.org/git/binutils-gdb.git;branch=hardknott;protocol=git'. Unable to fetch URL from any source.
Rename to SRCBRANCH like glibc has to avoid the more common variable name BRANCH.
(From OE-Core rev: 40d18272cd765420080fffc0e4bde7e3e79982af)
Signed-off-by: Armin Kuster <akuster808@gmail.com>
--
V2]
Remove commented out BINUPV and function
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This reverts commit ed69ef2016.
The console entry has already been added into /etc/inittab based
on the SERIAL_CONSOLES. So drop this redundant entry.
(From OE-Core rev: 633f0c6b74e3caa2bae52ca60c61b811b7b2215d)
Signed-off-by: Kevin Hao <kexin.hao@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The hvc tty driver doesn't populate a file like /proc/tty/driver/serial,
so the current implementation of start_getty doesn't work for the hvc
console. By checking the /sys/class/tty/ for the tty device existence,
it should support more console types and also make the codes more simple.
(From OE-Core rev: 670ceef0f6584ece5ce4176610255226a6148570)
Signed-off-by: Kevin Hao <kexin.hao@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Fix the following warning when boot with a core-image-minimal rootfs:
depmod: can't change directory to 'lib/modules/5.10.25-yocto-standard': No such file or directory
(From OE-Core rev: c34650400182a1104a5fbe03e54f5cea69eb1900)
Signed-off-by: Kevin Hao <kexin.hao@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When use automake to generate Makefile.in from Makefile.am, there
comes below race:
| configure.ac:45: error: required file 'config-h.in' not found
It is because the file config-h.in in updating process by autoheader,
so make automake run after autoheader to avoid the above race.
(From OE-Core rev: 1fc0a4a98e65db7efba8bb5cb835101ea5dd865b)
Signed-off-by: Mingli Yu <mingli.yu@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
I was encountering the following race condition on poky:
- automake-native does do_install.
- automake-native does do_populate_sysroot. This hardlinks config.guess
and config.sub into ${D}.
- kmod-native does do_configure. This runs `autoreconf`, which runs
`automake --add-missing` (symlinks config.guess/config.sub from
recipe-sysroot-native to build dir), then runs `gnu-configize` (copies
_its own_ config.guess/config.sub _on top_ of the already existing
ones). Since the destinations already had symlinks, the copy would
overwrite config.guess/config.sub in recipe-sysroot-native, which
would in turn overwrite the same in ${D} due to being hardlinked.
- automake-native does do_package. The outhash is thus calculated on the
clobbered config.guess/config.sub files.
With hash equivalency enabled, the different outhash produced a
different unihash, which kept me from reusing sstate between my laptop
and my build server. This race condition would happen only on the build
server (BB_NUMBER_THREADS = 32) but never on my laptop
(BB_NUMBER_THREADS = 6).
I didn't see the --install and --symlink flags being used by any other
recipe, so I removed them, and that fixed the issue.
(From OE-Core rev: 89d675efd633b495daa4a3a57420b9c309497035)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The run-ptest script got accidently dropped from the SRC_URI during
a past update and ptest patch.
(From OE-Core rev: 4479f810c1a3ab2badf4f9610c309bc0e23e2a5f)
Signed-off-by: Saul Wold <saul.wold@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
as cpan release versions are almost always follow an a.b version scheme,
it's better to filter out beta releases such as a.b.c.
Use the first resource fetched from https://cpan.metacpan.org as base
for calculating the needed regex.
In case nothing can be calculated fall back to nothing.
Add this to cpan-base to enable it for new & old style cpan integration.
(From OE-Core rev: 3df2cf383b58a3100bd78ebb0369047221121512)
Signed-off-by: Konrad Weihmann <kweihmann@outlook.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Whilst pkg-config is fine with .pc files containing leading whitespace,
pkgconf is less forgiving.
(From OE-Core rev: 14bfe5f15f78c1bc049868633fd6fa19feb5a70c)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Currently the headers are not installed and the ltp-dev package is
empty.
This patch adds an include-install make target in the do_install step to
install them in sysroot which ends up as a working ltp-dev package.
(From OE-Core rev: f6943da4444cd71053650be0c9212bc25ac53137)
Signed-off-by: Jonas Höppner <jonas.hoeppner@garz-fricke.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If a recipe inherits cross-canadian and contains "nativesdk" in
BBCLASSEXTEND and meta-mingw is included and multiconfig is enabled,
bitbake will generate the correspending recipe. As meta-mingw sets
SDK_OS to "mingw32", that's what TARGET_OS will be set to as well.
Thus, currently such a recipe won't pass the check and fail with
a message:
Building cross-candian for an unknown TARGET_SYS
(x86_64-mysdk-mingw32), please update cross-canadian.bbclass
Even when building an SDK targeting Linux, but the mentioned conditions
are met, bitbake will try to generate the corresponding recipe and fail.
As the described combination seems valid, including "mingw32" into the
whitelist unconditionally as a fix is suggested.
(From OE-Core rev: d9306e8f9dbdbd30382f0bc0f0a1af75e702a2aa)
Signed-off-by: Anatol Belski <anbelski@linux.microsoft.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
NR_futex is not defined by newer architectures e.g. riscv32 as
they only have 64bit variant of time_t. Glibc defines SYS_futex
interface based on __NR_futex, since this is used in applications,
such applications start to fail to build for these newer architectures.
Define a fallback to alias __NR_futex to __NR_futex_time64 to make
SYS_futex keep working.
Reference: https://git.openembedded.org/openembedded-core/commit/?id=7a218adf9990f5e18d0b6a33eb34091969f979c7
(From OE-Core rev: 81599bf32135187b34726d41e9f619d22ca1bdd1)
Signed-off-by: Mingli Yu <mingli.yu@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Further to 50ff9afb39, only detect code changes in submodules that are
subdirectories of the EXTERNALSRC directory.
The (undocumented) git submodule--helper returns a path
for each submodule relative to the top of the repo.
Don't add submodules that are not within our source subtree.
[YOCTO #14333]
(From OE-Core rev: 1c18225d3ef94a41fc073ae87c163b68e6d46571)
Signed-off-by: Douglas Royds <douglas.royds@taitradio.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This reverts commit 4525310d49d115a37705f04ac5c03d639e5e8f8c.
Further to 50ff9afb39, only detect code changes in submodules that are
subdirectories of the EXTERNALSRC directory.
The (undocumented) git submodule--helper returns a path
for each submodule relative to the top of the repo.
Don't add submodules that are not within our EXTERNALSRC subtree.
If we unpack one git repo inside another, like this:
SRC_URI = "git://${GIT_SERVER}/repo1;name=repo1;destsuffix=repo1 \
git://${GIT_SERVER}/repo2;name=repo2;destsuffix=repo1/repo2 \
"
Git status reports, for repo1:
Untracked files:
(use "git add <file>..." to include in what will be committed)
repo2/
If we run `devtool modify` on this recipe, do_patch runs with:
PATCHTOOL = "git"
PATCH_COMMIT_FUNCTIONS = "1"
The `patch_task_postfunc` (patch.bbclass, line 82) runs a `git add .` on the
top-level repo1, leaving the checkout in an invalid state. The following git
warning does not appear in the log:
$ git add .
warning: adding embedded git repository: repo2
hint: You've added another git repository inside your current repository.
hint: Clones of the outer repository will not contain the contents of
hint: the embedded repository and will not know how to obtain it.
hint: If you meant to add a submodule, use:
hint:
hint: git submodule add <url> repo2
hint:
hint: If you added this path by mistake, you can remove it from the
hint: index with:
hint:
hint: git rm --cached repo2
hint:
hint: See "git help submodule" for more information.
$ git submodule status
fatal: no submodule mapping found in .gitmodules for path 'repo2'
No further git submodule commands can be run on the checkout.
We could enhance the `patch_task_postfunc` to look for any embedded git
checkouts and add them as submodules, but this seems unnecessary complexity for
an obscure edge-case. Although the git repo is left in an invalid state with
respect to the submodules, it still serves the purpose required by devtool:
To take further commits, and generate patch files from them.
We are still able to run these commands to examine any submodules,
where git submodule--helper reports paths relative to the top of the checkout:
$ git ls-files --stage | grep ^160000
160000 5feee12d6e974dd8c0614cf5b593380b046439a5 0 repo2
$ git submodule--helper list
160000 5feee12d6e974dd8c0614cf5b593380b046439a5 0 repo2
When a recipe sets EXTERNALSRC to a subdirectory of the git checkout, we test
for the existence of the reported submodule paths within the EXTERNALSRC
directory.
The latest versions of git submodule--helper accept a path to a subdirectory and
correctly report no submodules within that subdirectory. Regrettably, we still
support git versions that don't accept a path to a subdirectory.
[YOCTO #14333]
(From OE-Core rev: 2055718fdd19f925e236d67823017323bbd92a4b)
Signed-off-by: Douglas Royds <douglas.royds@taitradio.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
At least some Qt tooling depends on assimp.
(From OE-Core rev: 49c6742eba328236cb73c0ac59b6288f29c46c81)
Signed-off-by: Samuli Piippo <samuli.piippo@qt.io>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This reverts commit afc9ba7d546f3f2e60fb6f46f740dc925542df16.
Ptest-runner was upgraded in e3fd8f17dfb41173dbe037c25087a69f90b1346f,
which means we no longer need to limit glib-2.0 ptest output.
[YOCTO #14170]
(From OE-Core rev: e7be3901e43645796e195348924739d03495a079)
Signed-off-by: Yi Fan Yu <yifan.yu@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If not postinstall applied, some nativesdk command could not be found
in sdk due to update-alternatives in postinst not be executed, such as chroot:
$ which chroot
/sbin/chroot
$ which chroot.coreutils
path-to-sdk/sysroots/x86_64-wrlinuxsdk-linux/usr/bin/chroot.coreutils
After applying the fix
$ which chroot
path-to-sdk/sysroots/x86_64-wrlinuxsdk-linux/usr/bin/chroot
$ which chroot.coreutils
path-to-sdk/sysroots/x86_64-wrlinuxsdk-linux/usr/bin/chroot.coreutils
(From OE-Core rev: 2a9bf19502766baa4087456649d5471483d04f6a)
Signed-off-by: Hongxu Jia <hongxu.jia@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
image-manifest: script to generate product/image specific BOM
The image-manifest script generates image specific reports based on
an image manifest file. Currently there is data generated by buildhistory,
pkgdata, and license manifest but this data is poorly formated and spread
across multiple text files. This script can generate a single JSON output
file that is machine readable by other tools.
The manifest-info collects package information and stores the information
in a tarball. manifest-info can be configured using a json configuration
file. The default configuration including all possible options can be
dumped using the dump-config subcommand.
image-manifest takes an image manifest file as input to get the runtime
dependencies. As an option image-manifest can also use the build dependency
file, pn-buildlist, to get the build dependencies excluding native
packages.
This script extends the oe-image-manifest script [0] done by Paul Eggleton
[0]
https://github.com/intel/clear-linux-dissector-web/blob/master/layerindex/static/files/oe-image-manifest
------------------------------------------------------
usage: image-manifest [-h] [-d] [-q] <subcommand> ...
Image manifest utility
options:
-h, --help show this help message and exit
-d, --debug Enable debug output
-q, --quiet Print only errors
subcommands:
recipe-info Get recipe info
list-depends List dependencies
list-recipes List recipes producing packages within an image
list-packages List packages within an image
list-layers List included layers
dump-config Dump default config
manifest-info Export recipe info for a manifest
Use image-manifest <subcommand> --help to get help on a specific command
Co-developed-by: Paul Eggleton <bluelightning@bluelightning.org>
(From OE-Core rev: ad8fec9ce1704866df925bda18a240d6889b1ed5)
Signed-off-by: Anders Wallin <anders.wallin@windriver.com>
Signed-off-by: Saul Wold <saul.wold@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
0001-src-compress.c-correct-header-define-for-xz-lzma.patch
removed since it is included in 5.40
(From OE-Core rev: ae73c5fa666c0e0a7d1d7a04acd6246542b744aa)
Signed-off-by: Wang Mingyu <wangmy@fujitsu.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Use git for SRC_URI as thi release has not appeared on gnome downloads yet
Drop LGPL-2.0 as it has fully moved to LGPL-3.1+ see [1] that also
covers for change in License checksums for GPL-3
Add license information to cover for Xterm files in libvte
Add new glade files into -dev package
[1] 5e14529d42
(From OE-Core rev: 4a1a20325e2d40256e03ab1a5be348a4c213d181)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
