The current MULTILIB_SCRIPTS entry incorrectly assigns
g-ir-annotation-tool and g-ir-scanner to the ${PN} package. However,
these scripts are actually installed in the gobject-introspection-tools
package. This leads to incorrect symlinks being created when multilib is
enabled. Therefore, this patch correctly moves them to the ${PN}-tools
package.
Error log:
root@intel-x86-64:~# ls -l /usr/bin/g-ir-scanner
lrwxrwxrwx 1 root root 27 Mar 9 2018 /usr/bin/g-ir-scanner -> /usr/bin/g-ir-scanner-lib64
root@intel-x86-64:~# ls -l /usr/bin/g-ir-scanner-lib64
ls: cannot access '/usr/bin/g-ir-scanner-lib64': No such file or directory
(From OE-Core rev: 94aa798624dd3e1d0bfeccc046936a4a4f87b8ca)
Signed-off-by: Jiaying Song <jiaying.song.cn@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
All qemu machines have ext4 in IMAGE_FSTYPES which makes
native mkfs.ext4 available at wic image build time.
genericarm64 defaults to only wic in IMAGE_FSTYPES
and this test was failing:
| DEBUG: Python function extend_recipe_sysroot finished
| DEBUG: Executing python function set_image_size
| DEBUG: 148548.400000 = 114268 * 1.300000
| DEBUG: 652644.400000 = max(148548.400000, 8192)[148548.400000] + 504096
| DEBUG: 652645.000000 = int(652644.400000)
| DEBUG: 652645 = aligned(652645)
| DEBUG: returning 652645
| DEBUG: Python function set_image_size finished
| DEBUG: Executing shell function do_image_wic
| INFO: Creating image(s)...
|
| ERROR: A native program mkfs.ext4 required to build the image was not found (see details above).
|
| Please make sure wic-tools have e2fsprogs-native in its DEPENDS, build it with 'bitbake wic-tools' and try again.
|
| WARNING: exit code 1 from a shell command.
NOTE: recipe core-image-minimal-1.0-r0: task do_image_wic: Failed
(From OE-Core rev: 59b5ec3d53058237dc6f3e85385851d1a8a97f97)
Signed-off-by: Mikko Rapeli <mikko.rapeli@linaro.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This test is failing on genericarm64 which includes all kernel
modules on rootfs by default. Recently added kernel modules
triggered the size limits to be exceeded. Fixes:
ERROR: Actual rootfs size (112884 kB) is larger than allowed size 102400 kB
Doubling the size to avoid issues like this on machines which
may include a lot of packages on default images. Size of the
rootfs does not matter for the test, only that the offsets are
correct in various usecases.
(From OE-Core rev: 1ff542318ea66514ef550d4817ba9b2ef688134c)
Signed-off-by: Mikko Rapeli <mikko.rapeli@linaro.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The wic test_exclude_path_with_extra_space does not succeed on debian-based
AB workers since they, by default, do not install the 'parted' utility. This
test installs the 'wic-tools' package, which includes the 'parted' utility,
but it is not being found/used for some unknown reason.
In the previous patch it was believed that doing some extra PATH handling
(as performed by some other tests with a python try...finally block) would
solve the issue. That turned out to not be the case. This patch starts by
reverting that change, since it has no benefit.
In order to use the native tools from the 'wic-tools' package, wic's
'--native-sysroot' can be used (as demonstrated in other tests). In fact
the wic help message explaining the purpose of this flag states that it is
for passing "...the path to the native sysroot containing the tools(parted
and mtools) to use"[sic].
Removing the host's 'parted' utility better simulates the situation found
on the debian workers for testing. This patch is seen to make this test pass
with no host 'parted' utility in place.
(From OE-Core rev: 306e4831f07d4a8db6ab880487813a6abd0ffa08)
Signed-off-by: Trevor Woerner <twoerner@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Declare riscv64 as a COMPATIBLE_HOST since upstream now support it.
For that target 'valgrind /bin/ls' warns with:
--253-- WARNING: unhandled riscv64-linux syscall: 258
--253-- You may be able to write your own handler.
--253-- Read the file README_MISSING_SYSCALL_OR_IOCTL.
--253-- Nevertheless we consider this a bug. Please report
--253-- it at http://valgrind.org/support/bug_reports.html.
This is a known issue:
https://bugs.kde.org/show_bug.cgi?id=503253
but the tool does work, despite this warning with glibc.
For riscv64 with musl, the build is fine but running:
# valgrind /bin/ls
produces the fatal error:
==306== Process terminating with default action of signal 4 (SIGILL)
==306== Illegal opcode at address 0x1002015952
==306== at 0x40E5F26: map_library (dynlink.c:845)
==306== by 0x40E6C97: load_library (dynlink.c:1183)
==306== by 0x40E7B63: load_preload (dynlink.c:1365)
==306== by 0x40E7B63: __dls3 (dynlink.c:1963)
==306== by 0x40E75D9: __dls2 (dynlink.c:1767)
==306== by 0xFFFFFFFFFFFFFFFF: ???
which is not yet reported.
Patches reviewed, manually fix-up one word change in:
0001-none-tests-fdleak_cmsg.stderr.exp-adjust-tmp-paths.patch
and refresh patches with devtool.
* ==================== CORE CHANGES ===================
* The valgrind gdbserver now supports the GDB remote protocol packet
'x addr,len' (available in GDB release >= 16).
The x packet can reduce the time taken by GDB to read memory from valgrind.
* Valgrind now supports zstd compressed debug sections.
* The Linux Test Project (ltp) is integrated in the testsuite try
'make ltpchecks' (this will take a while and will point out various
missing syscalls and valgrind crashes!)
* ================== PLATFORM CHANGES =================
* Added RISCV64 support for Linux. Specifically for the RV64GC
instruction set.
* Numerous bug fixes for Illumos, in particular fixed a Valgrind crash
whenever a signal handler was called.
* On FreeBSD, a change to the libc code that runs atexit handlers was
causing Helgrind to produce an extra error about exiting threads
still holding locks for. This applied to every multithreaded application.
The extra error is now filtered out. A syscall wrapper had been added
for getrlimitusage.
* On Linux various new syscalls are supported (landlock*, io_pgetevents,
open_tree, move_mount, fsopen, fsconfig, fsmount, fspick, userfaultfd).
* s390x has support for various new instructions (BPP, BPRP, PPA and NIAI).
* ==================== TOOL CHANGES ===================
* The --track-fds=yes and --track-fds=all options now treat all
inherited file descriptors the same as 0, 1, 2 (stdin/out/err).
And when the stdin/out/err descriptors are reassigned they are
now treated as normal (non-inherited) file descriptors.
* A new option --modify-fds=high can be used together with
--track-fds=yes to create new file descriptors with the highest
possible number (and then decreasing) instead of always using the
lowest possible number (which is required by POSIX). This will help
catch issues where a file descriptor number might normally be reused
between a close and another open call.
* Helgrind:
There is a change to warnings about calls to pthread_cond_signal and
pthread_cond_broadcast when the associated mutex is unlocked. Previously
Helgrind would always warn about this. Now this error is controlled by
a command line option, --check-cond-signal-mutex=yes|no. The default is
no. This change has been made because some C and C++ standard libraries
use pthread_cond_signal/pthread_cond_broadcast in this way. Users are
obliged to use suppressions if they wish to avoid this noise.
The full 3.25.0 bug fix list can be found here:
https://valgrind.org/docs/manual/dist.news.html
(From OE-Core rev: 04b3e0c1384469167ddfb4d22e2b513f9a59aca9)
Signed-off-by: Randy MacLeod <Randy.MacLeod@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Debug level was not added as a parameter, causing a warning.
(From OE-Core rev: 40157fcbd9066f261812ba665ec963b2e496aa53)
Signed-off-by: Daniel Turull <daniel.turull@ericsson.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
ChangeLog:
https://github.com/makedumpfile/makedumpfile/releases/tag/1.7.7
This version supports the following new kernels:
- 6.12, 6.13, 6.14
Drop backport patch.
(From OE-Core rev: 364e15aadcbb3ac754c2c484f7920420b4cb3138)
Signed-off-by: Yi Zhao <yi.zhao@windriver.com>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
- New argument android_exe_type for executables
- Changes to the b_sanitize option
- New C standard c2y (and gnu2y)
- i18n module xgettext
- version_compare now accept multiple compare strings
- Improvements to Objective-C and Objective-C++
- Per project subproject options rewrite
- objects added correctly to Rust executables
- rust.test now supports link_whole
- Meson can run "rustdoc" on Rust projects
- The Wayland module is stable
- New swift_std compiler option
- New option to execute a slice of tests
- Valgrind now fails tests if errors are found
Full release notes: https://mesonbuild.com/Release-notes-for-1-8-0.html.
(From OE-Core rev: 84ded53ea7e4db1e3d7ea60527374040ec64b4fd)
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>
libbfd is enabled and it invokes libtool relink step to get rid of
rpaths during install step. libtool 2.4 patches rightly prepend
lt_sysroot to target libdir which relink step would use, such a patch
is also upstreamed into libtool [1]
However, when we do not specify --with-libtool-sysroot, lt_sysoot prefix
turns out to be empty and relink step adds -L/usr/lib to linker command
line. it cause all sort of problems e.g. when the build host has zlib
installed then libbfd tries to link with /usr/lib/libz.so instead of the
one in target sysroot, fortunately OE linker reports host path contamination
and fails the build. Second problem seen when building target binutils on
musl, it links with libc.so correctly but libtool relink step resolves
libc.so in /usr/lib due to this path and expands it into libc.so.6 and
ld-linux-x86-64.so.2 ( glibc host's libc.so is a linker stub ) in
DT_NEEDED ELF section which does not work with
musl linker and build QA detects this anamoly as well.
ERROR: binutils-2.44-r0 do_package_qa: QA Issue: /usr/lib/libbfd-2.44.so contained in package libbfd requires libc.so.6(GLIBC_2.34)(64bit), but no providers found in RDEPENDS:libbfd? [file-rdeps]
This inconsistency may cause produced binaries mistakenly linked against
libraries from the host distro.
Add libtool sysroot to point libtool to correct sysroot location during
build.
[1] https://git.savannah.gnu.org/cgit/libtool.git/commit/?id=3221f9f0fb98d5740ab5d0e8db6a731302520644
(From OE-Core rev: 89e984bd7edb9a2013b65d0215fd6af9aadd59e8)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This recipe takes longer time >20min when bitbake for package
write stage. When cross-verified for longer time duration, found
that do_check() stage taking 20min while other stages completes
before 6min.
This recipe gives only below two test binaries in the packages to
test (ptest: glibc-y2038-tests):
io/ftwtest
io/ftwtest-time64
The above test binaries are already included for testing in recipe
glibc-testsuite_2.41.bb.
It is by now well established that glibc itself works as it should,
that all affected 32 bit targets are configured to use 64 bit time_t,
and that any lingering y2038 issues are in components other than the c
library, and usually come from C programming mistakes (e.g. storing
timestamps in long). Maybe we can simply remove the recipe?
Review comments for fixing above longer time duration ended up in
removing this recipe as a proposal is below
https://lists.openembedded.org/g/openembedded-core/topic/112188476#msg214636
Removed lines having reference to glibc-y2038-tests in the files.
(From OE-Core rev: fbe3679ba3c12c52a502511f5dde91fb4de7a6b6)
Signed-off-by: rajmohan r <semc.2042@gmail.com>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Move the functions in qemu.bbclass to meta/lib/oe/qemu.py as they are
generally useful.
The qemu.bbclass is still kept, and recipes can continue to use functions
from it, though they have become wrapper functions on qemu.py functions.
Note that the QEMU_OPTIONS settings are still kept in qemu.bbclass.
This sets a clear barrier for people to use qemu user mode.
(From OE-Core rev: 7b3563b3b3901c96c3e498799a83ab8cabcf84b4)
Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Fix to ensure it would work with both libsdl2 and libsdl2-compat
(From OE-Core rev: 21033e98045d03025f6e12dba16428fa484b3057)
Signed-off-by: Markus Volk <f_l_k@t-online.de>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We have long since obsoleted md5sum in favour of sha256sum. Drop the remaining
56 entries (which were showing many recipes hadn't been touched in a long time).
They all do have the corresponding sha256sum entries as is clear from the diff.
(From OE-Core rev: 7e4bfcc9706fa8a09f6a0004174a2c3b21c90df3)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
I previously upgrade autoconf 2.72e (the fifth release candidate) to the
final release 2.72, but unfortunately failed to notice that the version
appears to go backwards as the package managers sort 2.72e _after_ 2.72.
We could resolve this with an epoch (via PE) but epochs are forever and
this mistake is temporary. We could set a convoluted PV but that gets
messy as it then means SRC_URI needs to set manually. Instead, set a
convoluted PKGV to fix the sorting order in a way that only alters the
output packages and nothing else, which can be removed when the next
major release is made.
[1] oe-core 11ff8dba0ce ("autoconf: upgrade to final 2.72 release")
(From OE-Core rev: 58b185b25dff627eecc980919dd44dcce32fbca2)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Fix the numpy ptests by doing the following:
- Add meson to ptest RDEPENDS in the recipe;
- Add python3-unittest-automake-output as a ptest RDEPENDS;
- Convert run-ptest to a shell script that sets PYTEST_DEBUG_TEMPROOT to
a directory inside the same path that contains the script, create that
directory, and then invoke the tests with `pytest --automake` pointed
at the numpy path in site-packages (copying the tests into the normal
PTEST_DIRECTORY seems to cause module import breakages in some tests).
This also includes skipping two problematic tests which require a C
compiler and use up a lot of space, respectively;
- Set 'IMAGE_ROOTFS_EXTRA_SPACE = "3048576"' for python3-numpy in
core-image-ptest.bb;
- Also set 'QB_MEM:virtclass-mcextend-python3-numpy = "-m 4096"' in
core-image-ptest.bb;
- Move python3-numpy from the PTESTS_PROBLEMS list to the PTESTS_SLOW
one.
Results on qemux86-64:
Testsuite summary
DURATION: 87
END: /usr/lib/python3-numpy/ptest
2025-04-29T17:35
STOP: ptest-runner
TOTAL: 1 FAIL: 0
Note that many of the skipped tests are due to the absence of
python3-mypy (which is currently in meta-python) and of a Fortran
compiler.
(From OE-Core rev: 7f0b5e8faa1b246531ac425c99a629eb344b21e2)
Signed-off-by: Trevor Gamblin <tgamblin@baylibre.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If extra-utils package is not included in the image, you'll always see a
warning that password agent is missing whenever you start/stop a service:
Failed to execute /usr/bin/systemd-tty-ask-password-agent: No such file or directory
(From OE-Core rev: a87d523ab24e4ea87d1b19ea3a0c515cc47db1b6)
Signed-off-by: Vyacheslav Yurkov <uvv.mail@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Below commits on binutils-2.44 stable branch are updated.
fe459e33c67 PR 32603, revert message changes in 0b7f992b78fe and 31e9e2e8d109
37d12dd25d8 gdb/compile: add missing entry in bfd_link_callbacks array
31e9e2e8d10 PR 32603, more ld -w misbehaviour
0b7f992b78f PR 32603, ld -w misbehaviour
8cb98edf123 s390: Add support for z17 as CPU name
ed70d86b491 x86: Remove AVX10.2 256 bit rounding support
e1af7e590a5 elf: Clear the SEC_ALLOC bit for NOLOAD note sections
35db8c6dd2f ld: Pass -Wl,-z,lazy to compiler for i386 lazy binding tests
cc7ec316a45 Updated translations for bfd and gold
bf088ee09a7 PR 32731 ub sanitizer accessing filenames_reversed
78082591ec7 score-elf gas SEGV
d4c7ee9fbc1 gas: fix rs_fill_nop listing
a68d096a0ab Open the 2.44 branch for further development
Dropped: 0015-CVE-2025-1153.patch
Testing was done and there were no regressions found
(From OE-Core rev: 749bdd5bda6f9b5af8d63794858bbb9834294fcb)
Signed-off-by: Deepesh Varatharajan <Deepesh.Varatharajan@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Even with our fixes in deterministic_imports.patch the
importlib.metadata package scan was still returning Distribution objects
for empty directories. This interacts badly with rebuilds when recipes
are changing as when a recipe is removed from the sysroot directories
are not removed[1].
In particular this breaks python3-meson-python-native rebuilds when
Meson upgrades from 1.7 to 1.8: the site-packages directory has an empty
meson-1.7.dist-info/ and populated meson-1.8.dist-info/. Whilst it's
deterministic to return the empty 1.7 first, this breaks pypa/build as
it looks through the distributions in order.
We had discussed this with upstream previously and there's a more
comprehensive fix upstream (actually in importlib_metadata, not cpython)
which ensures that valid distribution objects are listed first. So we
can drop our patch and replace it with a backport to fix these rebuilds.
[1] oe-core 4f94d929639 ("sstate/staging: Handle directory creation race issue")
(From OE-Core rev: 73de8daa6293403f5b92d313af32882c47bce396)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Older versions do not compile with GCC 15. We had different versions to test
GPLv3 exclusion.
1.21 compiles with gcc 15 and 1.20.2 has a CFLAGS tweak to allow it to work
with gcc 15 too.
1.21 is licensed under GPL-2.0 so we need to rework some of the tests.
Tweak the gplv3 test by adding a special override of LICENSE to then test
the license exclusion code.
Modify the archiver selftests to use the new version.
Based on a patch from Khem Raj <raj.khem@gmail.com>
(From OE-Core rev: 3b17355ad1ecad17d12c5eb0e6403a59ef11f7d7)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If a distro sets TOOLCHAIN with ?= or = then it overrides this
too, however, we demand GCC to be in there due to KERNEL_CC etal
Make it hard assignment, it can still be overturned via a bbappend
in that case it is intentional to use non-gcc compiler for kernel
(From OE-Core rev: 307902aa05c4537cb34fffe768df1547fb6a12d8)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
llvm sourcebase is large and like gcc, it reuses same source tree to
build all recipes using clang+llvm sourcebase
(From OE-Core rev: f5dfd524e9f516ea4be72eb8348acb9b31b64a49)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
bitbake-dumpsig or bitbake-diffsig tools do not work on any of tasks
exposed by llvm-project-source recipe. This is due to it being a
shared-workdir recipe.
Fixes
bitbake-diffsigs -t llvm-project-source-20.1.2 do_preconfigure
NOTE: Starting bitbake server...
ERROR: No sigdata files found matching llvm-project-source-20.1.2 do_preconfigure
(From OE-Core rev: a6d46935939a94b8ea2b83c024aa86f05efbd7ce)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Some components e.g. clang and its runtime needs the native toolchain
defines especially when doing nativesdk builds it uses
CROSS_TOOLCHAIN_FLAGS_NATIVE to pass native toolchain file, which is
then used to build native llvm tools needed during nativesdk builds
Moreover this would enable using OE built native toolchain e.g.
clang-native to build cmake based packages. e.g. libcxx and other llvm
runtime plus it can be used for build native packages which require clang
(From OE-Core rev: 79dc6a23234a34403157dec10d0cdd839ca76b3e)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The user cannot override the setup command options --cross-file and
--native-file because the meson-wrapper places these options on the
command line after the user options. This problem was noticed when
trying to build with an SDK using a custom cross-file.
(From OE-Core rev: 045a53349a5c00b318feb7029470d3fb084b61c8)
Signed-off-by: Tom Hochstein <tom.hochstein@oss.nxp.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
icu will check program install path during do_configure, eg:
checking for a BSD-compatible install... /path/to/install -c
And this path will be writen into pkgdata.inc:
INSTALL_CMD=$(INSTALL-L)
Decided by if install is installed into recipe-sysroot-native during
do_configure stage, the INSTALL_CMD could be
/build/tmp/work/corei7-64-wrs-linux/icu/76-1/recipe-sysroot-native/usr/bin/install
or /build/tmp/hosttools/install if the build is rerun after the sysroot was
extended.
set ac_cv_path_install to install under hosttools to make a deterministic
result of INSTALL_CMD, avoid vary caused by the execute sequence of
another task which DEPENDS on coreutils-native and independent with
do_configure
[RP: Removed paths from ac_cv_path_install to simplify and avoid QA error too]
(From OE-Core rev: 208143e060cda6e22ae1e8c618e033fa9144b323)
Signed-off-by: Changqing Li <changqing.li@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
GCC-15 inliner at O2 seems to be able to analyse more
This is a workaround to compile the one file where it fails
to use -Os
(From OE-Core rev: 01f2b3f09c3c9999e75f15c9041a0668cb6bb580)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Avoid multiple import statements for anything that is used more than
once. Additionally, drop no longer used imports.
(Bitbake rev: 7c74310440f4d6ec47cf5bacf597e18308b3bb20)
Signed-off-by: Philip Lorenz <philip.lorenz@bmw.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
There's no need to pass `name` when it is no longer used.
(Bitbake rev: b132d35dee643e270e3e6dd536dcc90334a0111c)
Signed-off-by: Philip Lorenz <philip.lorenz@bmw.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The wic test_exclude_path_with_extra_space test succeeds on non-debian AB
workers. Add PATH handling so parted from the wic-tools can be found on
debian-based AB workers.
Fixes [YOCTO #15838]
(From OE-Core rev: 3994e727f10c5a0143d52bdd6e1d9ca037296d59)
Signed-off-by: Trevor Woerner <twoerner@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Due to commit [cdrtools-native: fix booting EFI ISO live failed]
applied to improve mkisofs to fix nsectors exceeds 0xffff situation
which set selection criteria type = 2 and save extra nsectors to
vendor unique selection criteria
In following case, add 64MB extra space to bootable image efi.img,
and the partition table of EFI is truncated to 32M
$ echo 'IMAGE_FSTYPES:pn-core-image-minimal = " live"' >> conf/local.conf
$ echo 'MACHINE_FEATURES:append = " efi pcbios"' >> conf/local.conf
$ echo '# 64MB extra space to bootable image efi.img' >> conf/local.conf
$ echo 'BOOTIMG_EXTRA_SPACE = "65535"' >> conf/local.conf
$ bitbake core-image-minimal
$ fdisk -l tmp/deploy/images/qemux86-64/core-image-minimal-qemux86-64.rootfs.iso
...
Device Boot Start End Sectors Size Id Type
tmp/deploy/images/qemux86-64/core-image-minimal-qemux86-64.rootfs.iso1 * 0 376831 376832 184M 0 Empty
tmp/deploy/images/qemux86-64/core-image-minimal-qemux86-64.rootfs.iso2 120 65654 65535 32M ef EFI (FAT-12/16/32)
After applying this patch to process extra sector count, the partition
table of EFI is 90.3M
$ fdisk -l tmp/deploy/images/qemux86-64/core-image-minimal-qemux86-64.rootfs.iso
...
Device Boot Start End Sectors Size Id Type
tmp/deploy/images/qemux86-64/core-image-minimal-qemux86-64.rootfs.iso1 * 0 376831 376832 184M 0 Empty
tmp/deploy/images/qemux86-64/core-image-minimal-qemux86-64.rootfs.iso2 120 185151 185032 90.3M ef EFI (FAT-12/16/32)
[1]https://pdos.csail.mit.edu/6.828/2017/readings/boot-cdrom.pdf
(From OE-Core rev: b4e112ed7e6ba5a6c6df530d696485a588831851)
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>
In ISO live, if the size of efi.img > 32MB, and copy EFI application
(bootx64.efi) to efi.img behind of kernel and initrd, UEFI system
could not find EFI application bootx64.efi
Using QEMU+OVMF to boot ISO live image, press ESC to enter UEFI shell:
...
Shell> ls FS0:\
Directory of: FS0:\
04/05/2011 23:00 12,985,344 bzImage
04/05/2011 23:00 <DIR> 2,048 EFI
04/05/2011 23:00 20,494,696 initrd
04/05/2011 23:00 26 startup.nsh
3 File(s) 33,480,066 bytes
1 Dir(s)
Shell> ls FS0:\EFI
Directory of: FS0:\EFI
0 File(s) 0 bytes
0 Dir(s)
...
In following case, add 64MB extra space to bootable image efi.img,
and the partition table of EFI is truncated to 26.3M
$ echo 'IMAGE_FSTYPES:pn-core-image-minimal = " live"' >> conf/local.conf
$ echo 'MACHINE_FEATURES:append = " efi pcbios"' >> conf/local.conf
$ echo '# 64MB extra space to bootable image efi.img' >> conf/local.conf
$ echo 'BOOTIMG_EXTRA_SPACE = "65535"' >> conf/local.conf
$ bitbake core-image-minimal
$ fdisk -l tmp/deploy/images/qemux86-64/core-image-minimal-qemux86-64.rootfs.iso
...
Device Boot Start End Sectors Size Id Type
tmp/deploy/images/qemux86-64/core-image-minimal-qemux86-64.rootfs.iso1 * 0 376831 376832 184M 0 Empty
tmp/deploy/images/qemux86-64/core-image-minimal-qemux86-64.rootfs.iso2 120 54079 53960 26.3M ef EFI (FAT-12/16/32)
According to page 11: `Figure 5 - Section Entry' in El Torito Bootable
CD-ROM Format Specification [1]. The sector count takes 2 byte which
means max sector count is 0xffff (65535), for 512-byte sector, the
size of bootable image is no more than 32MB (65536 * 512 / 1024 / 1024)
This commit truncate to 32MB if image size larger than 32MB, and
report a warning, then save the extra image sector count to
vendor unique selection criteria
After apply this commit, the partition table of EFI is truncated to 32M
$ fdisk -l tmp/deploy/images/qemux86-64/core-image-minimal-qemux86-64.rootfs.iso
...
Device Boot Start End Sectors Size Id Type
tmp/deploy/images/qemux86-64/core-image-minimal-qemux86-64.rootfs.iso1 * 0 376831 376832 184M 0 Empty
tmp/deploy/images/qemux86-64/core-image-minimal-qemux86-64.rootfs.iso2 120 65654 65535 32M ef EFI (FAT-12/16/32)
[1]https://pdos.csail.mit.edu/6.828/2017/readings/boot-cdrom.pdf
(From OE-Core rev: 259bb8907d8bfe1217e88a3b6935c160e5a92f8d)
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>
Remove --all and -a and they are unused in the file.
Remove long options as they don't actually exist when using getopt.
(From OE-Core rev: c2be1a9197b5e261051fe075edca000dc70ee2fe)
Signed-off-by: Antonin Godard <antonin.godard@bootlin.com>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Workaround to unblock genericarm64 builds.
Upstream is working on a better fix
https://bugs.lttng.org/issues/1426
Fixes: https://bugzilla.yoctoproject.org/show_bug.cgi?id=15840
(From OE-Core rev: c57a903b9ac6d3015195a59829c223917e9c41f8)
Signed-off-by: Mikko Rapeli <mikko.rapeli@linaro.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
linux-firmware-rtl8723 and linux-firmware-adsp-sst
contain symlinks to files that were previously
packaged only in the main linux-firmware package.
This caused both subpackages to inherit an unintended
RDEPENDS on the full package. This change resolves the
issue by ensuring all required files are correctly
included in their respective subpackages.
Thanks to Peter Kjellerstedt for figuring out the rootcause.
(From OE-Core rev: cf27c7d040e7a5f1bbc60fb36c98686704bd7dc5)
Signed-off-by: Patryk Seregiet <patryk.seregiet@gmail.com>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This sample ESP partition is used mostly for testing purposes.
It's not expected to host multiple UKI binaries for example.
Thus reduce size from 500 Mb to size of needed boot binaries
72 Mb plus around 20% free space 88Mb. This is enough for
all test cases and fits to RAM when using PMEM memory based
block device on real target boards with just a few Gb of RAM.
(From OE-Core rev: 7a4b90ef3815aa227236ec9b95540233db8ac3b3)
Signed-off-by: Mikko Rapeli <mikko.rapeli@linaro.org>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When using the ptest-cargo class with multiple Rust test binaries, ptest-runner
may report FAIL: 0 even if one of the tests fails, as long as the last test passes.
This happens because the run-ptest script, as generated by the class, does not
track failures and simply returns the exit code of the last test.
To fix this, each test binary is checked individually for failure. If any test fails,
a non-zero exit code is returned.
This ensures that test failures are not silently ignored and are properly reported
by ptest-runner in multi-test scenarios.
(From OE-Core rev: 039708d2aa578da755d5b6eadd6f549121a93186)
Signed-off-by: Ines KCHELFI <ines.kchelfi@smile.fr>
Reviewed-by: Yoann Congal <yoann.congal@smile.fr>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We call the installer script but if it fails the user doesn't see the
reason, which makes resolving the problem hard. Capture both stdout and
stderr as text, and display it to the user when it fails.
(From OE-Core rev: c67fbe17ce063350181c28f99662004737d8b770)
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>
We're shipping a release but the filename suggests it is a git snapshot.
To avoid version-going-backwards errors we need to continue to put +git
in the PV, so add a comment to remind the upgrader to remove it.
(From OE-Core rev: 467a75c70506720e5603143afc2d005cf14cffeb)
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>
Since runtime dependencies to the old 'dbus-x11' compatibility label
are now no longer used in either poky or meta-openembedded provided
layers, we can remove it.
(From OE-Core rev: 2639ab4fd8855ada4ae8e2093868d7978220e783)
Signed-off-by: Niko Mauno <niko.mauno@vaisala.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Stop shifting first_affected if backport is indicated. This does not
have effect on generated list, but makes the logic cleaner as it will
not shift it to "first affected on our branch" and also make it behave
like in defaultStatus==affected case.
Cc: daniel.turull@ericsson.com
(From OE-Core rev: dc1ecb69389dd79354084757ba6b9af0781afcc0)
Signed-off-by: Peter Marko <peter.marko@siemens.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This will shift fixed version of many CVEs, it does not change status of
any CVE.
Note that the current format of cvelistV5 does not allow us to determine
real value of "fixed_in" without also checking the hashes, but the
result are still fine.
The reason is that many entries are missing original_commit_for_fix
field and thus we see the final "fixed_in" version to be set to backport
to previous branch (e.g. 6.12.23 instead of 6.13).
(From OE-Core rev: 1697404589e2d3a625f9da2e8906e47af668c1c3)
Signed-off-by: Peter Marko <peter.marko@siemens.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Current code takes the first version found as "fixed-version".
That is not correct as it is almost always only the oldest backport.
Fix it by unconditionally shift the assigmnet of variable "fixed" so
that we take last instead of first version.
Cc: daniel.turull@ericsson.com
(From OE-Core rev: 68f8e58a249c8adef18e63f0841e8bfea16f354e)
Signed-off-by: Peter Marko <peter.marko@siemens.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This is preparation for fix in the script so that next update shows only
entries updated by the script change.
(From OE-Core rev: 583e9f15c01555863ae467c7f91729ce85aae194)
Signed-off-by: Peter Marko <peter.marko@siemens.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Changes are:
Include bidi mirroring variants of the requested codepoints when subsetting. The new HB_SUBSET_FLAGS_NO_BIDI_CLOSURE can be used to disable this behaviour.
Various bug fixes.
Various build fixes and improvements.
Various test suite improvements.
(From OE-Core rev: 61a4ec67b4721d4a13b3c1171e55bdef50f7e85e)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* fixes builds on host with gcc-15:
http://errors.yoctoproject.org/Errors/Details/853016/
../../bash-5.2.37/builtins/mkbuiltins.c:268:29: error: too many arguments to function ‘xmalloc’; expected 0, have 1
268 | error_directory = xmalloc (2 + strlen (argv[arg_index]));
| ^~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
(From OE-Core rev: 663a79bbf2f2e113992e457244964b7582d9caaf)
Signed-off-by: Martin Jansa <martin.jansa@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
