| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
| |
Rewrite the include and include_all sections to drive home the fact
that the include_all directive is relevant in only very specific
cases, and not something developers should expect to use in normal
operation.
(Bitbake rev: cac938c07622aaabbbb388ed935efc4b09143ba2)
Signed-off-by: Robert P. J. Day <rpjday@crashcourse.ca>
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: 093fec5f019cc0a181782961452a8ccb9a19459d)
Signed-off-by: Philippe-Alexandre Mathieu <pamathieu@poum.ca>
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
======
(Bitbake rev: 37d99d94b8d76d66673529b7118ea86a923d6d98)
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: 12676b84fca45bece686b8da2feec75ea2f191c2)
Signed-off-by: Alexander Kanavin <alex@linutronix.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Preamble
========
The latest iteration of this patchset is available at
https://github.com/kanavin/bitbake
I recommend taking the patches from there to ensure that
you are not trying out outdated code.
For the rationale and design guidelines please see this message:
https://lists.openembedded.org/g/openembedded-architecture/message/1913
Left out for now but will be done later:
- base bitbake configs (a way to declare the common parts between several bitbake build configurations just once, like a parent 'class')
(this is inspired by a similar mechannism in yocto-autobuilder)
- official configuration repository (this probably depends on oe-core being
populated with a rich, useful set of fragments, and providing sstate for
official configurations)
- documentation
Amble *scratch* HOWTO
=====================
1. If you don't know where to start, list available configurations, and pick one:
===
alex@Zen2:/srv/work/alex/bitbake$ bin/bitbake-setup list
Created a new settings file in /home/alex/bitbake-builds/bitbake-setup.conf.
Loading settings from /home/alex/bitbake-builds/bitbake-setup.conf.
Fetching configuration registry git://github.com/kanavin/bitbake-setup-configurations.git;protocol=https;branch=main;rev=main into /home/alex/bitbake-builds/.bitbake-setup-cache/configurations
Available configurations:
poky-alex Poky reference distribution, with alex fixes
poky-kirkstone Poky reference distribution, kirkstone long term support release (supported until April 2026)
poky-ng Poky-ng configuration: like poky but built from individual repositories
Run 'init' with one of the above configuration identifiers to set up a build.
===
2. Then build is initialized this way:
===
alex@Zen2:/srv/work/alex/bitbake$ bin/bitbake-setup init poky-alex
Loading settings from /home/alex/bitbake-builds/bitbake-setup.conf.
Initializing a poky-alex build in /home/alex/bitbake-builds/poky-alex
Fetching configuration registry git://github.com/kanavin/bitbake-setup-configurations.git;protocol=https;branch=main;rev=main into /home/alex/bitbake-builds/.bitbake-setup-cache/configurations
Fetching layer/tool repository poky into /home/alex/bitbake-builds/poky-alex/layers/poky
Fetching layer/tool repository meta-alex into /home/alex/bitbake-builds/poky-alex/layers/meta-alex
==============================
Setting up bitbake configuration gadget in /home/alex/bitbake-builds/poky-alex/build-gadget
Bitbake configuration summary: This configuration is intended for building gadget.
Usage instructions and additional information in /home/alex/bitbake-builds/poky-alex/build-gadget/README
==============================
Setting up bitbake configuration gizmo in /home/alex/bitbake-builds/poky-alex/build-gizmo
Bitbake configuration summary: This configuration is intended for building gizmo.
Usage instructions and additional information in /home/alex/bitbake-builds/poky-alex/build-gizmo/README
===
Note: 'init' sub-command can also take a path or a URL with a configuration file directly.
You can see how those files look like here:
https://github.com/kanavin/bitbake-setup-configurations
3. The above message refers to a one-liner shell script that would build the targets
specified in the chosen configuration:
===
alex@Zen2:/srv/work/alex/bitbake$ cat /home/alex/builds/poky-alex/build-gadget/build-targets
. /home/alex/builds/poky-alex/build-gadget/init-build-env && bitbake core-image-minimal
===
4. You can also source the bitbake environment, and then subsequent status/update commands
will not require a --build-dir option telling bitbake-setup where the initialized build is.
5. To check if the build configuration needs to be updated, run:
===
alex@Zen2:/srv/work/alex/bitbake$ bin/bitbake-setup status --build-dir ~/bitbake-builds/poky-alex/
Loading settings from /home/alex/bitbake-builds/bitbake-setup.conf.
Fetching configuration registry git://github.com/kanavin/bitbake-setup-configurations.git;protocol=https;branch=main;rev=main into /home/alex/bitbake-builds/.bitbake-setup-cache/configurations
Configuration in /home/alex/bitbake-builds/poky-alex/ has not changed.
===
If the configuration has changed, you will see the difference:
===
...
Configuration in /home/alex/builds/poky-alex has changed:
--- /home/alex/builds/poky-alex/config/poky-alex.conf.json 2024-12-16 11:43:24.077446096 +0100
+++ /home/alex/builds/poky-alex/config-tmp-asoubw5u/poky-alex.conf.json 2024-12-16 11:47:43.237104405 +0100
@@ -7,7 +7,7 @@
"uri": "git://git.yoctoproject.org/poky-contrib"
}
},
- "rev": "akanavin/sstate-for-all"
+ "rev": "akanavin/bitbake-setup-testing"
},
"path": "poky"
}
===
If the configuration has not changed, but layer revisions referred to it have (for example
if the configuration specifies a tip of a branch), you will see that too:
===
...
Layer repository git://git.yoctoproject.org/poky-contrib checked out into /home/alex/builds/poky-alex/layers/poky updated revision akanavin/sstate-for-all from 6b842ba55f996b27c900e3de78ceac8cb3b1c492 to aeb73e29379fe6007a8adc8d94c1ac18a93e68de
===
6. If the configuration has changed, you can bring it in sync with:
===
alex@Zen2:/srv/work/alex/bitbake$ bin/bitbake-setup update -build-dir ~/bitbake-builds/poky-alex/
Default parameter values are in /home/alex/.bitbake-setup/config - adjust as needed.
Fetching configuration repository git://github.com/kanavin/bitbake-setup-configurations.git;protocol=https;branch=main;rev=main into /home/alex/.bitbake-setup/configurations
Layer repository git://git.yoctoproject.org/poky-contrib checked out into /home/alex/builds/poky-alex/layers/poky updated revision akanavin/bitbake-setup-testing from d174acad934f8ad1fe303abc5705733e15542859 to a3d2ee10045f8c1151d680ad97994c5d6cf51ece
Fetching layer/tool repository poky into /home/alex/builds/poky-alex/layers/poky
Setting up bitbake configuration gadget in /home/alex/bitbake-builds/poky-alex/build-gadget
Existing bitbake congfiguration directory renamed to /home/alex/builds/poky-alex/build-gadget/conf-backup.20241216115007
The bitbake configuration has changed:
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
hashserv communication
The issue itself is sporadic but aborts the build with an uncaught exception.
The stack trace of python calls that resulted in this exception/failure was:
File: 'exec_func_python() autogenerated', lineno: 2, function: <module>
0001:
*** 0002:sstate_report_unihash(d)
0003:
File: '(...)/poky/meta/classes/sstate.bbclass', lineno: 882, function: sstate_report_unihash
0878: report_unihash = getattr(bb.parse.siggen, 'report_unihash', None)
0879:
0880: if report_unihash:
0881: ss = sstate_state_fromvars(d)
*** 0882: report_unihash(os.getcwd(), ss['task'], d)
0883:}
0884:
0885:#
0886:# Shell function to decompress and prepare a package for installation
File: '(...)/poky/lib/bb/siggen.py', lineno: 651, function: report_unihash
0647: method = self.method
0648: if tid in self.extramethod:
0649: method = method + self.extramethod[tid]
0650:
*** 0651: data = self.client().report_unihash(taskhash, method, outhash, unihash, extra_data)
0652: new_unihash = data['unihash']
0653:
0654: if new_unihash != unihash:
0655: hashequiv_logger.debug('Task %s unihash changed %s -> %s by server %s' % (taskhash, unihash, new_unihash, self.server))
File: '(...)/poky/lib/bb/asyncrpc/client.py', lineno: 139, function: wrapper
0135: pass
0136:
0137: def _get_downcall_wrapper(self, downcall):
0138: def wrapper(*args, **kwargs):
*** 0139: return self.loop.run_until_complete(downcall(*args, **kwargs))
0140:
0141: return wrapper
0142:
0143: def _add_methods(self, *methods):
File: '/usr/lib/python3.9/asyncio/base_events.py', lineno: 642, function: run_until_complete
0638: future.remove_done_callback(_run_until_complete_cb)
0639: if not future.done():
0640: raise RuntimeError('Event loop stopped before Future completed.')
0641:
*** 0642: return future.result()
0643:
0644: def stop(self):
0645: """Stop running the event loop.
0646:
File: '(...)/poky/lib/hashserv/client.py', lineno: 70, function: report_unihash
0066: m["taskhash"] = taskhash
0067: m["method"] = method
0068: m["outhash"] = outhash
0069: m["unihash"] = unihash
*** 0070: return await self.invoke({"report": m})
0071:
0072: async def report_unihash_equiv(self, taskhash, method, unihash, extra={}):
0073: await self._set_mode(self.MODE_NORMAL)
0074: m = extra.copy()
File: '(...)/poky/lib/bb/asyncrpc/client.py', lineno: 104, function: invoke
0100: async def proc():
0101: await self.socket.send_message(msg)
0102: return await self.socket.recv_message()
0103:
*** 0104: return await self._send_wrapper(proc)
0105:
0106: async def ping(self):
0107: return await self.invoke({"ping": {}})
0108:
File: '(...)/poky/lib/bb/asyncrpc/client.py', lineno: 82, function: _send_wrapper
0078: async def _send_wrapper(self, proc):
0079: count = 0
0080: while True:
0081: try:
*** 0082: await self.connect()
0083: return await proc()
0084: except (
0085: OSError,
0086: ConnectionError,
File: '(...)/poky/lib/bb/asyncrpc/client.py', lineno: 70, function: connect
0066: await self.socket.send("")
0067:
0068: async def connect(self):
0069: if self.socket is None:
*** 0070: self.socket = await self._connect_sock()
0071: await self.setup_connection()
0072:
0073: async def close(self):
0074: if self.socket is not None:
File: '(...)/poky/lib/bb/asyncrpc/client.py', lineno: 55, function: connect_sock
0051: import websockets
0052:
0053: async def connect_sock():
0054: try:
*** 0055: websocket = await websockets.connect(uri, ping_interval=None)
0056: except (OSError, asyncio.exceptions.TimeoutError, websockets.InvalidHandshake, websockets.InvalidURI) as exc:
0057: raise ConnectionError("Could not connect to websocket: %s" % exc) from exc
0058: return WebsocketConnection(websocket, self.timeout)
0059:
File: '/usr/local/lib/python3.9/dist-packages/websockets/asyncio/client.py', lineno: 444, function: __await_impl__
0440: async with asyncio_timeout(self.open_timeout):
0441: for _ in range(MAX_REDIRECTS):
0442: self.connection = await self.create_connection()
0443: try:
*** 0444: await self.connection.handshake(*self.handshake_args)
0445: except asyncio.CancelledError:
0446: self.connection.close_transport()
0447: raise
0448: except Exception as exc:
File: '/usr/local/lib/python3.9/dist-packages/websockets/asyncio/client.py', lineno: 104, function: handshake
0100: # receiving a response, when the response cannot be parsed, or when the
0101: # response fails the handshake.
0102:
0103: if self.protocol.handshake_exc is not None:
*** 0104: raise self.protocol.handshake_exc
0105:
0106: def process_event(self, event: Event) -> None:
0107: """
0108: Process one incoming event.
File: '/usr/local/lib/python3.9/dist-packages/websockets/client.py', lineno: 315, function: parse
0311:
0312: def parse(self) -> Generator[None]:
0313: if self.state is CONNECTING:
0314: try:
*** 0315: response = yield from Response.parse(
0316: self.reader.read_line,
0317: self.reader.read_exact,
0318: self.reader.read_to_eof,
0319: )
File: '/usr/local/lib/python3.9/dist-packages/websockets/http11.py', lineno: 238, function: parse
0234:
0235: try:
0236: status_line = yield from parse_line(read_line)
0237: except EOFError as exc:
*** 0238: raise EOFError("connection closed while reading HTTP status line") from exc
0239:
0240: try:
0241: protocol, raw_status_code, raw_reason = status_line.split(b" ", 2)
0242: except ValueError: # not enough values to unpack (expected 3, got 1-2)
Exception: EOFError: connection closed while reading HTTP status line
(Bitbake rev: 5ba7c2f0797a72536a81f57276d4e5c75f23011c)
Signed-off-by: Pedro Ferreira <Pedro.Silva.Ferreira@criticaltechworks.com>
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>
|
|
|
|
|
|
|
|
|
|
|
|
| |
description
After commit d591d7633fe8 ("fetch/git: Rework tag parameter handling"),
update the description of the tag= parameter for the Git fetcher.
(Bitbake rev: 85b31a55d114a1430868233d56573b470fef8908)
Signed-off-by: Antonin Godard <antonin.godard@bootlin.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>
|
|
|
|
|
|
|
|
|
|
|
| |
Remove rev's "master" default value. Mention that it must match SRCREV,
if set.
Reported-by: Quentin Schulz <quentin.schulz@cherry.de>
(Bitbake rev: 2519b317e4afb1686f907274715a9e2b9c6457f4)
Signed-off-by: Antonin Godard <antonin.godard@bootlin.com>
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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
code duplication
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>
|
|
|
|
|
|
| |
(Bitbake rev: f68b513c38fa33c89236efbaab2674a25983d5e1)
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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The current default value for BB_PRESSURE_MAX_CPU is 500, which is
really low for most systems. Provide a value of 15000 which limits the
load average without being extremely slow either.
Provide similar values for BB_PRESSURE_MAX_IO and
BB_PRESSURE_MAX_MEMORY. Mention that these should be adjusted depending
on the need, and warn about the potential spam of messages when the
value is too low.
(Bitbake rev: 09baa527dafca4bdf56a9189f6b3f7512886cbfb)
Signed-off-by: Antonin Godard <antonin.godard@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
|
| |
BB_GIT_DEFAULT_DESTSUFFIX
This variable was recently added with 378db0fdd95f ("fetch2/git: allow
overriding default unpack directory with a variable").
(Bitbake rev: a569be0d369cb8b9457beedfeb75b984f751ba5a)
Signed-off-by: Antonin Godard <antonin.godard@bootlin.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>
|
|
|
|
|
|
|
|
|
|
|
| |
unpacking
Also, drop an obsolete S = WORKDIR/git note.
(Bitbake rev: 3884b386cda649030f59e3040dd08e6aa2ec50cf)
Signed-off-by: Alexander Kanavin <alex@linutronix.de>
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>
|
|
|
|
|
|
|
|
|
| |
Update version to 2.15.0 for the development series and features needed for
toolchain selection in OE.
(Bitbake rev: c2f29c9475c4b9cdd12af1f8610f2675f8fdd964)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Calling oe-debuginfod in a build failed:
...
$ oe-debuginfod
|Getting sysroot...
|Error: NOTE: Reconnecting to bitbake server...
|NOTE: Retrying server connection (#1)... (18:55:53.009687)
|path-to-build/tmp/work/x86_64-linux/elfutils-native/0.192/recipe-sysroot-native doesn't exist.
|Have you run 'bitbake elfutils-native -caddto_recipe_sysroot'?
...
The script oe-debuginfod calls bitbake-getvar to get sysroot, the
output of bitbake-getvar was mixed with info output of bitbake
...
NOTE: Reconnecting to bitbake server...
NOTE: Retrying server connection (#1)... (18:55:53.009687)
...
Set logger level to logging.WARNING to skip info output
for quiet
(Bitbake rev: 873c524e1a33846df8f34b7c87b298349277b3d5)
Signed-off-by: Hongxu Jia <hongxu.jia@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
| |
Add support for automatically promoting class inherits to deferred inherits
by listing them in the BB_DEFER_BBCLASSES variable.
(Bitbake rev: 8e741b2e885a12d119788d04aa4efcd724dd6bfa)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Now that deferred inherits are extension specific, we can pass this
list to an event, which our metadata can use to set class overrides
earlier (as an example).
There are limitations to this, the list of classes is unexpanded and
recursive classes are not visible. There isn't much that can be done
about this, the ones we are interested in would usually be visible
at the top level (such as class extensions).
(Bitbake rev: 205d461c05fc7b4a7c81039af3bc3fd71cbb982c)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently deferred inherits get processed once for all class extensions
as a minor speed optimisation. Unfortunately this limits our options for
being able to report deferred classes to our code.
There are two challenges with using our deferred classes in OE at present.
One is that PACKAGECONFIG values don't work well with class overrides like
class-native if there are deferred classes based on PACKAGECONFIG, such
as python support. The second is that toolchain selection is proving
problematic to implement due to interactions between the toolchain deferred
inherit, the class extensions and class overrides being very late.
By changing deferred inherits to be recipe extension specific, we open
the way to generate events and "peek" at where things will end up,
allowing the class overrides to be set earlier.
The class extension code is updated to use a deferred inherit for the
class extension inheriting so that it is still inherited last.
(Bitbake rev: 29277cf4d88eb4dfa9572851177d009eab5afd0c)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
| |
Add Walnascar as a supported release manual, and move Styhead to the
outdated release manuals.
(Bitbake rev: 629aff734794568510c30939a4584cee2e0185ec)
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>
|
|
|
|
|
|
|
|
|
|
|
|
| |
AZ_SAS token should be prefixed with a question mark. Add a sanity check for
this and fix the documentation.
[YOCTO #15882]
(Bitbake rev: 22011765202514600314732b97f1bb938e21f585)
Signed-off-by: Robbin Van Damme <robbinvandamme@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
| |
The project is switching the way handle our CDN provision of sstate objects,
update the URL accordingly.
(Bitbake rev: 3372524cb961d95993b27fe4a8d794cdb7255e09)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
| |
(Bitbake rev: 6e1434d93d489aa4bab07777a7a9dc58ba0ca5a7)
Signed-off-by: Stefan Koch <stefan-koch@siemens.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
|
| |
shallow cloning
- Since `ud.path` contains in that case the `PREMIRRORS` prefix path,
this change ensures that a correct symlink is set up.
(Bitbake rev: 37ed18e45aa17406162efc5ee3ddb2d6b33d07b9)
Signed-off-by: Stefan Koch <stefan-koch@siemens.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
| |
class
(Bitbake rev: d934763f91b9bda85f273a44f12a04a3ca19fc28)
Signed-off-by: Stefan Koch <stefan-koch@siemens.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
| |
Some .deb files contain uncompressed data tarballs which do not have an
additional file extension after `.tar`. Add support for such cases while
preserving the existing behaviour.
(Bitbake rev: e3834deb427ceb1d1ae9a96c1e0dec990d7f3805)
Signed-off-by: Isaac True <isaac.true@emlix.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
|
| |
In scenequeue data generation loop, progress bar update in each cycle cause
a significant loss of speed. Remove progress bar update in for loop. It was
become quite fast (faster 30 times, about) without progress bar update.
(Bitbake rev: f775e53f1196e3e5d0ded277c061c5c268b3b28d)
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>
|
|
|
|
|
|
|
|
|
|
|
|
| |
The default adapters for sqlite datetime are deprecated as of Python
3.12, so implement our own.
[YOCTO #15333]
(Bitbake rev: 38a1d715bf58acbc9cb21eed413b3542c81cf15a)
Signed-off-by: Joshua Watt <JPEWhacker@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
| |
(Bitbake rev: f06112286ad141f0d5e4ae75a29f83cdd564c2ec)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
By switching from print() to bb.plain() to print failing task logs, we
allow them to be saved in BB_CONSOLELOG.
Fixes [YOCTO #15798]: This allows AB reproducibility test to save the
full log of the failing tasks and helps debugging.
(Bitbake rev: d3b3ad32da7c7ebf61814fc807f8667a37aa149b)
Signed-off-by: Yoann Congal <yoann.congal@smile.fr>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
| |
Update the fixtures generator table and update the fixtures removing
styhead and adding whinlatter.
(Bitbake rev: 72b1dee84df641cb24bc726f2dfe8f1cf1555247)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
works for tag containing slash
Add a test case to ensure git shallow fetch succeeds for SRC_URI
with tag containing slash.
For example, we want to succeed for SRC_URI like below:
SRC_URI = "git://salsa.debian.org/debian/debianutils.git;protocol=https;branch=master;tag=debian/${PV}"
See the following link for more information:
https://bugzilla.yoctoproject.org/show_bug.cgi?id=15862
(Bitbake rev: 919d4cf6e688e67229c46d30c84d523b21936377)
Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|