summaryrefslogtreecommitdiffstats
path: root/bitbake/lib/bb
Commit message (Collapse)AuthorAgeFilesLines
...
* bitbake: fetch2: Avoid warning about incorrect character escaping in regexRichard Purdie2018-12-061-1/+1
| | | | | | | | | | | Fixes: lib/bb/fetch2/__init__.py:259: DeprecationWarning: invalid escape sequence \w re.compile("^\w+:(?!//)").match(uri): (Bitbake rev: 9c619f1eb1583582fafda6acabaf08a5761215ef) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: tests/fetch: Update after recent gitsm message changesRichard Purdie2018-11-261-3/+2
| | | | | | | | Also use assetIn instead of assertTrue which aids debugging failures. (Bitbake rev: 7e9c0bffb95ca92cab61deeeef18f45f1b4edb6f) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: cooker: Fix multiconfig dependenciesAlejandro Enedino Hernandez Samaniego2018-11-261-8/+1
| | | | | | | | | | | | | | | | | | | | | | | | | When multiconfig is enabled the cooker adds providers for all the targets to be built on all the multiconfig variables that were set, regardless if there is a dependency to it or not. This causes an issue when a certain target is incompatible with one or more of the multiconfigs, e.g. the target is not in COMPATIBLE_MACHINE for one of the MACHINEs being built, causing the cooker to error out since no providers can be found for that certain target on that multiconfig. This patch modifies the behavior to only look for PROVIDERS for a target on the multiconfig that was selected to be built, PROVIDERS are then looked for in other multiconfigs only when there is a defined dependency to them. [YOCTO #12985] (Bitbake rev: 8bd519b04c7d6ee4cf626d5e04110c3759488d28) Signed-off-by: Alejandro Enedino Hernandez Samaniego <alejandr@xilinx.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: fetch/git: fix AttributeError in shallow extraction logicChristopher Larson2018-11-261-5/+8
| | | | | | | | | | | | | | | This code checks to see if shallow is either disabled or the tarball is missing, but the else block tries to print the tarball filename, and this attribute doesn't exist at all when shallow is disabled. Handle the two cases separately to give sane errors for both cases without the exception: Exception: AttributeError: 'FetchData' object has no attribute 'fullshallow' (Bitbake rev: b0ad961064ef6ecd77fab3435e5652c4ae284426) Signed-off-by: Christopher Larson <chris_larson@mentor.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: server/process: Fix unclosed socket warnings upon server connection ↵Richard Purdie2018-11-071-8/+7
| | | | | | | | | | | | | | | | | | | | | | | refused Extend the server error handling to avoid: Reconnecting to bitbake server... NOTE: Retrying server connection... (Traceback (most recent call last): File "/home/pokybuild/yocto-worker/nightly-oe-selftest/build/bitbake/lib/bb/main.py", line 464, in setup_bitbake server_connection = bb.server.process.connectProcessServer(sockname, featureset) File "/home/pokybuild/yocto-worker/nightly-oe-selftest/build/bitbake/lib/bb/server/process.py", line 457, in connectProcessServer sock.connect(os.path.basename(sockname)) ConnectionRefusedError: [Errno 111] Connection refused ) WARNING: /home/pokybuild/yocto-worker/nightly-oe-selftest/build/bitbake/lib/bb/main.py:481: ResourceWarning: unclosed <socket.socket fd=20, family=AddressFamily.AF_UNIX, type=SocketKind.SOCK_STREAM, proto=0> logger.info("Retrying server connection... (%s)" % traceback.format_exc()) NOTE: Starting bitbake server... (Bitbake rev: afee3f594e1510051a0b18e430e92549caf72fa2) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: siggen: Correct format argument substitutionMike Crowe2018-11-071-1/+1
| | | | | | | | | | Use % operator to ensure that the dependency is substituted into the error message correctly. (Bitbake rev: 8e587386b0b3a0ed11edf71dfbe9fb508f60d0b3) Signed-off-by: Mike Crowe <mac@mcrowe.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: fetch: Also export GIT_SSH environment variableMike Crowe2018-11-071-0/+1
| | | | | | | | | | | Support users who want to specify a custom ssh to Git using an environment variable. (This lets build systems work without requiring users to configure Git explicitly.) (Bitbake rev: db46fb2755a4b1033ab60051ce511cc9dd7e34fb) Signed-off-by: Mike Crowe <mac@mcrowe.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: fetch2/gitsm.py: Fix the references when the module and path are ↵Mark Hatle2018-11-071-35/+34
| | | | | | | | | | | | | | | | | | | | | | | different Git does not require the module and target path to be the same in the .gitmodules file. This incorrect assumption was being made previously causing various unpack failures. An example .gitmodule showing this issue: [submodule "plugins/WaveShaper/Libs/inih"] path = plugins/wolf-shaper/Libs/inih url = https://github.com/pdesaulniers/inih.git The unpack function also needed to work in a loop on the overall submodules_queue. Before it could have missed items that were not in the primary repository. (Bitbake rev: 5a7009c204f4d2254e3b2d83ad9319ac23f1cf4d) Signed-off-by: Mark Hatle <mark.hatle@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: fetch2/gitsm.py: Disable branch checking on submodulesMark Hatle2018-11-071-1/+1
| | | | | | | | | | | | Submodules by definition refer to a specific commit, not branch. If we don't ignore the branch, then any commits on a submodule on a branch different then the original module will trigger a failure that the commit is not on the branch. (Bitbake rev: fdc1dbf96f153b496de52acd8263366a1ff303ad) Signed-off-by: Mark Hatle <mark.hatle@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: bitbake: Bump version to 1.40.0Richard Purdie2018-10-201-1/+1
| | | | | | (Bitbake rev: 2820e7aab2203fc6cf7127e433a80b7d13ba75e0) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: data_smart: Fix removal handling interaction issue with overridesRichard Purdie2018-10-202-4/+22
| | | | | | | | | | | | | | | | | | | If a variable has a _remove applied to it but that variable is in turn 'renamed' through OVERRIDES, the removal gets lost with the current code. TEST = "foo" TEST_someval = "bar" TEST_someval_remove = "bar" OVERRIDES = "someval" currently gives "bar" for TEST but should give "". This fixes the code to track the removal and adds a test case to ensure this doesn't regress again. (Bitbake rev: 8f55010c18057be040f073d8bcb4c5c2c311d809) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: test/data: Add new tests for task checksum changing/not changingRichard Purdie2018-10-181-0/+48
| | | | | | | | | | | | | | | | | | This adds some basic tests for task checksums to ensure that the checksums: * change when variables change * change when active _remove operators are present * don't change when the _remove operators are not active * change when an active contains() expression is present * dont' change a contains() expression isn't active There is a lot of other functionality which should be added to this test but its a start. (Bitbake rev: 5463c16e3619d324aed137f47f93f0997a227d29) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: data/siggen: Extract task hash generation code into a functionRichard Purdie2018-10-182-33/+42
| | | | | | | | | By creating a standalone function, we can add better functional testing of this code. (Bitbake rev: 796a20d24dc18479de1975a37b9e52a5ac75c73f) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: bitbake: data: Ensure task checksums account for remove dataRichard Purdie2018-10-182-9/+30
| | | | | | | | | | | | | | | | | | | | | | | | Currently remove operations are not being accounted for in the task checksums. This is a fairly serious oversight and needs to be fixed. To do so, we need internal data from getVarFlag combined with the expanded variable data so that only "active" remove operators are accounted for in the task checksum. We can get this from the new optional removes attribute in the returned parser object. The code can then use the data on active remove operators to account for the removals in task checksum but only when the removal is active. We have to be careful here not to reference any expanded data since this may for example contain build paths. This means we can only map back and reference the unsplit (and hence unexpanded) remove string which may expand to multiple removal values. [YOCTO #12913] (Bitbake rev: 57d2ee17ae83a139a37081eb082e6184fa883581) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: data/data_smart: Allow getVarFlag to return the variable parser objectRichard Purdie2018-10-182-11/+18
| | | | | | (Bitbake rev: 136100dc932c9019737f927d826955425134010f) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: data_smart: Fix expand_cache and _remove operator interaction issuesRichard Purdie2018-10-181-27/+23
| | | | | | | | | | | | | | | | | | | The contents of the expand_cache is meant to match the return value of getVarFlag() but the implementation was mostly in expandWithRefs(). If an incorrect key was passed to expandWithRefs(), or a variable was only partially expanded with no remove processing, the cache could become corrupted. Move the code to getVarFlag making the data lifecycle very clear, meaning other calls to expandWithRefs() cannot corrupt the cache. The expand_cache reset code needs to be moved ahead of any remote data connectors too, since the expand_cache is now on the local side of the connection. (Bitbake rev: a039052f9b680eae53f3f12b7381b945f1d69253) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: data_smart: Micro optimise _remove handlingRichard Purdie2018-10-181-1/+1
| | | | | | | | | | | | | | | | | This brings _remove handling into line with _append/_prepend with regard to the parsing flag to getVarFlag. This is an internal flag and the only times this is used is through getVar during renameVar operations and when processing ?= operations to see if a variable is set. In either case we don't need to process remove operations. Therefore take the minor speedup and skip processing for parsing=True. [YOCTO #10945] (Bitbake rev: 6d19eb3226b59922c0f888e33b28443635151501) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: fetch2: Avoid incorrect getVarFlag callRichard Purdie2018-10-181-1/+3
| | | | | | | | | Calling getVarFlag with flag=None makes no sense, don't do it. Bitbake used to silently ignore this, it now warns so avoid the warning. (Bitbake rev: a68de8ace62eaba23856bfb301efbbe1824322aa) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: fetch2/git: provide information about missing sourcesUrs Fässler2018-10-182-8/+23
| | | | | | | | | | | Provide more information in the case the sources are not found in the unpack step. (Bitbake rev: 27a2214bf6f2e7c61bfc422a20959a55f7e0d25d) Signed-off-by: Urs Fässler <urs.fassler@bbv.ch> Signed-off-by: Pascal Bach <pascal.bach@siemens.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: fetch2/git: explicitly show the decision logic to select the source ↵Urs Fässler2018-10-181-3/+4
| | | | | | | | | | in code (Bitbake rev: 78d8fb3a7899e1404a513be1c2b2b4440da8b12d) Signed-off-by: Urs Fässler <urs.fassler@bbv.ch> Signed-off-by: Pascal Bach <pascal.bach@siemens.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: fetch2/git: prevent access to non-existing clonedirUrs Fässler2018-10-182-1/+14
| | | | | | | | | | | | A user friendly error is throw when neither the clonedir nor fullshallow exist. Without the check, a difficult to interpret error is throw from within the fetch command. (Bitbake rev: 30cf2506007d25162f0805051212f54c39034ff3) Signed-off-by: Urs Fässler <urs.fassler@bbv.ch> Signed-off-by: Pascal Bach <pascal.bach@siemens.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: fetch2: extract the function which ensures that a valid symlink existsUrs Fässler2018-10-181-10/+17
| | | | | | | | | | | For better readability and future use, we extract the function which ensures that a given symlink exists. (Bitbake rev: 5e69ca56533666a097bb23d09ab673e5c862051c) Signed-off-by: Urs Fässler <urs.fassler@bbv.ch> Signed-off-by: Pascal Bach <pascal.bach@siemens.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: fetch2/git: use intention revealing names for premirror testsUrs Fässler2018-10-181-11/+11
| | | | | | | | (Bitbake rev: 3434e64e7c077c1ecff7b36f02b6c6b59a7d1fe9) Signed-off-by: Urs Fässler <urs.fassler@bbv.ch> Signed-off-by: Pascal Bach <pascal.bach@siemens.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: fetch2/git: add tests to capture existing behavior wrt. naming of ↵Urs Fässler2018-10-181-0/+35
| | | | | | | | | | | | | git shallow tarball The mapping of the URLs to the local shallow tarballs is not obvious. For easier understanding, we add this tests to explicitly showing the mapping. (Bitbake rev: 05f2ac8e19a027d103921b5ae0070db609a83042) Signed-off-by: Urs Fässler <urs.fassler@bbv.ch> Signed-off-by: Pascal Bach <pascal.bach@siemens.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: fetch2/git: add tests to capture existing behavior wrt. naming of ↵Urs Fässler2018-10-181-0/+34
| | | | | | | | | | | | | mirror tarball The mapping of the URLs to the local tarballs is not obvious. For easier understanding, we add this tests to explicitly showing the mapping. (Bitbake rev: c604d9402b4c9ad7eb5c794ab24f2f348d9719a9) Signed-off-by: Urs Fässler <urs.fassler@bbv.ch> Signed-off-by: Pascal Bach <pascal.bach@siemens.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: fetch2/git: add tests to capture existing behavior wrt. naming of ↵Urs Fässler2018-10-181-0/+49
| | | | | | | | | | | | | clone directories The mapping of the URLs to the local directory is not obvious. For easier understanding, we add this tests to explicitly showing the mapping. (Bitbake rev: 5f92682389fee437d6df2ff7718c571b7444e179) Signed-off-by: Urs Fässler <urs.fassler@bbv.ch> Signed-off-by: Pascal Bach <pascal.bach@siemens.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: fetch2: avoid circular recursion with SRCPV in PRPeter Marko2018-10-181-1/+3
| | | | | | | | | | | Some recent changes broke SRCPV and workaround was introduced to avoid circular dependency if SRCPV is in PV. However there is still the same error if SRCPV is in PR. (Bitbake rev: 05ee4845f925b8528a7ce9cffb4bae425b8fa1e9) Signed-off-by: Peter Marko <peter.marko@siemens.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: taskexp: add focused search barTobias Olausson2018-10-181-1/+9
| | | | | | | | | | Searching in the task explorer requires one to focus the task list. A readily visible and focused search bar makes searching intuitive. (Bitbake rev: 43f8a23d56995f552f98a666e86b6cc124e235a4) Signed-off-by: Tobias Olausson <tol@hms.se> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: data: Fix whitespace on _remove operationsRichard Purdie2018-10-182-6/+19
| | | | | | | | | | | | | | | | | | | | We have some slightly odd behaviours with the current implementation of _remove operations. For example: TEST = " A B" TEST_remove = "C" would trigger TEST to become "A B" even thought it doesn't contain "C". In particular, this means that an inactive remove operator added in a bbappend could change the task checksum which is not desireable. Fix the operation to preserve whitespace, adding new tests to make this explict and test further corner cases. Also update the manual to match. (Bitbake rev: c0a23dd9155c50a6b7df796980bc7b612cac7994) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: data_smart: Preserve history when renaming variablesRichard Purdie2018-10-181-0/+11
| | | | | | | | | | | | | Currently when a variable is renamed, all the variable history is lost. This makes it hard for users to understand/debug where values came from. Improve the code so that history is preserved across renamed variables. (Expanded variable key names are a special case of variable renaming) (Bitbake rev: 11722c989077a8751a5d0653c523760bf91e6efa) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: main: Fix environment handling for UI module importsRichard Purdie2018-10-101-3/+4
| | | | | | | | | | | | | | | The environment was being cleared before the UI imports occurred which caused problems for graphical UIs like taskexp. The full environment was intended to be available to UI clients and it was only meant to be cleared for the server/cooker, so tweak the code order so this is the case. This fixes problems reported for taskexp. [YOCTO #12670] (Bitbake rev: ac15028391fdcc3fec2dd0e64a4f763ce63e5449) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: gitsm: Allow relative URIs when fetchingMark Hatle2018-10-041-0/+5
| | | | | | | | | | | Some repositories may specify a relative submodule path. If this happens, it is our responsibility to use the parents URL (ud) and handle any relative processing ourselves. (Bitbake rev: fd9893c338df7828b2c01f1d548aa86dfcf7c50a) Signed-off-by: Mark Hatle <mark.hatle@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: fetch2/gitsm: checkout submodules recursivelyLaurent Bonnans2018-10-041-30/+38
| | | | | | | | | The new fetcher did not run 'git submodule update' recursively. (Bitbake rev: 377ed943357b6d47d41d84edbf971741f44affa9) Signed-off-by: Laurent Bonnans <laurent.bonnans@here.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: fetch2/gitsm: handle submodules nested inside subdirsLaurent Bonnans2018-10-041-6/+9
| | | | | | | | | | | | | | The new gitsm fetcher assumed that submodules were living directly in the 'modules' directory, whereas they can be arbitrarily nested inside subdirectories. Solve it by first creating the parent of the destination directory for the symlink and copy steps. (Bitbake rev: 3dbc84e9c572f43209b79f3656d7dc35a6d982ba) Signed-off-by: Laurent Bonnans <laurent.bonnans@here.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: toaster: error logs missing for cli buildsDavid Reyna2018-10-041-4/+5
| | | | | | | | | | | | | The method 'store_log_event' in 'buildinfohelper.py' always puts log messages from CLI builds into the backlog but never takes them out. The "close" method now forces all backlogged CLI events to be registered. [YOCTO #12813] (Bitbake rev: 6458cc4234337f551dfe189b6f8800d8da886c24) Signed-off-by: David Reyna <David.Reyna@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: fetch2/gitsm: fix a typoLaurent Bonnans2018-10-041-1/+1
| | | | | | | | | 'qbareclone' in place of 'bareclone' (Bitbake rev: 90a3181f1397ae05862f4e89a9bbac606e74504e) Signed-off-by: Laurent Bonnans <laurent.bonnans@here.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: fetch2/git: use correct check to decide if the shallow tarball ↵Urs Fässler2018-10-041-1/+1
| | | | | | | | | | | | | should be unpacked The shallow_tarball check is never true due a check on the caller side. The tarball check is not related to the code on the caller side. (Bitbake rev: 086eddcf8c7520ff5c52ce2a11ca9bf5b5fe5d7e) Signed-off-by: Urs Fässler <urs.fassler@bbv.ch> Signed-off-by: Pascal Bach <pascal.bach@siemens.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: fetch2/git: prevent access to non-existing fullshallow tarballUrs Fässler2018-10-042-1/+15
| | | | | | | | (Bitbake rev: b7f00a8c11672a2ee0408e210fb174cda3384e3f) Signed-off-by: Urs Fässler <urs.fassler@bbv.ch> Signed-off-by: Pascal Bach <pascal.bach@siemens.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: fetch2/git: improve readability of method need_updateUrs Fässler2018-10-041-4/+9
| | | | | | | | | | | To improve the readability we extract the different scenarios of why the clonedir needs an update. (Bitbake rev: 9038e029f4f0ab413727de76c74248cbb3cdc9ea) Signed-off-by: Urs Fässler <urs.fassler@bbv.ch> Signed-off-by: Pascal Bach <pascal.bach@siemens.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: test/fetch: use canonical GitLab URLsRoss Burton2018-10-041-2/+2
| | | | | | | | | | | GitLab returns a redirect from /foo to /foo.git which older releases of Git don't handle when cloning. These tests don't clone so the redirect works, but let's be consistant with the structure of these URLs and add the .git suffix. (Bitbake rev: d47febbae4ff24be259037f12bafbc14b9e2d6a8) Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: fetch2/gitsm.py: Rework the git submodule fetcherMark Hatle2018-09-262-123/+159
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The prior fetcher did not know how to work with MIRRORS, and did not honor BB_NO_NETWORK and similar. The new fetcher approach recursively calls 'gitsm' download on each submodule detected. This ensures that it will go throug the standard download process. Each downloaded submodule is then 'attached' to the original download in the 'modules' directory. This mimics the behavior of: git submodule init but there is no chance it will contact the network without permission. It then corrects upstream reference URIs. The unpack steps simply copies the items from the downloads to the destdir. Once copied the submodules are connected and we then run: git submodule update According to the git documentation, git submodule init can and will modify the project configuration and may connect to the network. Doing the work manually prevents this. (This manual process is allowed based on my reading of the documentation.) See: https://git-scm.com/book/en/v2/Git-Tools-Submodules The small change to the existing test is due to this new code always assuming the code is from a remote system, and not a 'local' repository. If this assumption proves to be incorrect -- code will need to be added to deal with local repositories without an upstream URI. (Bitbake rev: 9c6b39adf9781fa6745f48913a97c859fa37eb5b) Signed-off-by: Mark Hatle <mark.hatle@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: lib/bb/tests/parse.py: Test case was changing chdirMark Hatle2018-09-261-0/+4
| | | | | | | | | | The test case was changing the current directory, but was never restoring it to the original location. This causes occasional failures in later test cases. (Bitbake rev: 8c222c45148d1f21c2390d66ddd9d3e33b397f05) Signed-off-by: Mark Hatle <mark.hatle@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: utils: lockfile: Fix infinite loopIoan-Adrian Ratiu2018-09-251-1/+5
| | | | | | | | | | | | | | | | | | | | | | | | | A nasty corner case leads to a hang when utils.lockfile is called from oe-core's package-manager:deploy_dir_lock (in turn called from rootfs:_create further up the call stack) with "name" owned by root and the user running bitbake has no write access. Because this code runs under pseudo, the UID and EUID of the bitbake worker process are 0, so the os.access(dirname, os.W_OK) returns True i.e. it thinks the path is writable when in fact it's not writable. Only later when trying to open the file an Exception it thrown because the OS prohibits writing, but the Exception is ignored and the open is retried leading to an infinite loop. So this fix is to not ignore the "Permission Denied" exception. An alternative fix would be to replace the os.access() call with an try: open() except() at the beginning of the function. (Bitbake rev: 0cb64d0f85b41b2fa764baf6ff7ea1b13f95004e) Signed-off-by: Ioan-Adrian Ratiu <adrian.ratiu@ni.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: daemonize/build: Clean up /dev/null fd handlingRichard Purdie2018-09-222-7/+4
| | | | | | | | | | | | | | | | At the end of bitbake selftest we see: sys:1: ResourceWarning: unclosed file <_io.TextIOWrapper name='/dev/null' mode='r+' encoding='UTF-8'> Clean up the /dev/null handling to drop the unused entry in build.by and ensure the other open() calls are cleaned up. NULL was unused since http://git.yoctoproject.org/cgit.cgi/poky/commit/bitbake/lib/bb/build.py?id=4a081b5a52e3d27da8d4b062f3fda292e8d8fb0a back in 2012. (Bitbake rev: e72be96cfa9f05fda5f420c7cfa8bcfa9304b884) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: COW: Fix StopIteration warningRichard Purdie2018-09-221-1/+1
| | | | | | | | | | | | | Fix the warning: WARNING: lib/bb/data_smart.py:235: DeprecationWarning: generator 'COWDictMeta.iter' raised StopIteration for k, v in self.variables.iteritems(): by using return from the generator, not raising StopIteration. (Bitbake rev: 407d6e07b09123c12c382b4a92107f002c314b05) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: runqueue: Ensure setscene tasks that aren't covered get builtRichard Purdie2018-09-101-2/+4
| | | | | | | | | | | | | | | | | | | | Running "bitbake gconf-native -c cleansstate; bitbake core-image-sato:do_populate_sdk" results in a build where it fails to find gconf-native and fails to build it, merrily trying to build the SDK without gconf being present. The issue is the missing setscene tasks are effectively ignored as the later code in runqueue thinks that since other sstate tasks are present, these 'cover' the missing one. In reality we need to call BB_SETSCENE_DEPVALID to make that decision. To do that we need a "reduced" setscene dependency graph which we don't have in main task graph context. Since that was already done in setscene, we should just assume anything in the non-covered list needs to be built. (Bitbake rev: 464d0339add15bc8b4344ddd1e4c49706e3c0a02) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: cooker/runqueue: Turn universe warnings into verbnotesRichard Purdie2018-09-102-2/+2
| | | | | | | | | If the user puts universe on the commandline, they don't really want warnings so use the new verbnote level instead. (Bitbake rev: 0c87ade5678e503899e3a6cdda5329f6fc212b63) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: msg: Add explicit verbnote log levelRichard Purdie2018-09-102-0/+19
| | | | | | | | | | It has become apparant we need a log level which reaches the console but isn't a warning/error. Add "verbnote" as a way of doing this, behaves as a note but with a higher priority. (Bitbake rev: 2076f12cc2f809345108b1606bd6201f41287505) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: server/process: Various server startup logging fixesRichard Purdie2018-09-053-13/+22
| | | | | | | | | | | | | | | | | | | | | | | | | There were various problems in the server startup loggin: a) stdout/stderr were not being flushed before forking which could potentially duplicate output b) there were separate buffers for stdout/stderr leading to confusing logs where the entries could be reordered. This was particularly confusing due to the separator the logs use to idendify new messages c) an fd wasn't being closed during server startup meaning if the server failed to start, the closed fd wasn't detected as it was held open by the other reference d) If the pipe was detected as being closed, the code incorrectly retried server startup e) The event code would remap stdout/stderr without flushing them, leading to lose log messages (Bitbake rev: 0594faa0b52ce5dbd948d836d88617d38d9862d1) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake: cooker.py: Fix incorrect bb files matched warningMark Hatle2018-09-052-1/+87
| | | | | | | | | | | | | | | | | | | | In the case of a sublayer of an existing layer, where the sublayer and main layer share a path, the system may not match the paths properly resulting in: No bb files matched BBFILE_PATTERN_sublayer '^/path/main/sublayer' because it has already matched the main layer. Fix this issue by sorting the collection items based on the pattern, using longest to shortest. Obviously regex wildcards could still be an issue but these are typically not used, so this simply fix should work in the existing cases. (Bitbake rev: 1787cef7221b88f6920ea70fadaffc117d84c7aa) Signed-off-by: Mark Hatle <mark.hatle@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>