- Address the absence of an initial full bare clone
- Utilize the initial shallow clone
- Modify existing test cases for this behavior
- Remove incompatible test cases
(Bitbake rev: 599fedacd7782dcb52825c22200f35344c102548)
Signed-off-by: Stefan Koch <stefan-koch@siemens.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When `ud.shallow == 1`:
- Prefer an initial shallow clone over an initial full bare clone,
while still utilizing any already existing full bare clones.
- If the Git error "Server does not allow request for unadvertised object"
occurs, the initial full bare clone is fetched automatically.
This may happen if the Git server does not allow the request
or if the Git client has issues with this functionality,
especially with the Git client from Ubuntu 20.04.
This improves:
- Resolve timeout issues during initial clones on slow internet connections
by reducing the amount of data transferred.
- Eliminate the need to use an HTTPS tarball `SRC_URI`
to reduce data transfer.
- Allow SSH-based authentication (e.g. cert and agent-based) when
using non-public repos, so additional HTTPS tokens may not be required.
(Bitbake rev: 457288b2fda86fd00cdcaefac616129b0029e1f9)
Signed-off-by: Stefan Koch <stefan-koch@siemens.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This directory must have mode 0700, and should be under /run/user (as
recommended in the specification, and as weston-init does).
Also check the permissions if the directory already exists and fail
early if they're incorrect.
[ YOCTO #13878 ]
(From OE-Core rev: 5c98609bf7dfb05af722e30adb49731727df9a94)
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 kernel/kvm test uses the host objcopy when building a payload, but
the host objcopy might not know how to deal with target binaries:
CC testcases/kernel/kvm/lib_host.o
objcopy: Unable to recognise the format of the input file `kvm_svm03-payload.elf'
make[3]: *** [ltp/testcases/kernel/kvm/Makefile:67: kvm_svm03-payload.o] Error 1
Solve this by using the host-prefixed objcopy binary.
(From OE-Core rev: 74818f79bd9a206f77ae3d26b19657116fd956cc)
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>
Few unit tests are failing for x86_64 arch.
Ignore the failing unit tests.
Upstream-Status: Pending
(From OE-Core rev: c71f9efc3140d279813ff6eb474fdbf5e677e348)
Signed-off-by: Deepesh Varatharajan <Deepesh.Varatharajan@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Previously, download-ci-llvm was set to false. However, with the following commit:
7d579046c8 ,
which has been present from rust_1.83, it was changed to true. As a result, after
updating to rust_1.83, we encountered the following error during the build:
-------------------------------------------------------------------------------
| thread 'main' panicked at src/core/config/config.rs:2047:13:
| setting build-target.llvm-config is incompatible with download-ci-llvm.
| note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
-------------------------------------------------------------------------------
To resolve this issue, we are setting download-ci-llvm back to false.
(From OE-Core rev: d43424cba7e93ee30b410d0a024be441e2336dbd)
Signed-off-by: Deepesh Varatharajan <Deepesh.Varatharajan@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Rust stable version updated to 1.83.0.
https://blog.rust-lang.org/2024/11/28/Rust-1.83.0.html
Renamed and modified the below patch to adapt the new version.
rv32-cargo-rustix-0.38.34-fix.patch->rv32-cargo-rustix-0.38.37-fix.patch
Modified the below patches to adapt the new version.
repro-issue-fix-with-cc-crate-hashmap.patch
revert-link-std-statically-in-rustc_driver-feature.patch
Dropped: zlib-off64_t.patch
a566e156b3kq
Because of the following commit ,
68034f837a
when we enable lib32, getting build failure because there is a check for target
support for "-Zdual-proc-macros" flag not functioning properly when lib32 is
enabled in the build environment. So for now reverting this commit and bring
back the previous behavior, where the "-Zdual-proc-macros" flag is always
added for building proc macros, regardless of the target architecture's support.
This would bypass the check introduced in the patch, allowing the build to
proceed without error, even when building for a 64-bit architecture with lib32 enabled.
(From OE-Core rev: 40d8dafdf556d7ce79c12a6de872193be9a0928a)
Signed-off-by: Deepesh Varatharajan <Deepesh.Varatharajan@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
After the fixture changes, the tests need to be tweaked unfotunately.
(Bitbake rev: 708abd1a8060684127acc7ce4142f05865005750)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We need to validate the toaster fixtures information against our current release
data to ensure it is correct when we release. Add a script we can use to
do this which the autobuilder can run to validate things.
[YOCTO #15516]
(Bitbake rev: 5b2d79ed505bbfa2fb2d355935e75199b7f2c37e)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
To be able to switch toolchains, we need to separate out the gcc definitions
into seperate include files. This patch starts that process. Whilst the
include is still hardcoded for now, it allows developers to start experimenting
with this locally more easily and stops people reinventing this patch. A
sample clang configuruation is also included which I was using for experimentation.
(From OE-Core rev: be063d58c0985a2c43c16302efb44706fbf3f1b3)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Now the obsolete config is removed from the autobuilder, we should remove
this distro from the tested list too.
(From meta-yocto rev: 59567ab18a6819ea845c9be824b203d030eb09c4)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Update the distros list to match what the autobuilder has available as configured
and tested workers.
(From meta-yocto rev: b3641515b44dcde4ee37e82428699d92b0785f2a)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Use :setfiletype instead of :set filetype. The former only sets the
'filetype' option if it has not been set before, which makes it possible
to override the syntax of certain *.inc files in autocommands from e.g.
.vimrc or modelines. All other ftdetect plugins in upstream vim also use
:setfiletype for this reason.
The detection for bitbake *.inc files is now upstream since Vim 9.0
patch 0055 [1]. If we're running an earlier Vim, use the detection
heuristic from upstream [2] to overwrite the filetype explicitely if we
find bitbake code. But don't always assuming that *.inc files are
bitbake files so as not to break Perl, PHP, Assembly, Povray, etc.
[1]: https://github.com/vim/vim/commit/fa49eb482729
[2]: https://github.com/vim/vim/blob/fb49e3cde79d/runtime/autoload/dist/ft.vim#L715
(Bitbake rev: e8efbba5d7bb4b685ed0a9b970e042ad99be8afb)
Signed-off-by: Roland Hieber <rhi@pengutronix.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
In order to avoid a potentially confusing backtrace, check that the mcdepend
is valid when we add it.
Add a test case to ensure invalid configurations are caught and trigger an
error.
[RP: Reworked test case to simplify and improve code]
(Bitbake rev: ff523497270f37b484b44a4445c2194791bcb6ff)
Signed-off-by: Mark Hatle <mark.hatle@amd.com>
Signed-off-by: Mark Hatle <mark.hatle@kernel.crashing.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We've been seeing intermittent failures on Ubuntu 22.04 in oe-selftest which
were problematic to debug. The failure was inside lock_timeout and once that was
identified and the backtrace obtained, the problem becomes clearer:
File "X/bitbake/lib/bb/server/process.py", line 466, in idle_thread_internal
retval = function(self, data, False)
File "X/bitbake/lib/bb/command.py", line 123, in runAsyncCommand
self.cooker.updateCache()
File "X/bitbake/lib/bb/cooker.py", line 1629, in updateCache
self.parser = CookerParser(self, mcfilelist, total_masked)
File "X/bitbake/lib/bb/cooker.py", line 2141, in __init__
self.bb_caches = bb.cache.MulticonfigCache(self.cfgbuilder, self.cfghash, cooker.caches_array)
File "X/bitbake/lib/bb/cache.py", line 772, in __init__
loaded += c.prepare_cache(progress)
File "X/bitbake/lib/bb/cache.py", line 435, in prepare_cache
loaded = self.load_cachefile(progress)
File "X/bitbake/lib/bb/cache.py", line 516, in load_cachefile
progress(cachefile.tell() + previous_progress)
File "X/bitbake/lib/bb/cache.py", line 751, in progress
bb.event.fire(bb.event.CacheLoadProgress(current_progress, cachesize),
File "X/bitbake/lib/bb/event.py", line 234, in fire
fire_ui_handlers(event, d)
File "X/bitbake/lib/bb/event.py", line 210, in fire_ui_handlers
_ui_handlers[h].event.send(event)
File "X/bitbake/lib/bb/cooker.py", line 117, in send
str_event = codecs.encode(pickle.dumps(event), \'base64\').decode(\'utf-8\')
File "/usr/lib/python3.10/asyncio/sslproto.py", line 320, in __del__
_warn(f"unclosed transport {self!r}", ResourceWarning, source=self)
File "/usr/lib/python3.10/warnings.py", line 109, in _showwarnmsg
sw(msg.message, msg.category, msg.filename, msg.lineno,
File "X/bitbake/lib/bb/main.py", line 113, in _showwarning
warnlog.warning(s)
File "/usr/lib/python3.10/logging/__init__.py", line 1489, in warning
self._log(WARNING, msg, args, **kwargs)
File "/usr/lib/python3.10/logging/__init__.py", line 1624, in _log
self.handle(record)
File "/usr/lib/python3.10/logging/__init__.py", line 1634, in handle
self.callHandlers(record)
File "/usr/lib/python3.10/logging/__init__.py", line 1696, in callHandlers
hdlr.handle(record)
File "/usr/lib/python3.10/logging/__init__.py", line 968, in handle
self.emit(record)
File "X/bitbake/lib/bb/event.py", line 778, in emit
fire(record, None)
File "X/bitbake/lib/bb/event.py", line 234, in fire
fire_ui_handlers(event, d)
File "X/bitbake/lib/bb/event.py", line 197, in fire_ui_handlers
with bb.utils.lock_timeout(_thread_lock):
File "/usr/lib/python3.10/contextlib.py", line 135, in __enter__
return next(self.gen)
File "X/bitbake/lib/bb/utils.py", line 1888, in lock_timeout
bb.server.process.serverlog("Couldn\'t get the lock for 5 mins, timed out, exiting. %s" % traceback.format_stack())
or put in simpler terms, whilst sending an event(), an unrelated warning
message happens to be triggered from asyncio:
/usr/lib/python3.10/asyncio/sslproto.py:320: ResourceWarning: unclosed transport <asyncio.sslproto._SSLProtocolTransport object at 0x7f0e797d3100>
which triggers a second event() which can't be sent as we're already
in the critcal section and already hold the lock.
That warning is due to the version of asyncio used on Ubuntu 22.04 with
python 3.10 and that comined with timing issues explains why we don't
see it on other python versions or distros.
We can't handle the second event as the lock is there to serialise the
events. Instead, we queue the event and then process the queue later.
Add a new version of lock_timeout which allows us to handle the situation
more gracefully.
(Bitbake rev: 2c590ff1aff89d23b25ce808650f200013a1e6af)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We never want to exit whilst holding these locks as it deadlocks all python
threads. Add signal blocking around the lock critical part so a signal
shouldn't cause such an exit.
(Bitbake rev: a097755c671e2b530dea6200a94b39fa9dca246c)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We should really try and take the lock in the try/finally block so that
in some rare cases such as badly timed interrupt/signal, we always release
the lock.
(Bitbake rev: a9eb8bf7174b6962b5ba07192fe95b8c7112d9d2)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If you send this forked process a SIGTERM, it will execute all of the
parent's exit code leading to two sets of console/exit output which is
extremely confusing. Wrap the code in a try/finally to ensure we always
call os._exit() to avoid this.
I spent far too long trying to work out the crazy console output from this.
(From OE-Core rev: 652e40bfae24b8e23bbf7a7f35d900d2ab8d0f92)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
ctypes.util.find_library depend on run external programs(ldconfig, gcc,
objdump or ld) to get the pathname, if none of above are installed, None
is returned. Previously, RDEPENDS to ldconfig is added to ensure it
always work when installed.
This commit change it to RRECOMMENDS, this allows user who don't use
function find_library could remove ldconfig from image by
PACKAGE_EXCLUDE
Refer:
https://docs.python.org/3/library/ctypes.html
(From OE-Core rev: 404e7c65499c58d2a6a760b5f0994fadd2ff74d0)
Signed-off-by: Changqing Li <changqing.li@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Check if the variable GO_IMPORT is
set in the recipe. If not generate an error.
Test building go-helloworld when GO_IMPORT assigned
Test building go-helloworld when GO_IMPORT is not assigned, generate error about GO_IMPORT
Test building any other recipe(e.g bash) when GO_IMPORT is not assigned, generate error about GO_IMPORT
Test creating a GO recipe with recipetool (not affected)
Test selftest test_recipetool_create_go (not affected)
Test selftest test_recipetool_create_go_replace_modules (not affected)
[YOCTO #15763]
CC: Yoann Congal <yoann.congal@smile.fr>
CC: Randy MacLeod <randy.macleod@windriver.com>
(From OE-Core rev: 374a91204bdaf44067f6b0ae89ed60934751efaa)
Signed-off-by: Christos Gavros <gavrosc@yahoo.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Rework the anon Python so that it doesn't expect to find non-MLPREFIXed FILES
overrides which are then mapped into MLPREFIXed versions, this allows the
apparent hardcoding of boost-{test,serialization} to be written more naturally
(and is significantly less surprising).
With this, and a change to lookup ${BPN} when generating split package names,
generating an explicitly versioned boost package (e.g. "boost-1.82") alongside
the main boost package ("boost") can be done by copying/renaming the older
recipe. This is useful when upstream code hasn't yet been ported to newer
boost and an older version is required.
(From OE-Core rev: b0770990a8b332dd2de802091164c9506882a465)
Signed-off-by: Alex Kiernan <alex.kiernan@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Due to we have upgraded go to 1.24.0, we should also bump GOVERSION
to fix preferred version warning
...
WARNING: preferred version 1.22% of go not available (for item go)
WARNING: versions of go available: 1.24.0
...
(From OE-Core rev: 939449cfcb4a920132145d2ad1212bac3acb1baa)
Signed-off-by: Hongxu Jia <hongxu.jia@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
After upstream go applied commit [cmd: remove support for
GOROOT_FINAL][1], GOROOT_FINAL variable is dropped and use
option -trimpath to instead [2]
The option -trimpath has already been added to GOBUILDFLAGS
in go.bbclass
[1] 507d1b22f4
[2] https://github.com/golang/go/issues/62047
(From OE-Core rev: 791ab77ac05f658ecd61525a3d9b1afaf8ac6e06)
Signed-off-by: Hongxu Jia <hongxu.jia@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
In upstream commit [cmd: remove support for GOROOT_FINAL][1], it clear
GOROOT for func ld when -trimpath is used
But it missed to do the same thing for share libarary linking which caused
building go-runtime failed with buildpath issue
|ERROR: go-runtime-1.23.4-r0 do_package_qa: QA Issue: File /usr/lib/go/pkg/
linux_amd64_dynlink/libstd.so in package go-runtime contains reference to
TMPDIR [buildpaths]
This commit applied a patch to clear GOROOT for func ldShared when
-trimpath is used and add option -trimpath to go-runtime build
[1] 507d1b22f4
[2] 507d1b22f4 (diff-cab5921f94f2667bb0bc1b935d2d46b4c03541b4351b33438ab7290b94dea212R669)
(From OE-Core rev: f7b05ebfdc6504a8360741f273163ef7fbb11b10)
Signed-off-by: Hongxu Jia <hongxu.jia@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
In rare cases BUILDNAME can seemingly be None outside of heartbeat events
which leads to UnboundLocalErrors as bsdir and taskdir aren't defined.
Skip the code in these cases rather than generate tracebacks which cause
bitbake server to exit.
(From OE-Core rev: 0f74d804ba0daf7e8bd6481597740b9d89821414)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Spamming the build host's syslog with useradd information during image creation
isn't great. Add a patch to disable that.
It may be possible to convince upstream to make it a configure option but for
now the patch is trivial and reduces host impact to the logs.
(From OE-Core rev: a52572886e60e4aff9d54b57bf45a301e1dec1ee)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The class called 'make menuconfig' without any of the make variables and
options set in EXTRA_OEMAKE, resulting in a quite different build
environment than actually intended.
For the kernel.bbclass this was fixed in commit 8c616bc0 ("kernel: Use
consistent make flags for menuconfig") by appending ${EXTRA_OEMAKE} to
KCONFIG_CONFIG_COMMAND.
Instead of fixing this individually for additional recipes, we simply
include ${EXTRA_OEMAKE} in KCONFIG_CONFIG_COMMAND by default.
For most class users, this change is directly visible in the generated
.config file:
* For barebox and u-boot, the CONFIG_GCC_VERSION erroneously reflected
the host GCC version before where it now correctly reflects the target
toolchain's GCC.
* For u-boot, also the "Compiler: " line at the beginning of the .config
now prints the target toolchain instead of the host ones.
* The kernel had this already set.
* busybox did not produce any difference.
Note that these projects might base some compile-time decisions on e.g.
the actual compiler version used. Having the wrong one in the
menuconfig-generated .config affects at least the visibility and
consistency.
Reported-by: Ulrich Ölmann <u.oelmann@pengutronix.de>
(From OE-Core rev: 1b6ddd452837e67b500a84455a234f5edc8250a9)
Signed-off-by: Enrico Jörns <ejo@pengutronix.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
In boost 1.85 a charconv implementation in c++11 was added
[https://www.boost.org/doc/libs/master/libs/charconv/doc/html/charconv.html]
This is already used in real life and e.g. building the current wesnoth release fails with:
| /usr/src/debug/wesnoth/1.19.9/src/utils/charconv.hpp:57:(.text+0x238b): undefined reference to `boost::charconv::to_chars(char*, char*, double, boost::charconv::chars_format)'
Add charconv to BOOST_LIBS to provide the library
(From OE-Core rev: 42d14c130f2159c1d9ea314acc93142e6ccb2761)
Signed-off-by: Markus Volk <f_l_k@t-online.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
After the removal of BSD-4-Clause from LICENSE in commit 362435b0aec
(libbsd: Drop licenses that were removed upstream), the licenses for all
packages match the licenses for the recipe. Thus there is no longer any
reason to explicitly specify the package licenses.
(From OE-Core rev: 0c1b68fefe41d92eaa87578ff644bc254e078f9a)
Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
0001-automake-Add-default-libtool_tag-to-cppasm.patch was upstreamed in
1.16[1].
0003-build-fix-race-in-parallel-builds.patch wasn't directly applied,
but a fix for the same problem was merged in 1.17[2].
[1] automake dc67b18d "automake: Add default libtool_tag to cppasm"
[2] automake 5d022858 "build: fix race in parallel builds"
(From OE-Core rev: 386feebe8221c5ef0f87d371dc3e79bfdee1a3bb)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* Drop 0001-sched_attr-Do-not-define-for-glibc-2.41.patch as it has been
merged upstream.
* Skip statmount02 case which does not work on musl.
(From OE-Core rev: 5d72185e65aa0d9012913d9d095caceada7799d7)
Signed-off-by: Yi Zhao <yi.zhao@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This reverts commit 7adaec468d.
It does not seem to fix the issue it was supposed to fix.
Additionally it breaks code which decides in full/partial update,
because it manipulates timestamp that code is relying on.
(From OE-Core rev: ebc65fdddd7ce51f0f1008baa30d0ae7918ae0bb)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
psplash-systemd.service depends on FIFO created by psplash-start@fb0.service.
This FIFO can be removed due to signals or /dev/fb0 related errors
when psplash-start@fb0.service exits. This exit can happen
when psplash-systemd.service is being started. Thus ignore
all errors in psplash-systemd.service startup.
There are too many ways things can go wrong and all of them
leave open race conditions unless a single process handles
all of the psplash usecases including progress bar updates.
(From OE-Core rev: 580ae81e102bf999cb89f05430c737210253d90a)
Signed-off-by: Mikko Rapeli <mikko.rapeli@linaro.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
oe-core no longer supports OE_IMPORTS[1], so remove the documentation.
[1] oe-core 1f56155e ("base: Switch to use addpylib directive and
BB_GLOBAL_PYMODULES")
(From OE-Core rev: d1388e0958c8013179a948e08bf989c07f8654ca)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The current code for multiple argument passing is horrible. Tweak the
multiprocess_launch function to only convert to a tuple if it isn't already
one, which means we can then use function arguments in a standard way.
(From OE-Core rev: 7c99f90079e722764ebdc30e8d0e781454b3a51a)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This prevented package_qa sstate from being reusable unless host uid/gid
values would match exactly (and they unfortunately do on the yocto autobuilder
worker machines which all share a 'pokybuild' user).
I noticed this when testing CDN sstate reuse, which otherwise works well.
(From OE-Core rev: 6ea8b4b10b0549c858427a8411bf2a4cd5c0eb7b)
Signed-off-by: Alexander Kanavin <alex@linutronix.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This is an OpenEmbedded-specific variable that is no longer used[1].
[1] oe-core 1f56155e ("base: Switch to use addpylib directive and
BB_GLOBAL_PYMODULES")
(Bitbake rev: 34bfa55a3c14f5d1d6bb3e31b747906fa7cb99c3)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
roman-numerals-py is a module providing utilities for working with
well-formed Roman numerals. python3-sphinx relies on this now, so add it
as a recipe.
(From OE-Core rev: 43b4e995769de54e47b0a98ce841b143a877f87d)
Signed-off-by: Trevor Gamblin <tgamblin@baylibre.com>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Due to some musl build issues with 2025.01.0, we skip this version and
move forward to 2025.02.0 directly.
Changes in 2025.01.0
--------------------
* Added LLVM/Clang support for the sandbox architecture.
* Enabled command execution from the sandbox command line.
* Improved TFTP with dentry caching and default-disabled window size.
* Introduced hardening features: register zeroing, stack variable
initialization, and malloc buffer zeroing.
* Enhanced AM625 support with network support, watchdog driver, and
bootsource detection.
Changelog: https://lore.barebox.org/barebox/Z4oUYdHXEAtnkySC@pengutronix.de/T/#u
Changes in 2025.02.0
--------------------
* Several memory overflow fixes for different filesystems.
* Added 'Security Considerations' guideline:
https://www.barebox.org/doc/latest/user/security.html
* Added FIT image build target for booting barebox 2nd stage from a
U-Boot with the bootm command (for development purpose).
* AM625 1st stage support including DDR, clock and power domain drivers.
* Added support for the AM625-SK board
* Added support for the Pine64 PineTab 2 (Rockchip)
* CVE's fixed:
- CVE-2025-26721
- CVE-2025-26722
- CVE-2025-26723
- CVE-2025-26724
- CVE-2025-26725
Changelog: https://lore.barebox.org/barebox/Z7iJIYuoxZAja_F7@pengutronix.de/T/#u
(From OE-Core rev: 8a526783e31d9fbb65ffdf234607fa6229543f8d)
Signed-off-by: Enrico Jörns <ejo@pengutronix.de>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
