summaryrefslogtreecommitdiffstats
path: root/bitbake
Commit message (Collapse)AuthorAgeFilesLines
* bitbake: bitbake: fix deprecated threading.Thread.setDaemonTim Orling2023-01-244-4/+4
| | | | | | | | | | | | | | | | | Deprecated in Python 3.10: https://docs.python.org/3/whatsnew/3.10.html#deprecated https://github.com/python/cpython/pull/25174 Fixes warnings like: ...bitbake/lib/bb/ui/uievent.py:68: DeprecationWarning: setDaemon() is deprecated, set the daemon attribute instead self.t.setDaemon(True) (Bitbake rev: 323f6ce27a1bfd7159e72f29684674ff495dedee) Signed-off-by: Tim Orling <tim.orling@konsulko.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: data_smart: Small optimisation to _findVar()Richard Purdie2023-01-241-7/+9
| | | | | | | | | | | | | Some users of _findVar don't need the override data and even getVarFlag doesn't need it in some common cases (parsing=True). Rearrange the code as the current overridedata approach doesn't need to be in the _findVar code anyway. This removes some search overhead from a critical path. (Bitbake rev: fcb64e1138a20eb19560af3fc5d1fa748cc9cf34) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: data: Add support for new BB_HASH_CODEPARSER_VALS for cache ↵Richard Purdie2023-01-242-12/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | optimisation Currently the codeparser cache ends up being extended for every parse run since there are values in the functions such as the result of os.getpid() from LOGFIFO in OE-Core. Digging into that issue, there are also lots of similar but different functions being parsed where the change might just be a path to WORKDIR, a change in PN or PV or something like DATE/TIME. There is no reason we have to use these changing values when computing the dependenies of the functions. Even with a small tweak like: BB_HASH_CODEPARSER_VALS = "LOGFIFO=/ T=/ WORKDIR=/ DATE=1234 TIME=1234 PV=0.0-1 PN=nopn" the cache is reduced from ~4.6MB, increasing by ~300kb for every parse run to around 1.3MB and remaining static for oe-core and meta-oe. In my local build, admittedly heavily experimented with, the cache had grown to 120MB. The benefits of doing this are: * faster load time for bitbake since the cache is smaller to read from disk and load into memory * being able to skip saving the cache upon shutdown * lower memory footprint for bitbake * faster codeparser data lookups (since there is less data to search) We only use these special values when passing code fragments to the codeparser to parse so the real variable values should otherwise be used in the hash data. The overall effect of this change, combined with others to avoid saving unchanged cache files can be ~2s on a ~16s parse on my local system and results in a more responsive feeling bitbake. It also allows parsing performance to be investigated more consistently. (Bitbake rev: f24bbaaddb36f479a59a958e7fc90ef454c19473) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: cooker: Fix parsing race around cache handlingRichard Purdie2023-01-241-8/+8
| | | | | | | | | | | | | When draining the result queue from the parsing processes, cache objects can be created even if they are then immediately destroyed. The reset in the sync code needs to happen after any objects have been created. Change the ordering to fix this. This ordering has caused various cache errors, particularly when interrupting parsing with Ctrl+C. (Bitbake rev: f45a94e6720dacf7f51ac147c115a6f608769093) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: cache: Only write files if we have dataRichard Purdie2023-01-241-3/+11
| | | | | | | | | By writing the cache files only if there is data to write, we can save a bit of time. (Bitbake rev: abeff1f80bb1c690b92d535d472dff9df7a56067) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: cooker: Fix siggen recipe cache race issueRichard Purdie2023-01-241-2/+1
| | | | | | | | | We need to reset the cache before the start() call which starts the parsing processs, tweak the code to ensure this is the case. (Bitbake rev: 4712d6237df5d2188238294fbdb9f107b068a3a7) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: server/process: Fix lockfile contents check bugRichard Purdie2023-01-241-1/+1
| | | | | | | | We need to check against the first line of the file, fix the typo. (Bitbake rev: 4abc598fb01d426394f4222dfc752e620a8e1b7b) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: fetch2/tests: Add parameter to recipe_uriPavel Zhukov2023-01-201-1/+1
| | | | | | | | | | | | While the parameter is not required it allows testing of possible regression in fetcher code when parameter specified and mirrors are used. (Bitbake rev: 1a21918049091a6d77426dbf8868ffdc14ba1003) Signed-off-by: Pavel Zhukov <pavel@zhukoff.net> Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: fetch2/tests: Add test for MercurialPavel Zhukov2023-01-181-0/+44
| | | | | | | | | | | Basic test for mercurial functionality including PREMIRRORONLY with disabled network (Bitbake rev: c0e349a5fc92e9c90afc53800c7e83495393ff79) Signed-off-by: Pavel Zhukov <pavel@zhukoff.net> Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: fetch2: kill parameters in uri_find_decodedPavel Zhukov2023-01-181-0/+1
| | | | | | | | | | | | | Fixes: File "/bitbake/./lib/bb/fetch2/__init__.py", line 446, in uri_replace if uri_decoded[loc][k] != uri_find_decoded[loc][k]: KeyError: 'module' (Bitbake rev: 80421abd5bf3f1f751219c050fa93970cf1f2088) Signed-off-by: Pavel Zhukov <pavel@zhukoff.net> Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: server/process: Improve lockfile handling at exitRichard Purdie2023-01-141-4/+5
| | | | | | | | | | | | | | | | | | | | | | | | If memory resident bitbake is active and the build directory is renamed upon build completion, several bad things can happen: * the old build directory could be re-created to contain a lockfile leaving an empty directory behind * a lockfile for a new build could be found and attempt to be locked This patch avoids creating an empty directory (not perfectly, but should work in the majority of cases - an empty directory is cosmetic). It also now compares the lock file contents to it's own pid and just exits if it doesn't match, it is clearly then belonging to some new process. This will be combined with bitbake shutdown calls on the autobuilder to ensure "saved" build directories, or build directories being deleted by clobberdir don't do strange things. (Bitbake rev: b986eac18b6a8bf633f5ef15f32f68de4c86173b) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: persist_data: Handle sqlite error when cachefile path is too longYoann Congal2023-01-131-1/+20
| | | | | | | | | | | | | | | | | | | Sqlite can't open the cachefile when its path is too long (>= 505 char by my tests). We do have a path length check in sanity.bbclass but this code is called before sanity checks. Treat the error in the exception instead of checking before hand in case sqlite eventually fixes this. Fixes [YOCTO #12374] (Bitbake rev: bf681d173263cd42ffc143655f61abe0573fd83c) Signed-off-by: Yoann Congal <yoann.congal@smile.fr> Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: server/process: Move heartbeat to idle threadRichard Purdie2023-01-111-22/+22
| | | | | | | | | | Rather than risk the heartbeat event code locking up the server control socket, handle it in the 'idle' thread with the other work. The aim is to remove it as a possible issue with some ongoing hangs. (Bitbake rev: 0f9a0c7853b181817bf01863a26da21412376294) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: main: Move --buildfile help at the end of "Execution" groupYoann Congal2023-01-111-4/+3
| | | | | | | | | | | | | | | Often, '--buildfile/-b' is used to mean "Do not execute anything but this recipe", so it make sense to have it in the "Execution control options" group. Fixes [YOCTO #12018]. (Original suggestion by Ross Burton) (Bitbake rev: 412a6d8701a92efe4dd6db8ec713c0013f7db64d) Signed-off-by: Yoann Congal <yoann.congal@smile.fr> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: cooker: Fix exit handling issuesRichard Purdie2023-01-111-6/+4
| | | | | | | | | | | | | The shutdown() call should definitely not be waiting for idle, since we expect execution and events to continue even after setting either shutdown state. This was causing the UI to appear to hang at Ctrl+C interrupts. Also ensure that if we reset cooker, we stop any active parser processes since these currently appear to be being left behind. (Bitbake rev: 4f73c2eb12ee074f3b7d4717380649f6ca8f3def) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: knotty: Improve shutdown handlingRichard Purdie2023-01-111-5/+10
| | | | | | | | | | | | There are three levels of shutdown, the initial "wait for current tasks", then "stop current tasks" and "exit now". Change the code so that we don't instantly exit after "stop current tasks" but allow the events to come through from the server first. The new shutdown level allows that to then be broken out of too. (Bitbake rev: af38345b91cfc8a6bb5c38f5753255e7635bfe2b) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: tinfoil: Don't wait for events indefinitelyRichard Purdie2023-01-111-1/+7
| | | | | | | | | | If for some reason the bitbake server dies, we shouldn't loop indefinitely waiting for events within tinfoil. Add a ping test and exit if things have somehow failed. (Bitbake rev: 32da768ae67cfe0b2d154ce4667a7cfdfa5bf4b0) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: process/cooker/command: Fix currentAsyncCommand locking/racesRichard Purdie2023-01-113-24/+44
| | | | | | | | | | | | | | currentAsyncCommand currently doesn't have any locking and we have a conflict in "idle" conditions since the idle functions count needs to be zero *and* there needs to be no active command. Move the changes/checks of currentAsyncCommand to within the lock and then we can add it to the condition for idle, simplifying some of the code. (Bitbake rev: b5215887d2f8ea3f28f1ebda721bd5b8f93ec7f3) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: cooker/command: Drop async command handler indirection via cookerRichard Purdie2023-01-112-11/+2
| | | | | | | | | Indirecting the async command handler via cooker is confusing and no longer needed. Drop it to make things slightly clearer. (Bitbake rev: 4a41a7d0594e6a84a67b9de70a505858aebcd84a) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: Group and reorder options in bitbake helpYoann Congal2023-01-091-100/+122
| | | | | | | | | | | | | Fixes [YOCTO #12018]. Also, I have included some small fixes: * added a '.' at the end of sentence where it was missing * split some long lines (Bitbake rev: 9257c48c3e36daaecb5e15da22d0bed24865f02c) Signed-off-by: Yoann Congal <yoann.congal@smile.fr> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: cooker: Clean up inotify idle handlerRichard Purdie2023-01-062-8/+3
| | | | | | | | | We no longer need to abstract the inotify callback handler, remove the abstraction and simplify/clean up the code. (Bitbake rev: af4ccab8acc49e91bf7647f209d69f4858618466) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: cooker: Rework the parsing results submissionRichard Purdie2023-01-061-11/+15
| | | | | | | | | | | | | The loop submitting the parser results was not efficient on many core systems as may of the parsers could block for a long time waiting to send the results. While a result was pending, the code wouldn't parse further jobs. Change the code to parse further jobs even if the results can't be submitted and lower the result submission timeout to keep the parsers busy. (Bitbake rev: 9ece4a2e406509bd89dbce8dac80a02e600b0ecf) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: lib/bb: Update thread/process locks to use a timeoutRichard Purdie2023-01-056-36/+40
| | | | | | | | | | | | | | | | | | | | | The thread/process locks we use translate to futexes in Linux. If a process dies holding the lock, anything else trying to take the lock will hang indefinitely. An example would be the OOM killer taking out a parser process. To avoid bitbake processes just hanging indefinitely, add a timeout to our lock calls using a context manager. If we can't obtain the lock after waiting 5 minutes, hard exit out using os._exit(1). Use _exit() to avoid locking in any other places trying to write error messages to event handler queues (which also need locks). Whilst a bit harsh, this should mean we stop having lots of long running processes in cases where things are never going to work out and also avoids hanging builds on the autobuilder. (Bitbake rev: d2a3f662b0eed900fc012a392bfa0a365df0df9b) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: command: Ensure that failure cases call finishAsyncComandRichard Purdie2023-01-021-2/+2
| | | | | | | | | | | | | | | | | There are a couple of failure cases that runCommands needs to better handle, ensuring finishAsyncCommand is called. This doesn't matter if the server is about to shut down but for memory resident bitbake and with threading enabled, correctness is more important this could could in theory lead to problems with the recent code changes. By using the idleFinish class, it ensures the current async command is terminated correctly and the various state pieces around commands finishing are called. This also makes the code more uniform matching the other exception handling code. (Bitbake rev: 367a83ed46c7fbcdd06579b6cc3a6e48a89ca7fb) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: cookerdata: Fix previous commit to use a string, not a generatorRichard Purdie2023-01-021-1/+1
| | | | | | | | | | The previous commit was injecting a generator object instead of a string, which happened to fix the issue but we should fix it properly! Thanks to Christopher Larson for spotting. (Bitbake rev: 36589f13c5babb3b2af82666c8a96338e6ea4eb9) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: cookerdata: Fix cache/reparsing issueRichard Purdie2023-01-011-2/+2
| | | | | | | | | | When setting the LAYERSERIES_COMPAT and LAYERSERIES_CORENAMES variables, we need to be deterministic. The random ordering from the sets was causing unexpected reparses. (Bitbake rev: 8c405c97430ac830837e25438e8795f6f7abbdaa) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: knotty: Ping the server/cooker periodicallyRichard Purdie2022-12-311-1/+11
| | | | | | | | | | We're seeing failures where the UI hangs if the server disappears. Ping the cooker/server if we've not had any events in the last minute so we can check if it is still alive. (Bitbake rev: 6567ad6181f9e39812097f0154647e4b38238fdd) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: server/process: Run idle commands in a separate idle threadRichard Purdie2022-12-314-50/+97
| | | | | | | | | | | | | | | | | | | | | | | | | When bitbake is off running heavier "idle" commands, it doesn't service it's command socket which means stopping/interrupting it is hard. It also means we can't "ping" from the UI to know if it is still alive. For those reasons, split idle command execution into it's own thread. The commands are generally already self containted so this is easier than expected. We do have to be careful to only handle inotify poll() from a single thread at a time. It also means we always have to use a thread lock when sending events since both the idle thread and the command thread may generate log messages (and hence events). The patch depends on previous fixes to the builtins locking in event.py and the heartbeat enable/disable changes as well as other locking additions. We use a condition to signal from the idle thread when other sections of code can continue, thanks to Joshua Watt for the review and tweaks squashed into this patch. We do have some sync points where we need to ensure any currently executing commands have finished before we can start a new async command for example. (Bitbake rev: 67dd9a5e84811df8869a82da6a37a41ee8fe94e2) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: server/process: Add locking around idle functions accessesRichard Purdie2022-12-311-5/+14
| | | | | | | | | In preparation for adding splitting bitbakes work into two threads, add locking around the idle functions list accesses. (Bitbake rev: a9c63ce8932898b595fb7776cf5467d3c0afe4f7) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: event: Always use threadlockRichard Purdie2022-12-312-55/+35
| | | | | | | | | | | | | | | | With the move to a server idle thread, we always need threading. The existing accessor functions could end up turning this off! I was going to hold the lock whilst changing it, check if the value was already set, cache the result and also fix the event code to always release the lock with a try/finally. Instead, disable the existing functions and use a with: block to handle the lock, keeping things much simpler. (Bitbake rev: 645c9d3b50e55f69b222cc338373cdfd91d524ce) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: server/process: Improve idle loop exit codeRichard Purdie2022-12-313-17/+20
| | | | | | | | | | | | | | When idle handlers want to exit, returning "False" isn't very clear and also causes challenges with the ordering of the removing the idle handler and marking that no async command is running. Use a specific class to signal the exit condition allowing clearer code and allowing the async command to be cleared after the handler has been removed, reducing any opportunity for races. (Bitbake rev: 102e8d0d4c5c0dd8c7ba09ad26589deec77e4308) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: cooker: Ensure commands clean up any parser processesRichard Purdie2022-12-311-0/+3
| | | | | | | | | When finishing a command, we need to ensure any parsing processes that may have been started are cleaned up before we reset the cooker state. (Bitbake rev: 6569ab64bea35de21acc89053ba76e2828163f3f) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: command: Tweak finishAsyncCommand ordering to avoid racesRichard Purdie2022-12-311-1/+1
| | | | | | (Bitbake rev: 89435442946767cfe58eedde363802add8f1ab29) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: server/process: Improve exception and idle function loggingRichard Purdie2022-12-311-0/+4
| | | | | | | | | | | | | | | Currently if the idle functions loop suffers a traceback, it is silently dropped and there is no log message to say what happened. This change at least means the traceback is in the cooker log, making some debugging possible. Add some logging to show when handlers are added/removed to allow a better idea of what the server code is doing from the server log file. (Bitbake rev: 9cf3102dc36513124fe5ead2f1e448b51833b6ac) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: cooker/cookerdata: Rework the way the datastores are resetRichard Purdie2022-12-312-18/+22
| | | | | | | | | | | | | | | | | | | | | | | | As far as I could tell, the current code could result in some strange situations where some data was set back to the original data store copy but the multiconfig data was not restored. There are also some changes made to the datastore which did not persist. The data store was also being reset at every client reset, which seems a little excessive if we can reset it to the original condition properly. Move the __depends -> __base_depends rename into databuilder along with the __bbclasstype change so these are saved in the original data. Tweak the databuilder code to be clearer and easier to follow on which copies are where, then save copies of all the mc datastores. Finally, drop the cache invalidation upon reset for the base config as we shouldn't need that now (oe-selftest -r tinfoil works with memory resident bitbake which was the original reproducer requiring that change). (Bitbake rev: 5f8b9b9c35b4ec0c8c539bf54ca85f068f4a5094) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: event: Add enable/disable heartbeat codeRichard Purdie2022-12-313-2/+15
| | | | | | | | | | | Currently heartbeat events are always generated by the server whilst it is active. Change this so they only appear when builds are running, which is when most code would expect to be executed. This removes a number of races around changes in the datastore which can happen outside of builds. (Bitbake rev: 8c36c90afc392980d999a981a924dc7d22e2766e) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: knotty: Avoid looping with tracebacksRichard Purdie2022-12-311-3/+1
| | | | | | | | | | If there are events queued and there is an exception in the main loop of the UI code, it will print tracebacks on the console indefinitely. Avoid that by improving the loop exit conditions. (Bitbake rev: 2d0940b920a22b244f3ba6849c7cd019578386b4) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: cache: Drop reciever side counting for SiggenRecipeInfoRichard Purdie2022-12-301-7/+8
| | | | | | | | | | Joshua Watt pointed out maintaining the counting on both sides of the connection isn't needed. Remove the receiver side counting and simplify the code, also allowing errors if the counts do go out of sync. (Bitbake rev: aeacfd391903fe68ae600470fc2bbad0502d401e) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: tinfoil: Ensure CommandExit is handledRichard Purdie2022-12-291-1/+1
| | | | | | | | | | By inspection, tinfoil handles two of the three command exit cases but one is missing. Add the CommandExit case in case this is the cause of one of our recipetool/devtool hangs. Regardless, the fix is necessary. (Bitbake rev: eadddd94835b6b6a8517dfed3d29e6dbb2d35988) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: cooker: Ensure cache is cleared for partial resetsRichard Purdie2022-12-291-0/+3
| | | | | | | | | | We're still seeing occasional SiggenRecipeInfo coherency issues, add some further reset points into the parsing code to ensure the cache is cleared before reparsing. (Bitbake rev: 26ed783caf11dc9ebf53d3790681eb44c0c360f0) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: event: builtins fix for 'd' deletionRichard Purdie2022-12-294-26/+17
| | | | | | | | | | | | | | | | | | | I've been seeing event handlers where 'd' seems to disappear half way through event handler execution. This is problematic when multiple threads are active since this code assumes single threading. The easiest fix is to change the handler function calls to contain d as a parameter as we do elsewhere for other functions. This will break any non-text handlers but I was only able to spot one of those in runqueue. It will also break handlers than call functions that assume 'd' is in the global namespace but those failures should be obvious and we can fix those to pass d around. This solution avoids manipulating builtins which was always a horrible thing to do anyway and solves the issue without needing locking, thankfully. (Bitbake rev: 1e12f0a4b592dacd006d370ec29cd71d2a44312e) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: cache/siggen: Fix cache issues with signature handlingRichard Purdie2022-12-292-1/+3
| | | | | | | | | | | | | There is a bug in the current cache code where the restored data structures were "inverted" leading to some very weird issues, not sure how anything worked like that, this patch fixes it. Also fix some issues with multiconfig cache ordering problems by resetting the stream counters when appropriate. (Bitbake rev: cd06beb948eff5eaf2d474f5b127d51a61b0b2ef) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: server/process: Add bitbake.sock race handlingRichard Purdie2022-12-211-1/+11
| | | | | | | | | | | | | | | | We've seen cases where the bitbake.sock file appears to disappear but the server continues to hold bitbake.lock. The most likely explaination is that some previous build directory was moved out the way, a server there kept running, eventually exited and removed the sock file from the wrong directory. To guard against this, save the inode information for the sock file and check it before deleting the file. The new code isn't entirely race free but should guard against what is a rare but annoying potential issue. (Bitbake rev: b02ebbffdae27e564450446bf84c4e98d094ee4a) 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: cache: Allow compression of the data in SiggenRecipeInfoRichard Purdie2022-12-212-0/+76
| | | | | | | | | | | | | | | | | | | | | | | | | The data in SiggenRecipeInfo is large and has a lot of duplication. The size causes a few problems, impacting: - bitbake's overall memory usage - the amount of data sent over IPC between parsing processes and the server - the size of the cache files on disk - the size of "sigdata" hash information files on disk The data consists of strings (some large) or frozenset lists of variables. To reduce the impact we can: a) deplicate the data b) pass references to the object on the second usage (e.g. over IPC or saving into pickle). This patch does this for SiggenRecipeInfo mostly behind the scenes but we do need a couple of reset points so that streamed data is written correctly on the second usage. (Bitbake rev: 9a2b13af483c20763d6559a823310954884f6ab1) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: command: Add ping commandRichard Purdie2022-12-211-0/+6
| | | | | | | | Add a simple ping command so the UI can check the server is still there. (Bitbake rev: fd3359de0b9f18fac187a629df203be0b2c87545) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: README: add required python version for bitbakeFrank de Brabander2022-12-211-0/+2
| | | | | | | | (Bitbake rev: 8f9402b291421ebcbf0a3ab97791c87af4b3f36e) Signed-off-by: Frank de Brabander <debrabander@gmail.com> Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: bitbake-user-manual: remove "OEBasic" signature generatorMichael Opdenacker2022-12-211-9/+8
| | | | | | | | | | | Removed in BitBake through https://git.openembedded.org/openembedded-core/commit/?id=3667e589ba16eb261cfd72c2b11429f482c239f6 (Bitbake rev: 50261fe047dfb41c3ce9d91b9b8245ce465d69b3) Signed-off-by: Michael Opdenacker <michael.opdenacker@bootlin.com> Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: bitbake-user-manual: double colon fixMichael Opdenacker2022-12-211-2/+1
| | | | | | | | (Bitbake rev: 4f57853f46423f9e50b0140cd3d4aaffdcd5a08d) Signed-off-by: Michael Opdenacker <michael.opdenacker@bootlin.com> Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: fetch2/git: Clarify the meaning of namespaceMarek Vasut2022-12-212-3/+4
| | | | | | | | | | | | | | Namespace in this context means a branch, a tag, etc., clarify it in the description. Also, fix a typo "a any", replace with plain "any". This patch is based of feedback on new applied patch d32e5b0e ("fetch2/git: Prevent git fetcher from fetching gitlab repository metadata") (Bitbake rev: b4999425c812b25cb359d5163d11e3c1b030dc28) Signed-off-by: Marek Vasut <marex@denx.de> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
generated by cgit v1.2.3-54-g00ecf (git 2.39.0) at 2024-06-11 09:24:43 +0000