summaryrefslogtreecommitdiffstats
path: root/bitbake/lib/bb/siggen.py
Commit message (Collapse)AuthorAgeFilesLines
* bitbake: siggen: Fix rare file-checksum hash issueRichard Purdie2024-09-051-1/+1
| | | | | | | | | | | | | | There is a subtle issue with full pathnames being included in the file checksums since the sorting might be different depending upon how layers are being setup causing hash mismatches for recipes appeneded from other layers with differing directory layouts. Avoid this by filtering out to the path basename which is what is written into the sig data anyway later in the code. (Bitbake rev: 83acc21cdfdb410082c0871ac7693d29a7c5627d) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: siggen: catch FileNotFoundError everywhere and ConnectionError also ↵Martin Jansa2024-06-181-7/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | in get_unihashes * avoids long trace when BB_HASHSERVE points to non-existent socket file, e.g.: BB_HASHSERVE = "unix:///OE/no-socket.sock" or when running the build before starting the bin/bitbake-hashserv. * now it shows just warnings like it did in kirkstone many of them, e.g. 6 just for rebuilding zlib-native, but better than long trace for nonexistent socket file: WARNING: zlib-native-1.3.1-r0 do_create_spdx: Error contacting Hash Equivalence Server unix:///OE/no-socket.sock: [Errno 2] No such file or directory for existing file, but before starting bin/bitbake-hashserv: WARNING: zlib-native-1.3.1-r0 do_create_spdx: Error contacting Hash Equivalence Server unix:///OE/hashserv.sock: [Errno 111] Connection refused ERROR: An uncaught exception occurred in runqueue############################################################### | ETA: 0:00:00 Traceback (most recent call last): File "/OE/build/oe-core/bitbake/lib/hashserv/__init__.py", line 80, in create_client(addr='unix:///OE/no-socket.sock', username=None, password=None): if typ == ADDR_TYPE_UNIX: > c.connect_unix(*a) elif typ == ADDR_TYPE_WS: File "/OE/build/oe-core/bitbake/lib/bb/asyncrpc/client.py", line 241, in Client.connect_unix(path='/OE/no-socket.sock'): self.loop.run_until_complete(self.client.connect_unix(path)) > self.loop.run_until_complete(self.client.connect()) File "/usr/lib/python3.12/asyncio/base_events.py", line 687, in _UnixSelectorEventLoop.run_until_complete(future=<Task finished name='Task-6' coro=<AsyncClient.connect() done, defined at /OE/build/oe-core/bitbake/lib/bb/asyncrpc/client. py:150> exception=FileNotFoundError(2, 'No such file or directory')>): > return future.result() File "/OE/build/oe-core/bitbake/lib/bb/asyncrpc/client.py", line 152, in AsyncClient.connect(): if self.socket is None: > self.socket = await self._connect_sock() await self.setup_connection() File "/OE/build/oe-core/bitbake/lib/bb/asyncrpc/client.py", line 85, in connect_sock: sock = socket.socket(socket.AF_UNIX, socket.SOCK_STREAM, 0) > sock.connect(os.path.basename(path)) finally: FileNotFoundError: [Errno 2] No such file or directory ERROR: Running idle function Traceback (most recent call last): File "/OE/build/oe-core/bitbake/lib/hashserv/__init__.py", line 80, in create_client(addr='unix:///OE/no-socket.sock', username=None, password=None): if typ == ADDR_TYPE_UNIX: > c.connect_unix(*a) elif typ == ADDR_TYPE_WS: File "/OE/build/oe-core/bitbake/lib/bb/asyncrpc/client.py", line 241, in Client.connect_unix(path='/OE/no-socket.sock'): self.loop.run_until_complete(self.client.connect_unix(path)) > self.loop.run_until_complete(self.client.connect()) File "/usr/lib/python3.12/asyncio/base_events.py", line 687, in _UnixSelectorEventLoop.run_until_complete(future=<Task finished name='Task-6' coro=<AsyncClient.connect() done, defined at /OE/build/oe-core/bitbake/lib/bb/asyncrpc/client. py:150> exception=FileNotFoundError(2, 'No such file or directory')>): > return future.result() File "/OE/build/oe-core/bitbake/lib/bb/asyncrpc/client.py", line 152, in AsyncClient.connect(): if self.socket is None: > self.socket = await self._connect_sock() await self.setup_connection() File "/OE/build/oe-core/bitbake/lib/bb/asyncrpc/client.py", line 85, in connect_sock: sock = socket.socket(socket.AF_UNIX, socket.SOCK_STREAM, 0) > sock.connect(os.path.basename(path)) finally: FileNotFoundError: [Errno 2] No such file or directory Summary: There were 2 ERROR messages, returning a non-zero exit code. 1605616 09:29:05.369352 Parse cache valid 1605616 09:30:14.500863 Registering idle function <function BBCooker.buildTargets.<locals>.buildTargetsIdle at 0x7f43988c09a0> 1605616 09:30:14.500927 Removing idle function <bound method Command.runAsyncCommand of <bb.command.Command object at 0x7f43a961c350>> 1605616 09:30:14.573274 Exception Traceback (most recent call last): File "/OE/build/oe-core/bitbake/lib/bb/server/process.py", line 435, in idle_thread_internal retval = function(self, data, False) ^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/OE/build/oe-core/bitbake/lib/bb/cooker.py", line 1487, in buildTargetsIdle retval = rq.execute_runqueue() ^^^^^^^^^^^^^^^^^^^^^ File "/OE/build/oe-core/bitbake/lib/bb/runqueue.py", line 1651, in execute_runqueue return self._execute_runqueue() ^^^^^^^^^^^^^^^^^^^^^^^^ File "/OE/build/oe-core/bitbake/lib/bb/runqueue.py", line 1567, in _execute_runqueue if self.rqdata.prepare() == 0: ^^^^^^^^^^^^^^^^^^^^^ File "/OE/build/oe-core/bitbake/lib/bb/runqueue.py", line 1290, in prepare unihashes = bb.parse.siggen.get_unihashes(ready) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/OE/build/oe-core/bitbake/lib/bb/siggen.py", line 713, in get_unihashes with self.client() as client: File "/usr/lib/python3.12/contextlib.py", line 137, in __enter__ return next(self.gen) ^^^^^^^^^^^^^^ File "/OE/build/oe-core/bitbake/lib/bb/siggen.py", line 595, in client self._client = hashserv.create_client(self.server, **self.get_hashserv_creds()) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/OE/build/oe-core/bitbake/lib/hashserv/__init__.py", line 88, in create_client raise e File "/OE/build/oe-core/bitbake/lib/hashserv/__init__.py", line 80, in create_client c.connect_unix(*a) File "/OE/build/oe-core/bitbake/lib/bb/asyncrpc/client.py", line 241, in connect_unix self.loop.run_until_complete(self.client.connect()) File "/usr/lib/python3.12/asyncio/base_events.py", line 687, in run_until_complete return future.result() ^^^^^^^^^^^^^^^ File "/OE/build/oe-core/bitbake/lib/bb/asyncrpc/client.py", line 152, in connect self.socket = await self._connect_sock() ^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/OE/build/oe-core/bitbake/lib/bb/asyncrpc/client.py", line 85, in connect_sock sock.connect(os.path.basename(path)) FileNotFoundError: [Errno 2] No such file or directory broke the idle_thread, exiting 1605616 09:30:14.673756 Exiting (socket: True) 1605616 09:30:14.683153 Exiting as we could obtain the lock sys:1: ResourceWarning: unclosed file <_io.TextIOWrapper name='/OE/build/oe-core/bitbake-cookerdaemon.log' mode='a+' encoding='UTF-8'> sys:1: ResourceWarning: unclosed <socket.socket fd=17, family=1, type=1, proto=0> ResourceWarning: Enable tracemalloc to get the object allocation traceback (Bitbake rev: 550c86969e5a137ffef61b08a520a4855232fb1c) Signed-off-by: Martin Jansa <martin.jansa@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: siggen: Drop copy_unihashes functionRichard Purdie2024-06-071-6/+0
| | | | | | | | | | The code in OE-Core using this has been replaced with something more fit for purpose. Drop these function calls as they were never a great idea in the first place and cause IO slowdown for runqueue needing to sync the cache. (Bitbake rev: 2c8fa57778c4bd2a5c48a60b701ac57de4289cb2) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: siggen: Batch unihash_exists checksJoshua Watt2024-05-311-7/+7
| | | | | | | | | | Similar to looking up unihashes, use the batch API when checking if a unihash exists to speed up lookups (Bitbake rev: 0ac521ff37b578f7487bca0eccc7dc9e5974991b) Signed-off-by: Joshua Watt <JPEWhacker@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: siggen: Drop client pool supportJoshua Watt2024-05-311-38/+15
| | | | | | | | | | Drops support for client pools, since batching support in the client code has proven to be much more effective (Bitbake rev: 85dafaf8e070459f7de7bfb37300d8b60a27002e) Signed-off-by: Joshua Watt <JPEWhacker@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: siggen: Enable batching of unihash queriesJoshua Watt2024-05-301-3/+6
| | | | | | | | | | Uses the batching API of the client to reduce the effect of latency when making multiple queries to the server (Bitbake rev: a54734b4ac2ddb3bce004e576cf74d6ad6caf62a) Signed-off-by: Joshua Watt <JPEWhacker@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: siggen/runqueue: Report which dependencies affect the taskhashjoshua Watt2024-05-081-1/+1
| | | | | | | | | | | | | Report which task dependencies in BB_TASKDEPDATA are included in the taskhash. This allows tasks to identify which tasks dependencies may change without the task re-running. Knowing this information is important for tasks that want to transfer information from dependencies (such as SPDX) (Bitbake rev: a313b4f07727e8187526157ba039911c3f73dd46) Signed-off-by: Joshua Watt <JPEWhacker@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: siggen: Capture SSL environment for hashserverJoshua Watt2024-04-161-24/+70
| | | | | | | | | | | | | | Now that the bitbake hash server supports SSL connections, we need to capture a few environment variables which can affect the ability to connect via SSL. Note that the variables are only put in place to affect the environment while actually invoking the server [RP: Tweak to use BB_ORIGENV as well] [RP: Tweak to handle os.environ restore correctly] (Bitbake rev: 0bacf6551821beb8915513b120ae672ae8eb1612) Signed-off-by: Joshua Watt <JPEWhacker@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: siggen: Add support for hashserve credentialsJoshua Watt2024-03-231-5/+16
| | | | | | | | | | Adds support for hashserver credentials to be specified in the SignatureGenerator (Bitbake rev: 741bef3755fde7bae1386aad575ea704d9fe0969) Signed-off-by: Joshua Watt <JPEWhacker@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: siggen: Add parallel unihash exist APIJoshua Watt2024-02-191-0/+32
| | | | | | | | | Adds API to query if unihashes are known to the server in parallel (Bitbake rev: 7e2479109b40ce82507f73b4f935903f7f79fb06) Signed-off-by: Joshua Watt <JPEWhacker@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: siggen: Add parallel query APIJoshua Watt2024-02-191-34/+87
| | | | | | | | | | | | | | | | Implements a new API called get_unihashes() that allows for querying multiple unihashes in parallel. The API is also reworked to make it easier for derived classes to interface with the new API in a consistent manner. Instead of overriding get_unihash() to add custom handling for local hash calculating (e.g. caches) derived classes should now override get_cached_unihash(), and return the local unihash or None if there isn't one. (Bitbake rev: 6faf48c09a4003a31b32e450779fb8ac9cc5e946) Signed-off-by: Joshua Watt <JPEWhacker@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: bitbake-diffsigs: fix walking the task dependencies and show better ↵Martin Jansa2024-02-081-6/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | error * when comparing 2 tmp/stamps/*do_configure.sigdata* I got TypeError("filename must be a str or bytes object, or a file") but both files I was comparing were Zstandard compressed data (v0.8+), Dictionary ID: None according to "file" with TypeError catched to show which file it failed to open I got better error which shows it was trying to read "do_prepare_recipe_sysroot.sigdata" file now and after a while you might notice that it's not just the expected file, but a dict with 'path', 'sstate', 'time'. Fix that in bitbake-diffsigs but keep the TypeError and add OSError in case it will eventually walk on file which isn't zstd compressed pipecompress throws CompressionError. ERROR: Failed to open {'path': '5.15.do_prepare_recipe_sysroot.sigdata.99b12a401341a0df7c3553cb00c87a7674295496bd5c25ed71764ee0d0fb8eb8', 'sstate': False, 'time': 1707136354.991718}: filename must be a str or bytes object, or a file Traceback (most recent call last): File "bitbake/bin/bitbake-diffsigs", line 192, in <module> output = bb.siggen.compare_sigfiles(options.sigdatafile1, options.sigdatafile2, recursecb, color=color) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "bitbake/lib/bb/siggen.py", line 1039, in compare_sigfiles recout = recursecb(dep, a[dep], b[dep]) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "bitbake/bin/bitbake-diffsigs", line 102, in recursecb out2 = bb.siggen.compare_sigfiles(hashfiles[hash1], hashfiles[hash2], recursecb, color=color) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "bitbake/lib/bb/siggen.py", line 857, in compare_sigfiles raise err File "bitbake/lib/bb/siggen.py", line 853, in compare_sigfiles with bb.compress.zstd.open(a, "rt", encoding="utf-8", num_threads=1) as f: ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "bitbake/lib/bb/compress/zstd.py", line 12, in open return bb.compress._pipecompress.open_wrap(ZstdFile, *args, **kwargs) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "bitbake/lib/bb/compress/_pipecompress.py", line 59, in open_wrap raise TypeError("filename must be a str or bytes object, or a file") TypeError: filename must be a str or bytes object, or a file * if I replace zstd file with just plaintext it fails with: $ echo foo > foo $ echo foo > bar $ bitbake-diffsigs foo bar zstd: /*stdin*\: unsupported format ERROR: Process died with 1 sys:1: ResourceWarning: unclosed file <_io.BufferedReader name='foo'> with this change it shows the name of the file which it failed to uncompress: $ bitbake-diffsigs foo bar zstd: /*stdin*\: unsupported format ERROR: Failed to open sigdata file 'foo': Process died with 1 ERROR: Process died with 1 sys:1: ResourceWarning: unclosed file <_io.BufferedReader name='foo'> (Bitbake rev: f3f843a4fd6e0a9e8f6edef5dd3cf1fce29c50ba) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: siggen: Ensure version of siggen is verifiedRichard Purdie2024-01-051-0/+10
| | | | | | | | | | Since we need to change the form of the siggen function, we need to add versioning and some verison checks. This means if a newer bitbake is used with older metadata we can detect it. (Bitbake rev: 721556568413508213d22c29985e305a45a8d68a) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: siggen.py: Improve taskhash reproducibilityPaulo Neves2023-08-241-2/+8
| | | | | | | | | | | | | | | file checksums are part of the data checksummed to generate the task hash. The list of file checksums was not ordered. In this commit we make sure the task hash checksum takes a list of checksum data that is ordered by unique file name thus guaranteeing reproducibility. (Bitbake rev: 5293a1b36eeb89f57577cb709ec7f293909039a1) Signed-off-by: Paulo Neves <paulo@myneves.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: siggen: Update debugRichard Purdie2023-08-131-4/+5
| | | | | | | | | The debug in the comments was out of date. It is still useful so update the code sample to the new code needed. (Bitbake rev: fa2724069ea7028939d816cb5ccd0e7c1bed09a1) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: siggen: Fix indentationRichard Purdie2023-08-131-1/+1
| | | | | | (Bitbake rev: 9a98851ef86adea3b05c4eb7c44e7ea3fbbb4420) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: siggen: Improve runtaskdeps data to fix sstate debuggingRichard Purdie2023-08-091-48/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The runtaskdep data in siginfo files was written out with full paths to the bb files, matching bitbake's internal "unique key" ID for recipes/tasks. When originally implemented this made sense. Over time, the main use for the data in siginfo files has become to match against other siginfo files to debug changes of hash calcuations. The recipename data is not useful for this as the siginfo filenames use PN instead which can often be derived from the recipe filename but not always. It is time to throw away the 'tid' data format and switch over the use a hybrid PN form which includes the multiconfig. That can be easily stripped off in the find_siginfo code in oe-core. The other purpose of having a sortable dependency ID is retained and the multiconfig needs to be included to allow the taskhashes to be processed and calculated correctly. PN is meant to be unique between recipes, only one would ever be built so using PN in this location is fine. The one risk of this change is there isn't any compatibility to the old format. I'm not convinced we should spend time complicating the code with it. This change will change the taskhashes everywhere so the only mixing of old and new siginfo files will be either through hash equivalence or through users using the tool against old and new info files manually which will give some weird output but it should be clear they're in different formats as there would be large paths from the old files not present in the new ones. We have options to add backwards compatibility if some issue is found to need that. (Bitbake rev: 637933e2e5a59228a8d17aae4160551cab5f2f61) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: lib/bb/siggen: fix debug() callRoss Burton2023-02-241-1/+1
| | | | | | | | | | | | | | | Bitbake f68682 changed the logger's debug() method to be compatible with logging.debug(), but this caller was still using the old API where you can pass an integer as the first argument: WARNING: Invalid arguments in bbdebug: (1, 1, 'Found unihash[...]') Instead, call bbdebug() which has the priority argument. (Bitbake rev: 18d4f9e8387f7994cf6d46300e25dda1c3a593b2) Signed-off-by: Ross Burton <ross.burton@arm.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: siggen: Fix inefficient string concatenationEtienne Cordonnier2023-02-041-5/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | As discussed in https://stackoverflow.com/a/4435752/1710392 , CPython has an optimization for statements in the form "a = a + b" or "a += b". It seems that this line does not get optimized, because it has a form a = a + b + c: data = data + "./" + f.split("/./")[1] For that reason, it does a copy of data for each iteration, potentially copying megabytes of data for each iteration. Changing this line causes SignatureGeneratorBasic::get_taskhash to take 0.06 seconds instead of 45 seconds on my test setup where SRC_URI points to a big directory. Note that PEP8 recommends explicitely not to use this optimization which is specific to CPython: "do not rely on CPython’s efficient implementation of in-place string concatenation for statements in the form a += b or a = a + b" However, the PEP8 recommended form using "join()" also does not avoid the copy and takes 45 seconds in my test setup: data = ''.join((data, "./", f.split("/./")[1])) I have changed the other lines to also use += for consistency only, however those were in the form a = a + b and were optimized already. Co-authored-by: JJ Robertson <jrobertson@snap.com> (Bitbake rev: 195750f2ca355e29d51219c58ecb2c1d83692717) Signed-off-by: Etienne Cordonnier <ecordonnier@snap.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: siggen: Minor code improvementRichard Purdie2022-12-211-3/+3
| | | | | | | | | Tweak the code to remove duplication and only set if the attribute isn't already there to avoid overwriting. (Bitbake rev: 513e6c4e9233e0d0bc31e1169077fdbf9aaf4ec3) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: siggen: Clarify which fn is meantRichard Purdie2022-12-171-38/+39
| | | | | | | | | | | | | | | "fn" can mean different things in bitbake, we added support for class extensions and then mutlticonfigs by extending it. In siggen, it generally means that mc is prefixed to it and that it is a virtual filename. Replace "fn" with "mcfn" in the code to make this clearer as if I'm getting confused, everyone else likely is as well. "mcfn" is sometimes referred to as taskfn as well but mcfn is probably the easiest to understand as the taskname isn't included. (Bitbake rev: e1c1139ab90f8da1b5036db11d943daefbe87859) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: build/siggen: Rework stamps functionsRichard Purdie2022-12-171-6/+51
| | | | | | | | | | | | | | | The current method of passing either a task's datastore, or dataCaches and a filename into the stamp functions is rather horrible. Due to the different contexts, fixing this is hard but we do control the bitbake side of the API usage so we can migrate those to use other functions and then only support a datastore in the public bb.build API which is only called from task context in OE-Core. (Bitbake rev: c79ecec580e4c2a141ae483ec0f6448f70593dcf) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: siggen: Add dummy dataCaches from task context/datastoreRichard Purdie2022-12-171-37/+40
| | | | | | | | | | | | | | | One of the challenges in maintaining the code is that it sometimes uses a datacaches structure and sometimes a datastore. Rather than continue the current dual API madness, have the worker contexts create a dummy datacaches structure with the entries we need. Whilst this does need to be kept in sync with the real structure, that doesn't change and this allows the code to be simplified. With this new approach, we can unify the stamps dependency code again. (Bitbake rev: c6d325fc9b53e9d588ab273ee3c2a99a70fba42c) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: bitbake: siggen/runqueue: Switch to using RECIPE_SIGGEN_INFO ↵Richard Purdie2022-12-171-20/+19
| | | | | | | | | | | | | | | | | | | feature for signature dumping Now that we have cache support for the taskdep/gendep/lookupcache data, we can switch to use that cooker feature and skip the secondary reparse to write the sig files. This does make the initial parse longer but means the secondary one isn't needed. At present parsing with the larger cache isn't optimal but we have plans in place which will make this faster than the current reparse code being removed here. (Bitbake rev: 5951b5b56449855bc2a30146af65eb287a35fcef) (Bitbake rev: 1252e5bce51ae912ecff9dcc354a371786ff2c72) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: siggen: Directly store datacaches referenceRichard Purdie2022-12-171-0/+3
| | | | | | | | | | | It is becomming clear the siggen needs access to our cache data but we can't always obtain it in the contexts we need to. Add it directly, meaning over time we should be able to simplify the APIs and stop convoluting new ones! (Bitbake rev: 6b213590ed0e77683cf7fbce6bbe9605ddecf3d3) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: build/siggen/runqueue: Drop do_setscene referencesRichard Purdie2022-12-111-1/+1
| | | | | | | | | | do_setscene was from a different era before our modern setscene per task code. It hasn't been used for years so remove some old obsolete references to it. (Bitbake rev: ef72282298f7c4db74383c23bb0251dd06d3c6d3) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: siggen: Drop non-multiconfig aware siggen supportRichard Purdie2022-12-111-49/+0
| | | | | | | | | All siggens in common use should now support multiconfig, drop the compatibility code. (Bitbake rev: b36545b4df6d935ed312ff407d4e0474c3ed8d1a) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: siggen/cache: Optionally allow adding siggen hash data to the ↵Richard Purdie2022-12-081-0/+4
| | | | | | | | | | | | | | | bitbake cache Being able to track siggen hash construction data can be useful for cache debugging. For now, add an extra cache class which contains this information. It can be enabled in the same way as the hob data cache through a feature flag to cooker. This allows us to experiment with the data without carrying larger patches around and ultimately may allow use to have a hash mismatch debugging mode that is more easily enabled. (Bitbake rev: 0736a8a03da8b774fafbd28f746bef4705378049) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: cache/siggen: Simplify passing basehash data into the cacheRichard Purdie2022-12-081-1/+4
| | | | | | | | | | | | | The basehash data is really internal bitbake data and passing an object directly is more efficient than creating and then extracting variables. This will match the format of other data we may optionally wish to store in the cache so more to the more efficient method. Nothing I can see is using this data today (and nothing should be). (Bitbake rev: e621093a1bf37cd75ede3fb77ab6845556870fc7) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: data/siggen: Switch to use frozensets and optimizeRichard Purdie2022-11-231-3/+3
| | | | | | | | | | | | | | | | | | | | | Python handles frozensets a little more optimally than normal sets. Once we finish parsing, we don't edit this data so we can convert to them. To do that, we need to stop changing them so process ignore_deps earlier then we can freeze the data and keep it frozen. This has the side effect that we need to be careful to sort the data in some of the variables when calculating the hashes. Overall this does seem to show a decent parsing time speed improvement of 20-25% in a local test but this would be highly setup dependent. Also ensure the sigdata can handle exported frozenset and make it import back to them instead of sets. (Bitbake rev: 19475627c363a52da49ec144422c87448ff2a6c5) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: bitbake: Add copyright headers where missingRichard Purdie2022-08-121-0/+2
| | | | | | | | | Where copyright headers were not present, add them to make things clear. (Bitbake rev: 1aa338a216350a2751fff52f866039343e9ac013) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: siggen: Fix insufficent entropy in sigtask file namesJoshua Watt2022-08-091-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | Signature generation uses mkstemp() to get a file descriptor to a unique file and then write the signature into it. However, the unique file name generation in glibc is based on the system timestamp, which means that with highly parallel builds it is more likely than one might expect expected that a conflict will occur between two different builder nodes. When operating over NFS (such as a shared sstate cache), this can cause race conditions and rare failures (particularly with NFS servers that may not correctly implement O_EXCL). The signature generation code is particularly susceptible to races since a single "sigtask." prefix used for all signatures from all tasks, which makes collision even more likely. To work around this, add an internal implementation of mkstemp() that adds additional truly random entropy to the file name to eliminate conflicts. (Bitbake rev: 97955f3c1c738aa4b4478a6ec10a08094ffc689d) Signed-off-by: Joshua Watt <JPEWhacker@gmail.com> Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: cache/siggen: Add unihash cache copy functionRichard Purdie2022-06-021-0/+6
| | | | | | | | | | We see rare failures in eSDK generation with zero sized unihash cache files. This is almost certainly due to races in the cache file being updated. Add a copy function where the cache file can be copied with the lock held to avoid this. (Bitbake rev: 9e72a3915e36cb843037040cb68a82077436dbef) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: bitbake-diffsigs: break on first dependent task differenceSchmidt, Adriaan2022-05-101-0/+1
| | | | | | | | | | | | | | compare_sigfiles() recursively calculates differences on all dependent tasks with changed hashes. This is done in arbitrary/alphabetical order, and only the last of those results is returned, while everything else is discarded. This changes the behavior to instead return the first difference and not calculate any more, which significantly speeds up diffs of tasks with many dependencies. (Bitbake rev: ea6a676c9aa2864c2eff40eea41ba09ce903a651) Signed-off-by: Adriaan Schmidt <adriaan.schmidt@siemens.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: siggen: Drop pointless break statementRichard Purdie2022-04-211-1/+0
| | | | | | (Bitbake rev: 42809f6acb79e39042e81d54c28efb92b7481e44) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: bitbake-diffsigs: make finding of changed signatures more robustSchmidt, Adriaan2022-04-141-5/+5
| | | | | | | | | | | | | | | | | In `runtaskhashes`, the keys contain the absolute paths to the recipe. When working with shared sstate caches (where these absolute paths can be different) we see that compare_sigfiles does not identifiy a changed hash of a dependent task as "changed", but instead as "removed"&"added", preventing the function from recursing and continuing the comparison. By calling `clean_basepaths` before comparing the `runtaskhashes` dicts, we avoid this. (Bitbake rev: 7358378b90b68111779e6ae72948e5e7a3de00a9) Signed-off-by: Adriaan Schmidt <adriaan.schmidt@siemens.com> Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: siggen: Add missing reset handler to hashserv signature generatorRichard Purdie2022-03-261-0/+6
| | | | | | | | | When we have a client connection, we should close that connection when reset() is called on the siggen. Add the missing function. (Bitbake rev: 770b4ea81b6126b0830e51649c40f7a46c64132a) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: cooker/siggen: Support exit calls and use for hashserv clientRichard Purdie2022-03-261-0/+9
| | | | | | | | | | | | | We have shutdown functions within the async client code but the siggen doesn't currently call them. We notice on python 3.10 (such as on fedora35) that at exit, there is a stray asyncio process left behind. Usually this doesn't cause problems but it could potentially be a cause of a hang. For general cleanliness and completness, add in hooks to call the exit handler. (Bitbake rev: 9ee3fb95330003878fbd64b3ce8897aad96fcd0f) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: siggen: Improve ambiguous use of 'dependent'Richard Purdie2022-03-231-1/+1
| | | | | | | | | I'd never spotted this until it was pointed out but the task isn't dependent, it is a dependency. Fix this confusing reference. (Bitbake rev: 93395559c9dda734a3dec9ffd9bb2156a71a2c17) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: bitbake: Replace remaining "abort" usageScott Murray2022-02-211-1/+1
| | | | | | | | | | | | | | | | In line with the inclusive language migration defined at: https://wiki.yoctoproject.org/wiki/Inclusive_language replace the remaining usage of "abort" in documentation, error messages, and comments with halt/fail/exit as appropriate. A couple of external Javascript API calls in Toaster remain, as they cannot currently be changed. (Bitbake rev: bc27762bf3ffb4a20b58eace5302438c4a526626) Signed-off-by: Scott Murray <scott.murray@konsulko.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: bitbake: Rename basehas and taskhash filtering variablesScott Murray2022-02-211-24/+40
| | | | | | | | | | | | | | | | | | | | | In line with the inclusive language migration defined at: https://wiki.yoctoproject.org/wiki/Inclusive_language rename: BB_HASHBASE_WHITELIST -> BB_BASEHASH_IGNORE_VARS BB_HASHTASK_WHITELIST -> BB_TASKHASH_IGNORE_TASKS the derived code variables basewhitelist and taskwhitelist have been renamed to basehash_ignore_vars and taskhash_ignore_tasks, respectively. [RP: Added compatibility mapping code and tweaked naming] (Bitbake rev: efaafc9ec2e8c0475e3fb27e877a1c0a5532a0e5) Signed-off-by: Scott Murray <scott.murray@konsulko.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: siggen: Ensure dumpsig output is deterministicRichard Purdie2021-12-091-8/+8
| | | | | | | | | Currently the console output for signature dumps e.g. with bitbake-dumpsig isn't deterministic. Add some sorting to improve that. (Bitbake rev: a663440b1623f97c9c169df5566e429fbc932a53) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: fetch2/checksum/siggen: Fix taskhashes not tracking file directoriesRichard Purdie2021-11-081-1/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently if you have something like: SRC_URI = "file://foobar;subdir=${S}" and a file like: foobar/1/somefile and then move it to: foobar/2/somefile the task checksums don't reflect/notice this. The file-checksum fields encode two pieces of data, the file path and whether or not the file exists. Changing the code which uses these fields is problematic. We can however add a "/./" path element which means "include the bit after the marker in the checksum" which the path walking code can use to mark which bits of the path are visible to the fetcher. I'm not convinced this is great design but it does appear to work. (Bitbake rev: b4975d2ecf615ac4c240808fbc5a3f879a93846b) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: siggen: Fix type conversion issuesRichard Purdie2021-10-171-11/+16
| | | | | | | | | | | | | | | The switch to using json has messed up the type handling as the code does assume that set()s are present. Add a decoder to reconstruct the set() objects. Also fix the change of tuples to lists for the file checksums and fix an existing type bug where dicts insteads of lists was used. Drop some old siginfo format handling code which is now long since obsolete. (Bitbake rev: 2d704842c0928f8dbe78fd081042aa7280af96be) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: siggen: Change file format of siginfo files to use zstd compressed jsonRichard Purdie2021-10-141-12/+17
| | | | | | | | | | | | | | | | | | | | | | Since OE is about to change to zstd compression of sstate, it would make it timely to convert the siginfo files from pickle which isn't reproducible to json which is both reproducible and also human readable. At the same time add zstd compression. This makes the siginfo files smaller, reprodubicle and easier to debug. Backwards compatibility mixing the two formats hasn't been supported since in reality if sstate changes at the same time, files will be in one format or the new one but comparing mixed formats won't make much sense. Since json doesn't support sets, we translate them into lists in the files themselves. We only use sets in bitbake since it makes things easier in the internal code, sorted lists are fine for the file format. [YOCTO #13973] (Bitbake rev: 22c18494c9072788e6e26eb73de70378ae5c5bf5) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: siggen: Fix sorting in diff outputRichard Purdie2021-09-261-7/+7
| | | | | | | | | The diff output isn't deterministic at the moment as the sets can have differing ordering. Sort the output so it is consistent. (Bitbake rev: 117830c1d7ef3e53052fa326e1ca62c5c3946c45) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: bitbake: Switch to using new override syntaxRichard Purdie2021-08-021-2/+2
| | | | | | | | | | | | | | | | | This change updates the datastore to use the new override syntax using colons instead of underscores exclusively. It is expected layers would have to be converted to work with bitbake after this change. Supporting mixed syntax isn't possible, it is only feasible to have one internal representation of overrides. Whilst we can't warn for every possible override that may be set in the old format, show errors for _append/_prepend/_remove since those should never be present. (Bitbake rev: 7dcf317cc141dc980634f8c18bfa84f83e57206a) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: lib/bb: Add bb.utils.rename() helper function and use for renamingDevendra Tewari2021-05-061-1/+1
| | | | | | | | | | | | | | | | | | | | os.rename can fail for example an incremental build in Docker fails with: OSError: [Errno 18] Invalid cross-device link when source and destination are on different overlay filesystems. Rather than trying to fix every call site, add a wrapper in bb.utils for renames. We can then handle cross device failures and fall back to shutil.move. The reason os.rename is still used is because shutil.move is too slow for speed sensitive sections of code. [YOCTO #14301] (Bitbake rev: c5c4e49574ab2a65e06298a0a77bb98b041cf56b) Signed-off-by: Devendra Tewari <devendra.tewari@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: hashserv: Use generic ConnectionErrorPaul Barker2021-04-271-3/+3
| | | | | | | | | | The Python built-in ConnectionError type can be used instead of a custom HashConnectionError type. This will make code refactoring simpler. (Bitbake rev: 8a796c3d6d99cfa8ef7aff0ae55bb0f23bbbeae1) Signed-off-by: Paul Barker <pbarker@konsulko.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: logging: Make bitbake logger compatible with python loggerJoshua Watt2021-02-101-3/+3
| | | | | | | | | | | | | | | | | The bitbake logger overrode the definition of the debug() logging call to include a debug level, but this causes problems with code that may be using standard python logging, since the extra argument is interpreted differently. Instead, change the bitbake loggers debug() call to match the python logger call and add a debug2() and debug3() API to replace calls that were logging to a different debug level. [RP: Small fix to ensure bb.debug calls bbdebug()] (Bitbake rev: f68682a79d83e6399eb403f30a1f113516575f51) Signed-off-by: Joshua Watt <JPEWhacker@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
generated by cgit v1.2.3-54-g00ecf (git 2.39.0) at 2025-07-15 01:54:40 +0000