linux/poky.git/bitbake, branch yocto-3.1.18

bitbake: fetch/wget: Move files into place atomically

2022-07-15T11:41:59+00:00

(Bitbake rev: 7fc4cffebf5dcc1d050416c0b7f7d58c765c1d69) Signed-off-by: Richard Purdie (cherry picked from commit cd7cce4cf4be5c742d29671169354fe84220b47a) Signed-off-by: Steve Sakoman Signed-off-by: Richard Purdie

bitbake: fetch/git: Fix usehead for non-default names

2022-07-15T11:41:59+00:00

The usehead url parameter for git repositories causes bitbake to use whatever commit the repository HEAD is pointing to if the repository happens to have the name 'default'. This is the default name so in many cases it works just fine, but if a different name is specified with the url parameter 'name=newName' then it will fail to parse the recipe with an error along the lines of: ERROR: ExpansionError during parsing /path/to/my/recipe.bb Traceback (most recent call last): File "/path/to/poky/bitbake/lib/bb/fetch2/git.py", line 235, in Git.urldata_init: > ud.setup_revisions(d) File "/path/to/poky/bitbake/lib/bb/fetch2/__init__.py", line 1302, in FetchData.setup_revisions: for name in self.names: > self.revisions[name] = srcrev_internal_helper(self, d, name) File "/path/to/poky/bitbake/lib/bb/fetch2/__init__.py", line 1167, in srcrev_internal_helper(name='newName'): if srcrev == "AUTOINC": > srcrev = ud.method.latest_revision(ud, d, name) File "/path/to/poky/bitbake/lib/bb/fetch2/__init__.py", line 1562, in Git.latest_revision(name='newName'): except KeyError: > revs[key] = rev = self._latest_revision(ud, d, name) return rev File "/path/to/poky/bitbake/lib/bb/fetch2/git.py", line 650, in Git._latest_revision(name='newName'): raise bb.fetch2.FetchError("Unable to resolve '%s' in upstream git repository in git ls-remote output for %s" % \ > (ud.unresolvedrev[name], ud.host+ud.path)) bb.data_smart.ExpansionError: Failure expanding variable SRCPV, expression was ${@bb.fetch2.get_srcrev(d)} which triggered exception FetchError: Fetcher failure: Unable to resolve 'master' in upstream git repository in git ls-remote output for /path/to/local/git/repo Let's fix this by setting the unresolved rev of _all_ repository names to 'HEAD' when the usehead url parameter is specified. Update the currently failing test, test_local_gitfetch_usehead_withname, to now expect success. This change preserves existing behavior that allows usehead to be overridden by a valid looking revision if one happens to be specified instead of AUTOREV. (Bitbake rev: a247f56df680382d62910bb9a174e0fdd29e4ca8) Signed-off-by: Joey Degges Signed-off-by: Richard Purdie (cherry picked from commit 01e901c44ab0f496606b1d45c8953dc54970204c) Signed-off-by: Paulo Neves Signed-off-by: Steve Sakoman Signed-off-by: Richard Purdie

bitbake: knotty: reduce keep-alive timeout from 5000s (83 minutes) to 10 minutes

2022-06-26T11:14:23+00:00

The keep alive timeout is excessively long at 83 minutes (5000 seconds), reduce this to 10 minutes: this should be long enough that it rarely triggers in normal builds, but when it does it has useful information. (Bitbake rev: a496a8952d8542ce814b13f460811d8849d25a3c) Signed-off-by: Ross Burton Signed-off-by: Alexandre Belloni Signed-off-by: Richard Purdie (cherry picked from commit dcf52157d3635925491783be656c6b76d1efe1a4) Signed-off-by: Anuj Mittal Signed-off-by: Richard Purdie Signed-off-by: Steve Sakoman Signed-off-by: Richard Purdie

bitbake: knotty: display active tasks when printing keepAlive() message

2022-06-26T11:14:22+00:00

In interactive bitbake sessions it is obvious what tasks are running when one of them hangs or otherwise takes a long time. However, in non-interactive sessions (such as automated builds) bitbake just prints a message saying that it is "still alive" with no clues as to what tasks are active still. By simply listing the active tasks when printing the keep alive message, we don't need to parse the bitbake log to identify which of the tasks is still active and has presumably hung. (Bitbake rev: 36fe8bae9fec61547ee0b13bcb721033afd3ac0e) Signed-off-by: Ross Burton Signed-off-by: Alexandre Belloni Signed-off-by: Richard Purdie (cherry picked from commit 30f6c3f175617beea8e8bb75dcf255611e3fc2fd) Signed-off-by: Anuj Mittal Signed-off-by: Richard Purdie Signed-off-by: Steve Sakoman Signed-off-by: Richard Purdie

bitbake: bin/bitbake-getvar: Add a new command to query a variable value (with history)

2022-06-26T11:14:22+00:00

We've talked about having this for long enough. Add a command which queries a single variable value with history. This saves "bitbake -e | grep" and avoids the various pitfalls that has. It also provides a neat example of using tinfoil to make such a query. Parameters to limit the output to just the value, to limit to a variable flag and to not expand the output are provided. [YOCTO #10748] (Bitbake rev: 47ed06d441152f8b6d374cacfac2c668c354423e) Signed-off-by: Richard Purdie (cherry picked from commit 4c1881b620e885f55d7772f8626b8a76c2828333) Signed-off-by: Steve Sakoman Signed-off-by: Richard Purdie

bitbake: tinfoil/data_smart: Allow variable history emit() to function remotely

2022-06-26T11:14:22+00:00

We can't access the emit() function of varhistory currently as the datastore parameter isn't handled correctly, nor is the output stream. Add a custom wrapper for this function which handles the two details correctly. (Bitbake rev: 144a1cfe8b60c677bb6ec66c242e064c7ba3ed88) Signed-off-by: Richard Purdie (cherry picked from commit ba0fa084ccd2b1ade96425d158fd31e49e42f286) Signed-off-by: Steve Sakoman Signed-off-by: Richard Purdie

bitbake: server/process: Disable gc around critical section

2022-04-16T22:03:41+00:00

The python gc can trigger whilst we're holding the event stream lock and when cleaning up objects, they can trigger warnings. This translates into a new event which would then need the lock and we can deadlock. Disable gc whilst we hold that lock to avoid this unfortunate and problematic situation. (Bitbake rev: 0784db7dd0fef6f0621ad8d74372f44e87fef950) Signed-off-by: Richard Purdie (cherry picked from commit 96a6303949cefd469bcf5ed250ff512271354357) Signed-off-by: Steve Sakoman Signed-off-by: Richard Purdie

bitbake: fetch2: add check for empty SRC_URI hash string

2022-04-05T19:49:51+00:00

No error was being reported when the hash string was set to empty. For example: SRC_URI[md5sum] = "" On a related note (not a bug): Because whitespace in the string will result in a checksum mismatch, the error message was updated to make it a little clearer why the error was thrown. For example: SRC_URI[md5sum] = " " or SRC_URI[md5sum] = " 209f8326f5137d8817a6276d9577a2f1" Now creates a message like this: File: '/home/scott/yocto-cache/downloads/rsync-3.2.3.tar.gz' has md5 checksum '209f8326f5137d8817a6276d9577a2f1' when ' 209f8326f5137d8817a6276d9577a2f1' was expected [YOCTO #14232] (Bitbake rev: d8c2175f6a7b5fdf111d6a073b2c3dbd3c0b061d) Signed-off-by: Scott Weaver Signed-off-by: Richard Purdie (cherry picked from commit a13510d0028e234ea2f4744b0d0c38558395c70f) Signed-off-by: Steve Sakoman Signed-off-by: Richard Purdie

bitbake: tinfoil: Allow run_command not to wait on events

2022-03-28T12:30:50+00:00

There are some commands where we want to see the events returned so allow the caller to request this. This also allows us to fix an infamous bug in the tinfoil testsuite in OE-Core. (Bitbake rev: 41bf1fa85a540232dcf92fe473c3b3c4cd7259dd) Signed-off-by: Richard Purdie (cherry picked from commit 0e8421c41d97d5d50a553d70c8f775d521f1a199) Signed-off-by: Steve Sakoman Signed-off-by: Richard Purdie

bitbake: server/process: Note when commands complete in logs

2022-03-28T12:30:50+00:00

Its hard to tell from the server logs whether commands complete or not (or how long they take). Add extra info to allow more debugging of server timeouts. (Bitbake rev: d388f6d159b9d7e1ed3f199f2d1aca0c473cda6d) Signed-off-by: Richard Purdie (cherry picked from commit 56285ada585ec1481449522282b335bcb5a2671e) Signed-off-by: Steve Sakoman Signed-off-by: Richard Purdie