summaryrefslogtreecommitdiffstats
path: root/bitbake
Commit message (Collapse)AuthorAgeFilesLines
* bitbake: fetch2/clearcase: Fix tar command working directoryCHerzig@Gauselmann.de2019-12-281-1/+1
| | | | | | | | | | We need to ensure the correct working directory is used for this tar command to succeed. (Bitbake rev: e1a2a0e29a75dead3426ae083387181ad52da91f) Signed-off-by: Christian Herzig <cherzig@gauselmann.de> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: lib/bb: Optimise out debug messages from cookerRichard Purdie2019-12-161-0/+5
| | | | | | | | | | | | | | | | | We have bb.debug(2, xxx) messages in cooker which are useful for debugging but have really bad effects on performance, 640,000 calls on recent profile graphs taking tens of seconds. Rather than commenting out debug which can be useful for debugging, don't create events for debug log messages from cooker which would never be seen. We already stop the messages hitting the IPC but this avoids the overhead of creating the log messages too, which has been shown to be signficiant on the profiles. This allows the code to perform whilst allowing debug messages to be availble when wanted/enabled. (Bitbake rev: f04cd931091fb0508badf3e002d70a6952700495) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: runqueue: Only call into the migrations function if migrations activeRichard Purdie2019-12-161-1/+2
| | | | | | | | | This doesn't save much time but does make the profile counts for the function more accurate which is in itself useful. (Bitbake rev: d446fa89d206fbc6d098215163c968ea5a8cf4a9) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: runqueue: Optimise task filteringRichard Purdie2019-12-161-3/+2
| | | | | | | | | We were seeing this running thousands of times with hashequiv, do the filtering where it makes more sense and make it persist. (Bitbake rev: 2cfeb9998a8ad5b1dcda0bb4e192c5e4306dab17) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: runqueue: Optimise out pointless loop iterationRichard Purdie2019-12-161-9/+3
| | | | | | (Bitbake rev: 105d1f0748edde7753a4063e6fdc758ffc8a8a9e) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: runqueue: Optimise task migration code slightlyRichard Purdie2019-12-161-8/+9
| | | | | | | | | | | | | Move the calls to difference_update out a code level which improves efficiency significantly. Also further combine the outer loop for efficiency too. These two changes remove a bottleneck from the performance charts. (Bitbake rev: e28ec69356f1797de3e4e3fca0fef710bc4564de) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: runqueue: Fix sstate task iteration performanceRichard Purdie2019-12-161-1/+5
| | | | | | | | | | | Creating a new sorted list of sstate tasks each iteration through runqueue is extremely ineffecient and was compounded by the recent change from a list to set. Create one sorted list instead of recreating it each time. (Bitbake rev: de18824996841c3f35f54ff5ad12f94f6dc20d88) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: siggen: Split get_tashhash for performanceRichard Purdie2019-12-162-9/+25
| | | | | | | | | | | | | | | There are two operations happening in get_taskhash, the building of the underlying data and the calculation of the hash. Split these into two funtions since the preparation part doesn't need to rerun when unihash changes, only the calculation does. This split allows sigificant performance improvements for hashequiv in builds where many hashes are equivalent and many hashes are changing. (Bitbake rev: 6a32af2808d748819f4af55c443578c8a63062b3) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: runqueue: Fix task mismatch failures from incorrect logicRichard Purdie2019-12-161-1/+1
| | | | | | | | | | The "no dependencies" task case was not being correctly considered in this code and seemed to be the cause of occasionaly task hash mismatch errors that were being seen as the dependencies were never accounted for properly. (Bitbake rev: 608b9f821539de813bfbd9e65950dbc56a274bc2) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: runqueue: Rework process_possible_migrations() to improve performanceRichard Purdie2019-12-161-47/+56
| | | | | | | | | | | | | | | The looping over multiple changed hashes causes many calls to get_taskhash and get_unihash which are potentially slow and then overwritten. Instead, batch up all the tasks which have changed unihashes and then do one big loop over the changed tasks rather than each in turn. This makes worlds of difference to the performance graphs and should speed up build where many tasks are being rehashed. (Bitbake rev: c9c68d898985cf0bec6fc95f54c151cc50255cac) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: bb.utils.fileslocked: don't leak files if yield throwsChris Laplante via bitbake-devel2019-12-161-4/+5
| | | | | | | | | | | | | Discovered with a recipe under devtool. The ${S}/singletask.lock file (added by externalsrc.bbclass) was leaked, giving a warning like: WARNING: <PN>+git999-r0 do_populate_lic: /home/laplante/yocto/sources/poky/bitbake/lib/bb/build.py:582: ResourceWarning: unclosed file <_io.TextIOWrapper name='/home/laplante/yocto/build/workspace/sources/<PN>/singletask.lock' mode='a+' encoding='UTF-8'> exec_func(task, localdata) (Bitbake rev: 6beddf6214e22b4002626761031a9e9d34fb04db) Signed-off-by: Chris Laplante <chris.laplante@agilent.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: Bump minimum python version to 3.5Joshua Watt2019-12-161-2/+2
| | | | | | | | | | | | The local hash equivalence server used by bitbake requires python 3.5, so bump up the minimum required version. [YOCTO #13678] (Bitbake rev: 1412dcc077b1bea10b72fc8b525d6258dca46d97) Signed-off-by: Joshua Watt <JPEWhacker@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: siggen: Fix performance issue in get_unihashRichard Purdie2019-12-151-3/+3
| | | | | | | | | | There is a significant performance issue in get_unihash(). The issue turns out to be the lookups of setscene tasks. We can fix this by using a set() instead of the current list. (Bitbake rev: 1e561672d039ebfb8cd0e0654a44dcf48513317c) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: Revert "siggen: Fix hashequiv performance issues"Richard Purdie2019-12-121-13/+14
| | | | | | | | This reverts commit c4b8440f730c33eaf9f818b856ae81b2f1017fec. The logic in this change is flawed and needs to be re-thought. Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: siggen: Fix hashequiv performance issuesRichard Purdie2019-12-121-14/+13
| | | | | | | | | | | | | | | | | | | We're seeing huge slowdowns on large builds on the autobuilder. A qemux86 world build was running really slowly, a primary feature was lots of rehashing going on due to an sstate change which caused a rebuild when all output should be identical. This was traced to the hundreds of thousands of calls to get_unihash() from get_taskash(). If we simplify the unitaskhashes data structure, we can bypass the function call and access the data directly. In local profile charts, this significanly sped up process_possible_migrations(), both on profiles and visually. Whilst this change doesn't aid readability, it does solve an otherwise huge performance issue. (Bitbake rev: c4b8440f730c33eaf9f818b856ae81b2f1017fec) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: runqueue: Batch scenequeue updatesJoshua Watt2019-12-121-4/+7
| | | | | | | | | | | | Batch all updates to scenequeue data together in a single invocation instead of checking each task serially. This allows the checks for sstate object to happen in parallel, and also makes sure the log statement only happens once (per set of rehashes). (Bitbake rev: db033a8f8a276d864bdb2e1eef159ab5794a0658) Signed-off-by: Joshua Watt <JPEWhacker@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: siggen: Ensure new unihash propagates through the systemRichard Purdie2019-12-091-0/+1
| | | | | | | | | | Its possible the new unihash may not exist in sstate. Currently the code would create an sstate object with the old hash however this updates it to create the object with the new unihash. (Bitbake rev: abcaa1398031fa5338a43859c661e6d4a9ce863d) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: siggen: Avoid taskhash mismatch errors for nostamp tasks when ↵Richard Purdie2019-12-061-4/+8
| | | | | | | | | | | | | | | | | | | dependencies rehash An example: NOTE: recipe binutils-cross-testsuite-2.32.0-r0: task do_check: Started ERROR: Taskhash mismatch b074da4334aff8aa06572e7a8725c941fa6b08de4ce714a65a90c0c0b680abea versus 17375278daed609a7129769b74a1336a37bdef14b534ae85189ccc033a9f2db4 for /home/pokybuild/yocto-worker/qemux86-64/build/meta/recipes-devtools/binutils/binutils-cross-testsuite_2.32.bb:do_check NOTE: recipe binutils-cross-testsuite-2.32.0-r0: task do_check: Succeeded Is caused by a rehash in a dependency happening somewhere earlier in the build and the taint being reset. Change the code so that nostamp taints are preserved to avoid the issue. (Bitbake rev: 61624a3fc38e8546e01356d5ce7a09f21e7094ab) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: knotty/uihelper: Switch from pids to tids for Task event managementRichard Purdie2019-12-063-33/+43
| | | | | | | | | | | | | | | | | | | | | | | | | | | We've seen cases where a task can execute with a given pid, complete and a new task can start using the same pid before the UI handler has had time to adapt. Traceback (most recent call last): File "/home/pokybuild/yocto-worker/qemux86-alt/build/bitbake/lib/bb/ui/knotty.py", line 484, in main helper.eventHandler(event) File "/home/pokybuild/yocto-worker/qemux86-alt/build/bitbake/lib/bb/ui/uihelper.py", line 30, in eventHandler del self.running_tasks[event.pid] KeyError: 13490 This means using pids to match up events on the UI side is a bad idea. Change the code to use task ids instead. There is a small amount of fuzzy matching for the progress information since there is no task information there and we don't want the overhead of a task ID in every event, however since pid reuse is unlikely, we can live with a progress bar not quite working properly in a corner case like this. [YOCTO #13667] (Bitbake rev: e427eafa1bb04008d12100ccc5c862122bba53e0) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: runqueue: Add extra debugging when locked sigs mismatches occurRichard Purdie2019-12-041-0/+2
| | | | | | (Bitbake rev: 3aad9978be2a40d4c535a5ae092f374ba2a5f627) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: runqueue/siggen: Allow handling of equivalent hashesRichard Purdie2019-12-042-12/+45
| | | | | | | | | | | | | Based on the hashserv's new ability to accept hash mappings, update runqueue to use this through a helper function in siggen. This addresses problems with meta-extsdk-toolchain and its dependency on gdb-cross which caused errors when building eSDK. See the previous commit for more details. (Bitbake rev: 39098b4ba2133f4d9229a0aa4fcf4c3e1291286a) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: hashserv: Add support for equivalent hash reportingRichard Purdie2019-12-042-0/+44
| | | | | | | | | | | | | | | | | | | | | | | The reason for this should be recorded in the commit logs. Imagine you have a target recipe (e.g. meta-extsdk-toolchain) which depends on gdb-cross. sstate in OE-Core allows gdb-cross to have the same hash regardless of whether its built on x86 or arm. The outhash will be different. We need hashequiv to be able to adapt to the prescence of sstate artefacts for meta-extsdk-toolchain and allow the hashes to re-intersect, rather than trying to force a rebuild of meta-extsdk-toolchain. By this point in the build, it would have already been installed from sstate so the build needs to adapt. Equivalent hashes should be reported to the server as a taskhash that needs to map to an specific unihash. This patch adds API to the hashserv client/server to allow this. [Thanks to Joshua Watt for help with this patch] (Bitbake rev: 674692fd46a7691a1de59ace6af0556cc5dd6a71) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: runqueue.py: not show warning for deferred multiconfig taskKai Kang2019-11-291-1/+1
| | | | | | | | | | | | | | | | | | | When follow the instructions of multiconfig from Yocto dev manual that set in core-image-sato recipe: do_image[mcdepends] = "multiconfig:x86:arm:core-image-minimal:do_rootfs" it show too many annoying warnings look like: | WARNING: Deferring mc:x86:virtual:native:/buildarea6/kkang/poky/meta/recipes-support/libxslt/libxslt_1.1.33.bb:do_populate_sysroot | after mc:arm: virtual:native:/buildarea6/kkang/poky/meta/recipes-support/libxslt/libxslt_1.1.33.bb:do_populate_sysroot Treat them as infomations rather than warnings. (Bitbake rev: 0fb4b5153237af4a13b2c65711ab798b0de06c2f) Signed-off-by: Kai Kang <kai.kang@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: tests/runqueue: Fix to match recent task migration fixesRichard Purdie2019-11-271-1/+1
| | | | | | (Bitbake rev: 35784582fdbb2092eddec094deb6ab9c87666b5e) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: siggen: Fix hashequiv bug where new hash wasn't referenced correctlyRichard Purdie2019-11-251-0/+1
| | | | | | | | | | | If a hash is reported to the hash server, the stamp written out by the current task didn't account for any new hash the server may have provided. Fix this so the correct stamp is written. This means "bitbake X; bitbake X" no longer rebuilds lots of things when hashequiv is active. (Bitbake rev: 9dc5178f56ab8ae37e1a646c09117c503e48d072) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: runqueue: Ensure failed harddependencies in scenequeue are ↵Richard Purdie2019-11-251-1/+8
| | | | | | | | | | | | | | | | | | accounted for in migrations Setscene hard dependencies were not being correctly handled during task migration. For example, do_package of recipe X might become valid due to hashequiv yet we're still rebuilding pseudo-native, a harddep of do_package. This would mean it would try to execute that setscene task despite pseudo not being present. Fix this by ignoring tasks with failed harddependencies. This does mean stlightly more rebuilds than is optimal but it avoids build crashes. Ultimately the new runqueue model can likely better handle these cases than the older codebase could but that is for another more invasive patch. (Bitbake rev: 0dc61e8b9964f7fe41d51b6a481ca7aeaacd8bce) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: prserv/serv: Only restart the server if settings changeRichard Purdie2019-11-251-7/+13
| | | | | | | | | | The server is now restarting when running commands which doesn't make sense. Only restart if its configuration has changed. This should potentially fix various memory resident bitbake usages too. (Bitbake rev: 0d2c67abf8c92386802eccfbb6b124dd65597941) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: runqueue: Fix hash equivalence duplicate tasks runningRichard Purdie2019-11-221-4/+10
| | | | | | | | | | | | | | | The key problem is that currently running setscene tasks are not accounted for when processing task migrations. This means can allow two of the same task to execute at the same time with unpredictable effects. This change allows us to stop doing that and refactor the code slightly to make it clearer that these conditions don't arrive even with deferred tasks. (Bitbake rev: ac1922d348613ca46a1047ad5ddf755eac16d568) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: contrib/vim/indent/bitbake.vim: move it to correct directoryYi Zhao2019-11-221-0/+0
| | | | | | | | | Move bitbake.vim from bitbake/contrib/vim/indent to contrib/vim/indent. (Bitbake rev: d2654a4ad8b0b885feac697448128baf7bf8a1c9) Signed-off-by: Yi Zhao <yi.zhao@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: fetch2/clearcase: Fix warnings from python 3.8Richard Purdie2019-11-211-3/+3
| | | | | | | | | | | | | | | | bitbake/lib/bb/fetch2/clearcase.py:148: SyntaxWarning: "is" with a literal. Did you mean "=="? if command is 'mkview': bitbake/lib/bb/fetch2/clearcase.py:155: SyntaxWarning: "is" with a literal. Did you mean "=="? elif command is 'rmview': bitbake/lib/bb/fetch2/clearcase.py:159: SyntaxWarning: "is" with a literal. Did you mean "=="? elif command is 'setcs': Python 3.8 is quite correct and we so mean "==" here, fix it to avoid the warnings. (Bitbake rev: 1fab03f6e10eaa13b8a89ce0b2f9fe8ce5157189) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: utils: also use mmap for SHA256 and SHA1, for performanceRoss Burton2019-11-211-20/+14
| | | | | | | | | | md5_file() uses a mmap() window to improve performance when hashing files, so refactor the code and do the same for SHA1 and SHA256. (Bitbake rev: ecf87437ff796e17c3e4f210b5803b0136a9e8a4) Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: tests: add test for the hashing functionsRoss Burton2019-11-211-0/+26
| | | | | | | | | Add a basic test for bb.utils.md5_file() etc. (Bitbake rev: e944d02fe678f7c6b05c62419f8bceb0709f3037) Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: cooker: Remove a left-over comment about expanded_dataPeter Kjellerstedt2019-11-141-4/+0
| | | | | | | | | | This should have been removed together with expanded_data in commit e3694e73 (cooker/command: Drop expanded_data). (Bitbake rev: 33197db8abf82be240d7c1c5c9d2484a08a90849) Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: prserv: fix ResourceWarning due to unclosed socketGavin Li2019-11-141-0/+1
| | | | | | | | | | | | | | | | | | With PRSERV_HOST = "localhost:0", this message would occasionally pop up during the initial cache read: WARNING: /home/matic/ambayocto/poky/bitbake/lib/bb/cache.py:446: ResourceWarning: unclosed <socket.socket fd=10, family=AddressFamily.AF_INET, type=SocketKind.SOCK_STREAM, proto=0, laddr=('127.0.0.1', 45655)> value = pickled.load() The file location stated is irrelevant; it just happens to be wherever CPython decides to run the garbage collector. The issue is that after we fork off a PRServer, self.socket is also duplicated. The parent side of it also needs to be closed. (Bitbake rev: c45b0140c37f2d68c4fa08cd17f0321b8d6524a8) Signed-off-by: Gavin Li <gavin@matician.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: contrib/vim: Add copyright and license noticeChris Laplante via bitbake-devel2019-11-071-0/+7
| | | | | Signed-off-by: Chris Laplante <chris.laplante@agilent.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: contrib/vim: handle shell indentingChris Laplante via bitbake-devel2019-11-071-1/+13
| | | | | Signed-off-by: Chris Laplante <chris.laplante@agilent.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: contrib/vim: indenting for assignments; tweak Python indentingChris Laplante via bitbake-devel2019-11-071-3/+53
| | | | | Signed-off-by: Chris Laplante <chris.laplante@agilent.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: contrib/vim: renaming & commentsChris Laplante via bitbake-devel2019-11-071-3/+4
| | | | | Signed-off-by: Chris Laplante <chris.laplante@agilent.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: contrib/vim: don't redeclare indenterChris Laplante via bitbake-devel2019-11-071-0/+4
| | | | | Signed-off-by: Chris Laplante <chris.laplante@agilent.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: contrib/vim: Special handling of bb.fatalChris Laplante via bitbake-devel2019-11-071-1/+1
| | | | | Signed-off-by: Chris Laplante <chris.laplante@agilent.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: contrib/vim: More Python indenting; move indent file to correct ↵Chris Laplante via bitbake-devel2019-11-071-0/+21
| | | | | | | directory Signed-off-by: Chris Laplante <chris.laplante@agilent.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: fetch2/hg: Fix various runtime issuesVolker Vogelhuber2019-11-071-10/+17
| | | | | | | | | | Fix mercurial fetching after breakage from changes to the core fetcher. Fix username and password usage and setting moddir needed by setup_revisions. (Bitbake rev: 8962b27abc68427eae085624f26300108ae88aa1) Signed-off-by: Volker Vogelhuber <v.vogelhuber@digitalendoscopy.de> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: bitbake-worker child process create group before registering ↵Ivan Efimov2019-11-071-3/+5
| | | | | | | | | | | | | | | | | | SIGTERM handler The bitbake-worker child on the SIGTERM signal handling send the SIGTERM to all processes in it's process group. In cases when the bitbake-worker child got SIGTERM after registering own SIGTERM handler and before the os.setsid() call it can send SIGTERM to unwanted processes. In the worst case during SIGTERM processing the bitbake-worker child can be in the group of the process that started BitBake itself. As a result it can kill processes that not related to BitBake at all. (Bitbake rev: b97b1ef0b1b00848a4a44b34eca123ccf33188f4) Signed-off-by: Ivan Efimov <i.efimov@inango-systems.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: runqueue: Improve sstate rehashing outputRichard Purdie2019-11-071-12/+16
| | | | | | | | | | | | | | Bibake is currently too 'chatty' when hash equivalence is enabled. Fix this by only printing the log output if a rehash happens and it matches an sstate object. Also, pass a summary option to the hash checking function. This was already changed to a mechanism which allows addition of new parameters so this should be backwards and forwards compatible. (Bitbake rev: 0c4515603ad08775e3b0404cba5374367e49f236) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: fetch2: Ensure cached url data is matched to a datastoreRichard Purdie2019-11-051-2/+2
| | | | | | | | | | | | | | | | | | | | There was a weird error in OE-Core where "devtool modify virtual/kernel" was showing basehash mismatch errors. This was due to SRCPV sometimes being: AUTOINC+b867b78b50_47b80ef7bd and sometimes AUTOINC+b867b78b50_255a750d28. The latter hash comes from KBRANCH and meant sometimes the correct branch was seen, sometimes it was not. The issue was complicated by the execution using a remote datastore over tinfoil. The problem turns out to be a fetcher caching error. If the datastore changes, the cached url data may not be valid. We therefore ensure we match cached url data against the datastore that generated it, which appears to fix this issue. (Bitbake rev: 0540abd338ed2ffd822edbd2947cab2f18873422) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: tests/fetch: add test for fetching shallow revsChristopher Larson2019-10-281-0/+20
| | | | | | | | | [YOCTO #13586] (Bitbake rev: f7a973604fbfd1059875ff1fabb3f885df9c5b95) Signed-off-by: Christopher Larson <chris_larson@mentor.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: fetch2/git: fetch shallow revs when neededChristopher Larson2019-10-281-7/+16
| | | | | | | | | | | | | | When bitbake determines if a git clone needs updating, it only checks for the needed srcrevs, not the revs listed in BB_GIT_SHALLOW_REVS, which will fail if using shallow and the needed rev was added to the upstream git repo after a previous fetch. Ensure that we also check for shallow revs. [YOCTO #13586] (Bitbake rev: 93b65e3c6ca64f644946953980595c44fbbcc748) Signed-off-by: Christopher Larson <chris_larson@mentor.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: bitbake: ConfHandler: Use with to manage filehandle lifetimeOla x Nilsson2019-10-281-23/+23
| | | | | | | (Bitbake rev: 459ad524756a3f9b50feeedf31e33502dceae8d5) Signed-off-by: Ola x Nilsson <olani@axis.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: bitbake: prserv/serv: Use with while reading pidfileOla x Nilsson2019-10-281-3/+2
| | | | | | | (Bitbake rev: 405a9068ce5072050b9878f7cec15b2c2592bc4e) Signed-off-by: Ola x Nilsson <olani@axis.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: bitbake: contrib/vim: Modify Python indentation to work with ↵Chris Laplante via bitbake-devel2019-10-281-17/+27
| | | | | | | | | 'python do_task {' (Bitbake rev: cd45a25b2a649e88ddd455bfa3dddc6a60340c03) Signed-off-by: Chris Laplante <chris.laplante@agilent.com> 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 16:00:14 +0000