bitbake-setup deduces top directory from BBPATH, which, if set, interferes with
the tests' own setup.
(Bitbake rev: e974d42eb5229f755e14b46a00ad06b23b53e143)
Signed-off-by: Alexander Kanavin <alex@linutronix.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This makes maintaining and extending them easier.
(Bitbake rev: 16dc8e3dad7dde7e7651cce13549e61574cafba1)
Signed-off-by: Alexander Kanavin <alex@linutronix.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Previously bitbake-setup was checking out 'detached commits' using
fetcher's nobranch feature, as that is the only option when only a revision is in the config.
Branches are optional, but beneficial, as
- checkout directory will be on a branch, making it easier for users
to understand where they are if they need to make changes (also
bitbake will print branch information instead of saying 'HEAD:sha').
- supply chain security! Enforcing a branch means any specified revision
has to be on it, and no one can sneak in (accidentally or deliberately!)
some dangling commit, or something from their private branch in the same repo.
(Bitbake rev: 45ed9b9faebdaa8cb7cc8dd2a6d51ec8eea06e73)
Signed-off-by: Alexander Kanavin <alex@linutronix.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This basically calls install-buildtools from oe-core/poky, but
it ensures via command line parameters that the installation
location is stable and the downloads are preserved for reproducibility:
$ bin/bitbake-setup install-buildtools
Loading settings from /home/alex/bitbake-builds/bitbake-setup.conf
======
Buildtools archive is downloaded into /home/alex/bitbake-builds/yocto-master-testing/buildtools-downloads/20250319141333 and its content installed into /home/alex/bitbake-builds/yocto-master-testing/buildtools
... (output from install-buildtools script)
======
It also detects when buildtools are already installed, and will direct
users what to do:
======
alex@Zen2:/srv/work/alex/bitbake$ bin/bitbake-setup install-buildtools
Loading settings from /home/alex/bitbake-builds/bitbake-setup.conf
Buildtools are already installed in /home/alex/bitbake-builds/yocto-master-testing/buildtools.
If you wish to use them, you need to source the the environment setup script e.g.
$ . /home/alex/bitbake-builds/yocto-master-testing/buildtools/environment-setup-x86_64-pokysdk-linux
You can also re-run bitbake-setup install-buildtools with --force option to force a reinstallation
======
This commits includes fixes by Gyorgy Sarvari <skandigraun@gmail.com>
https://github.com/kanavin/bitbake/pull/2
(Bitbake rev: 3fe3096847046110c72b23fce37fb4a459b1d748)
Signed-off-by: Alexander Kanavin <alex@linutronix.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Run like this:
alex@Zen2:/srv/work/alex/bitbake$ bin/bitbake-selftest -v bb.tests.setup
test_setup (bb.tests.setup.BitbakeSetupTest.test_setup) ... ok
----------------------------------------------------------------------
Ran 1 test in 9.223s
OK
The test does a basic run-through of init, then status/update
on an unchanged configuration, then status/update on a
configuration changed via new commits to the test layer,
then status/update on configuration changed via the top
level json config file.
Note that nothing whatsoever is fetched from the network;
the test relies entirely on synthetic data contained inside
itself, including minimal stubs for oe-setup-build and
bitbake-config-build. This data is used to create temporary
git repositories then clone them via local filesystem URIs.
Later on this can be supplemented by an oe-selftest that
tests bitbake-setup against real config files in the
official configuration repository and real layers,
templates and fragments.
(Bitbake rev: e3aa3eb46bd3196fa5415fa36e3737636fd6a1c0)
Signed-off-by: Alexander Kanavin <alex@linutronix.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* lastpids has not been used for almost 10 years.
* There is no longer any need to use running_pids to keep track of the
order the pids in running_tasks were added as dicts are guaranteed to
remember the insertion order since Python 3.7.
(Bitbake rev: 562b5bf0be2883144391e7030a9dce6a233802ac)
Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Having multiple builtin config fragments for the same variable
(eg OE_FRAGMENTS = "... machine/A ... machine/B") is not supported.
Warn the user to make them fix this but continue with the normal
variable evaluation : the last affectation "wins".
Added warning looks like:
WARNING: Multiple builtin fragments are enabled for machine via variable OE_FRAGMENTS: machine/qemux86-64 machine/test machine/qemux86-64. This likely points to a mis-configuration in the metadata, as only one of them should be set. The build will use the last value.
(Bitbake rev: 1c12aa23f6678dc289fc0e0d8b4dad311bd39c35)
Signed-off-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>
Imagine a machine fragment machine/A and a configuration which sets:
MACHINE = "B"
MACHINE:forcevariable = "C"
As I understand it, the fragment behaviour was intended to replace the
MACHINE = "B", so the override would still be active. The current code
replaces all variable overrides.
parsing=True, switches to the other behaviour, which I believe was the
design intent and the behaviour users would expect.
This is useful to allow test configurations to override a MACHINE setting
without change the fragments which would complicate the test code.
(Bitbake rev: f65bc6aaf4c11bc7e566c895209c093627a3015b)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Simple tests for various ways to include and require configuration
files.
(Bitbake rev: bdcb67824172ed5cd76fa0274dc3d27aeb52e77c)
Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
There is no reason to call file.flush() as the last call within a file
context manager since ending the context will close the file and thus
flush it.
(Bitbake rev: 90d5ce926d434d60d6df28b7d77b3cbc9b62ce14)
Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Tags for bitbake 2.8.6 and 2.8.7 have been removed from the git: use
some other ones.
(Bitbake rev: dcf12947954f3184d99fbf9813b3f3f667dacc5f)
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
In case a recipe specifies a git SRC_URI along with revision and tag, but only the
revision is present in the local clone without the tag (because it was tagged after
it was cloned), then unpacking fails with the following error:
... rev-list -n 1 1.0 failed with exit code 128, output:\nfatal: ambiguous argument \'1.0\': unknown revision or path not in the working tree
This happens because the during the download step only the revision's presence is
verified to decide if the repository needs to be updated.
To avoid this, check also if the tag is present in the local repository, when the "tag"
tag is specified.
(Bitbake rev: 546b347b4d3d82c01ecc99f45296f66e44638adc)
Signed-off-by: Gyorgy Sarvari <skandigraun@gmail.com>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Refactoring prints, print() functions were eliminated from all loops and it uses
"\n".join(...) in a single print() call for better performance.
(Bitbake rev: c32c3d9b83818661e12f3e437563ab4e1fa05e15)
Signed-off-by: Benjamin Szőke <egyszeregy@freemail.hu>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Optimize printing in footer update with use a StringIO buffer and it
prints content to terminal in a single call in every cycle.
(Bitbake rev: 32ba622d78f20b231f30f848379b4bbc3d7414da)
Signed-off-by: Benjamin Szőke <egyszeregy@freemail.hu>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Prior to commit aa84a900e ("cooker: Ensure delays are accurately transfered to
the idle loops from runqueue"), this was necessary. But now retval is returned
directly.
(Bitbake rev: c2eb4336fe10b1bf8bbc6291c32ca362840f39e1)
Signed-off-by: Chris Laplante <chris.laplante@agilent.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Marks bb.utils.explode_deps as callable from filter functions
(Bitbake rev: bb07003641e76de994482f7835a432f20297af96)
Signed-off-by: Joshua Watt <JPEWhacker@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Adds a new setVarFilter() API to the data store allowing filters to be
applied to variables.
Note that filters are applied to the non-override part of the variable name
so a filter set against RDEPENDS would apply against RDEPENDS:${PN} and
friends.
The filter function is applied before returning the final variable value.
(Bitbake rev: a9471c10d1de039474ddb4738abd286b928d82f4)
Signed-off-by: Joshua Watt <JPEWhacker@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Add the python API for applying filters to a string and being able to
register functions as filters.
Filter functions are pure functions where an input is translated into
an output and there are no external data accesses. This means translations
can be cached as they won't change.
(Bitbake rev: 7d25d7511ca14213eea78ee739d260295cfa4045)
Signed-off-by: Joshua Watt <JPEWhacker@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When parsing failures occur, trap KeyError to avoid these kinds
of tracebacks (from a parsing error in meta-ti).
bb.parse.ParseError: ParseError at /srv/pokybuild/yocto-worker/check-layer-nightly/build/meta-ti/meta-ti-bsp/recipes-kernel/linux/linux-ti-mainline_git.bb:6: Could not inherit file classes/${KERNEL_BASE_CLASS}.bbclass
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/srv/pokybuild/yocto-worker/check-layer-nightly/build/lib/bb/command.py", line 123, in runAsyncCommand
self.cooker.updateCache()
File "/srv/pokybuild/yocto-worker/check-layer-nightly/build/lib/bb/cooker.py", line 1639, in updateCache
if not self.parser.parse_next():
File "/srv/pokybuild/yocto-worker/check-layer-nightly/build/lib/bb/cooker.py", line 2314, in parse_next
self.shutdown(clean=False, eventmsg=str(exc))
File "/srv/pokybuild/yocto-worker/check-layer-nightly/build/lib/bb/cooker.py", line 2209, in shutdown
read_results()
File "/srv/pokybuild/yocto-worker/check-layer-nightly/build/lib/bb/cooker.py", line 2195, in read_results
self.result_queue.get(timeout=0.25)
File "/usr/lib/python3.10/multiprocessing/queues.py", line 122, in get
return _ForkingPickler.loads(res)
File "/srv/pokybuild/yocto-worker/check-layer-nightly/build/lib/bb/cache.py", line 338, in __setstate__
setattr(self, key, self._restore(state[key], pid))
File "/srv/pokybuild/yocto-worker/check-layer-nightly/build/lib/bb/cache.py", line 318, in _restore
ret[dep] = map[mapnum]
KeyError: 156
(Bitbake rev: 750c68ee7ee3f3d4518348e4c948243504880770)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Fixes [YOCTO 15917]
When fetching a git repository the .gitattributes file is scanned, checking if LFS
support is required for the repository. This scan checks if the word "lfs" is present
in the file, however the used regex doesn't account for comments, which makes some
repositories[1] be to misidentified as requiring LFS support (which fails fetching, in case
lfs support isn't installed on the build host).
To avoid it, change the used regex to ignore lines starting with "#".
[1]: e.g. https://github.com/MicrochipTech/cryptoauthlib
(Bitbake rev: 7917a758fc328747116c7899e689171bd0efc883)
Signed-off-by: Gyorgy Sarvari <skandigraun@gmail.com>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When recreating the uri in wget's checkstatus method, we only use the
scheme, netloc and path. This completely strips the query parameters
from the final URI and potentially breaks the checking functionality
from certain fetchers.
This is the case for the Azure storage fetcher, as it requires a SAS
token that is formatted as a series of query parameters. The error
manifests itself when using a private storage account as a PREMIRROR or
SSTATE_MIRROR (since regular SRC_URI won't run the checkstatus).
This problem is present in scarthgap, but wasn't in kirkstone.
CC: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
(Bitbake rev: 096301250455e2a83bdd818a56317c62436c9981)
Signed-off-by: Philippe-Alexandre Mathieu <pamathieu@poum.ca>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This API is no longer used and bitbake has moved beyond Python 2.7.3 as
the minimum version, so remove it.
(Bitbake rev: 0eb7b5dd512ed8d8b77b5779858b9fbd99edb4a4)
Signed-off-by: Joshua Watt <JPEWhacker@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Python 3.14 changes the default multiprocessing context from "fork" to
"forkserver"; however bitbake heavily relies on "fork" to efficiently
pass data to the child processes. As such, make "fork" context in the bb
namespace and use it in place of the normal multiprocessing module.
Note that multiprocessing contexts were added in Python 3.4, so this
should be safe to use even before Python 3.14
[YOCTO #15858]
(Bitbake rev: 62be9113d98fccb347c6aa0a10d5c4ee2857f8b6)
Signed-off-by: Joshua Watt <JPEWhacker@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The upstream servers are having issues so switch to our own shadow copy
of the repo.
(Bitbake rev: e910c7cd24fd366d6756641cd599c4efeb492e2a)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Use a more logical name for the profile reports and put each report
into a separate file since people struggle to discover them currently.
(Bitbake rev: a8145c84e0899285a5e6a809f1515118b002b106)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Running "time bitbake -pP idle" with a valid cache shows around 800,000
calls to enum creation from python's signal.py. We don't care about this
overhead and it adversely affects cache load time quite badly.
Try and use _signal directly, falling back to signal, which avoids
this overhead we don't need and makes cache loading much faster.
(Bitbake rev: ee5fce67ce35b025c68aa61e2e758903269ee346)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Starting with python 3.12, profiling now stays enabled over threads yet
you can't extract the profile data in the threads themselves, which makes it
difficult to use for our use case.
Our main loop starts the idle loop which starts the parsing threads and this
means we can't profile in the main loop and the parsing threads or the idle
loop at the same time due to this.
Add options to the commandline so you can specify which piece of bitbake
you want to enable profiling for. This allows some profiling with python 3.12
onwards rather than crashing.
(Bitbake rev: 09f29a4968841ee5070f70277ba8c253bb14f017)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
It is possible for multple bitbake threads to empty ui_queue in parallel
leading to duplicate console messages and much confusion when debuging.
Use the lock to extract the queue data which means only one thread will
processing, removing the duplicate out of order messages.
(Bitbake rev: 945095602e40d54efb8de494218f4a2b25c9969f)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We have code duplication in the way we handle profiling of code sections.
Create a common function in utils which covers this.
The main loop and idle loop profile files were also reversed. Fix this and the naming,
removing a couple of unused variables containing the profile log names in the process too.
(Bitbake rev: b4f6bae97ac9607420fc49fd4c9e957d89c9a5f3)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If the server is quickly stopped, we see tracebacks in the locks
due to the file not existing. Hide these as they're not errors.
(Bitbake rev: a7e1a07e9ef7e6f6a1bcaf567d7916a8ee1ef087)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The test behavior did not change visibly though.
"bitbake-selftest bb.tests.runqueue" passes completely, just like before.
(Bitbake rev: 1751aed08f8472f20fcfbadbb09d35f951904952)
Signed-off-by: Gyorgy Sarvari <skandigraun@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Instead of pre-partitioning which jobs will go to which parser
processes, pass the list of all jobs to all the parser processes
(efficiently via fork()), then used a shared counter of the next index
in the list that needs to be processed. This allows the parser processes
to run independently of needing to be feed by the parent process, and
load balances them much better.
(Bitbake rev: 373c4ddaf0e8128cc4f7d47aefa9860bd477a00f)
Signed-off-by: Joshua Watt <JPEWhacker@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If parsing ends early and unexpectedly, add some internal values
to better understand why/how it failed.
(Bitbake rev: 775f9720a17c9f3d6815d42c733ab5aaaa53749c)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We sometimes see hangs in parsing during automated testing. It appears that
SIGINT was sent to the underlying processes which see KeyboardInterrupt but
they're stuck trying to write into the results pipe. The SIGINT was probably
from some kind of parsing failure which doens't happen often, hence the hang
being rare (in the incompatible license selftests from OE).
This patch:
* sets a flag to indicate exit upon SIGINT so the exit is more graceful
and a defined exit path
* empties the results queue after we send the quit event
* empties the results queue after the SIGINT for good measure
* increases the 0.5s timeout to 2s since we now have some very slow to
parse recipes due to class extensions (ptests)
This should hopefully make the parsing failure codepaths more robust.
(Bitbake rev: 5b533370595f83b87e480bace3e0b42c9ba61e22)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We have other places in the code where we need to take filemode/mask
information from a bitbake variable and turn it into a real python
number. Turn this internal code into public API in bb.utils and
add some tests for it.
(Bitbake rev: d89e30fb2fb15b09f2cb95c4e5aa9f749ca257ea)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The bitbake worker/server IPC is asynchronous, but tinfoil only has
functionality to wait for a response on the build_targets() call.
Extract the bulk of the "wait for events and handle errors" logic to a
standalone wait_for wrapper, which is the build_targets code without the
extra_events or event_callback arguments (for now).
Then use this to create a build_file_sync() helper that just wraps the
existing build_file() with @wait_for.
(Bitbake rev: bacd125a9da66cd205f6ba2ab17930b976e82150)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
It makes sense to allow the shallow clone mirror tarball name to include the tag
name so that tags can be added to existing urls and the tarballs will be maintained
correctly. The code already allows this to be done easily just by moving the tag
handling code.
(Bitbake rev: 68fce3be14e4dd801661f4ef302d229fb16a04b5)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Currently, tags are fetched as just a name, which works but means they're not
seen as tags by git commands like git describe. Instead, fetch them as refs/tags/XXX
which means such commands then work correctly.
(Bitbake rev: c1f30ad61f5e55beb377451887bbbc5cb569f2e5)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The display window scrolling mechanism we were using was failing in one case
and needed in another. After trying various approaches, this one with
window.scrollTo seems to work and fixes the test failures.
(Bitbake rev: f1175778108a559e1dd0d55cb68f42816c86f393)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When reviewing proposed fragments to add settings for DISTRO and MACHINE,
RP noted that such fragments only add clutter and overhead, and there's
no need to maintain them as separate files.
Rather when bitbake sees 'fragmentvar/fragmentvalue' it can expand that into
FRAGMENTVAR = "fragmentvalue".
To achieve that, 'addfragments' directive is extended with a parameter
that sets the name of the variable that holds definitions of such
built-in fragments, for example like this:
"machine:MACHINE distro:DISTRO"
Then each enabled fragment name is matched against these definitions and the
respective variable is set, e.g. 'machine/qemuarm' would match
'machine:MACHINE' and result in MACHINE set to 'qemuarm'.
This happens before any fragment files are looked up on disk,
and no such lookup happens if there was a match, which should prevent
possible misuse of the feature. So the builtin fragment definition
is also an allowlist for them.
Please also see the patches for oe-core that show an application of the feature.
(Bitbake rev: 3b9d7bea915dc7f10e845854f1dae325743f9456)
Signed-off-by: Alexander Kanavin <alex@linutronix.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This will allow setting the variable in oe-core such that it matches
S, which in turn will allow dropping S from almost all git:// fetching recipes,
and not having to set it in newly written ones.
(Bitbake rev: 378db0fdd95f8704fccd852452555bfddcad384d)
Signed-off-by: Alexander Kanavin <alex@linutronix.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
