With the upcoming LTS, it is time we changed the bitbake version so
move to 2.0.
(Bitbake rev: 9a13bf8e20b1841ec99281d45be4c4fc1118438c)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
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>
Where a git url uses a tag instead of a full source revision, breakage
can currently occur in builds. Issues include:
* the revision being looked up in multiple tasks (fetch and unpack)
* the risk a different revision may be obtained in those tasks
* that some tasks may not be allowed to access the network
* that a revision may not be consistent throughout a given build
* rerunning a specific task may given inconsistent results
To fix this, stop the workers from cleaning out the source revision store. This
should only be done in the cooker itself (based on current policy).
Also, where the code "sees" an upstream access, mark the recipe as not to be
cached. The reparse re-triggers the upstream lookup by the server.
Add a test to ensure that if get_srcrev isn't called, the user is told they're
using a configuration that is known to break.
(Bitbake rev: 4b5eed1626709ef3dc06b32fd55d40a2a6edd179)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The NIS can't work when network is dissable, so preserve network for it, the
error is like:
do_ypcall: clnt_call: RPC: Unable to send; errno = Network is unreachable
Note, enable nscd on the build machine might be a solution, but that isn't
reliable since it depends on whether the network function has been cached or
not.
(Bitbake rev: 4eafae7904bae6e5c6bc50356e8a9077f2e207fa)
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This patch changes behaviour. After this change any task which does not
have the network flag set will have networking disabled on systems that
support that (kernel version dependent).
Add a "network" task specific flag which then triggers networking to
be enabled for this task, it is otherwise disabled.
This needs to happen before we enter the fakeroot environment of the task
due to the need for the real uid/gid which we save in the parent process.
(Bitbake rev: 0746b6a2a32fec4c18bf1a52b1454ca4c04bf543)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We occasionally see bitbake-worker failing and from the logs, an unpickle error
occurs. Add more debug so we can further debug this next time it fails.
[YOCTO #14595]
(Bitbake rev: fe8105cc06beca8240b76ea366a1eff5aa9c5412)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
For some debugging, BB_CURRENTTASK is set too late to be useful as
it isn't present in some event handlers for example. There is no
other way to know which task is actually running so set the value
earlier.
(Bitbake rev: 7daaaaa27f55b5a458656857c6d61a51b34a62fe)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If the build is interrupted, handle the shutdown of pseudo even in this
case to avoid data corruption inside docker containers.
[YOCTO #14555]
(Bitbake rev: a2a04c6fe94bc56efcff299c669a151746e35916)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We have a problem where pseudo server processes exist after bitbake exits
and hold the pseudo database in memory. In a docker container, the processes
will be killed as the container is destroyed with no warning and no opportunity
to write the data to disk. This leads to permissions/inode corruptions and
data loss.
Send a shutdown message to pseudo which in new versions of pseudo will flush
the database, thereby fixing some of the issues people using docker containers
see.
(Bitbake rev: a07a971b40acd3eee12e203d2cfa3e49f56109f6)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We really do want to see those, as they tend to turn into
hard errors eventually, as what happened with collections
vs collections.abc in python 3.10.
(Bitbake rev: bc43fbb86361a21dc2d5deb910810c5a77fdabe8)
Signed-off-by: Alexander Kanavin <alex@linutronix.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If bitbake-worker fails, return an error code showing that. Also
make the thread cleanup code explict in a finally clause as it would
otherwise hang.
[YOCTO #14393]
(Bitbake rev: 7e0af70fb53fb13f824ca954b8cc1dffee730233)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Adds a library that implements file-like objects (similar to
gzip.GzipFile) that can stream to arbitrary compression programs. This
is utilized to implement a LZ4 and zstd compression API.
(Bitbake rev: 61c3acd058ea018696bd284b3922d0b458838d05)
Signed-off-by: Joshua Watt <JPEWhacker@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
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: 4c1881b620e885f55d7772f8626b8a76c2828333)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
With the previous patch this code is now pointless as we'd have hit a TypeError
before now.
(Bitbake rev: 6301a99055c79d89b715f72182cd0ef1b781b89a)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
bitbake-server is spawned by process.py and passes the arguments it is
given to ProcessServer. There's some type confusion here:
bitbake-server is called with a string representation of the timeout,
which may be None. If the timeout is not set, pass 0 instead of None.
Inside bitbake-server a ProcessServer is created which expects the
timeout to be a float not a string, so always float() the value.
[ YOCTO #14350 ]
(Bitbake rev: c93ae1f861208f6d39fd15c84fbcd0e2b54331f5)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This allows metadata to rely upon BB_DEFAULT_UMASK.
(Bitbake rev: 969ac64adab236ce2d5196bcc294005a497913ae)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Currently each task has to have a umask specified individually. This
is leading to determinism issues since it is easy to miss specifying
this for an extra task.
Add support for specifing the default task umask globally which
simplifies the problem.
(Bitbake rev: 3e664599fd54a8a37ce587022fcbce5ca26f2ed3)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
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>
Short form arguments are added for convenience.
(Bitbake rev: 921199a4923ce383b27e23c9b7e34eb785c8bae3)
Signed-off-by: Paul Barker <pbarker@konsulko.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The hashserv server already implements support for pulling hash data
from another "upstream" server. Add the -u/--upstream argument to the
bitbake-hashserv app to expose this functionality to users.
(Bitbake rev: 8de510f1de35e581bcd5858edf23619c6a4cf923)
Signed-off-by: Paul Barker <pbarker@konsulko.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The -r/--readonly argument is added to the bitbake-hashserv app. If this
argument is given then clients may only perform read operations against
the server. The read-only mode is implemented by simply not installing
handlers for write operations, this keeps the permission model simple
and reduces the risk of accidentally allowing write operations.
As a sqlite database can be safely opened by multiple processes in
parallel, it's possible to start two hashserv instances against a single
database if you wish to export both a read-only port and a read-write
port.
(Bitbake rev: 492bb02eb0e071c792407ac3113f92492da1a9cc)
Signed-off-by: Paul Barker <pbarker@konsulko.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We're seeing occasional issues where builds fail as events were written from the
worker children in the form <event>partial data<event>full event</event>.
This causes failures as bitbake server can't parse that and exits. This could
be due to short writes to the worker event pipe which we weren't checking. Check
this and loop accordingly. Also add some asserts to detect other potential causes.
Thanks to Joshua Watt for help in spotting the issue.
[YOCTO #14181]
(Bitbake rev: a9451746a4bd7ccedf4c72cd03ad4ff0ab0143aa)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The connect function was previously removed from the hashserv Client
class but the bitbake-hashclient app was not updated. The client is
connected during hashserv.create_client() anyway so not separate connect
call is needed.
(Bitbake rev: 99bdb236bceeffa0083a0fa529280b217c1d310d)
Signed-off-by: Paul Barker <pbarker@konsulko.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This reverts commit 4fca9a07f2d6b0544977112672b786982d7bb8f2.
The default python handler is to ignore SIGPIPE errors yet by adding
this line, we see:
2020-09-23 22:10:20,325 - oe-selftest - INFO - recipetool.RecipetoolTests.test_recipetool_appendfile_subdir (subunit.RemotedTestCase)
2020-09-23 22:10:20,325 - oe-selftest - INFO - ... FAIL
2020-09-23 22:10:20,325 - oe-selftest - INFO - 11: 30/44 227/415 (14.85s) (recipetool.RecipetoolTests.test_recipetool_appendfile_subdir)
2020-09-23 22:10:20,325 - oe-selftest - INFO - testtools.testresult.real._StringException: Traceback (most recent call last):
File "/home/pokybuild/yocto-worker/oe-selftest-ubuntu/build/meta/lib/oeqa/selftest/cases/recipetool.py", line 226, in test_recipetool_appendfile_subdir
_, output = self._try_recipetool_appendfile('selftest-recipetool-appendfile', '/usr/share/selftest-replaceme-subdir', self.testfile, '', expectedlines, ['testfile'])
File "/home/pokybuild/yocto-worker/oe-selftest-ubuntu/build/meta/lib/oeqa/selftest/cases/recipetool.py", line 85, in _try_recipetool_appendfile
return self._try_recipetool_appendcmd(cmd, testrecipe, expectedfiles, expectedlines)
File "/home/pokybuild/yocto-worker/oe-selftest-ubuntu/build/meta/lib/oeqa/selftest/cases/recipetool.py", line 49, in _try_recipetool_appendcmd
bbappendfile = self._check_bbappend(testrecipe, recipefile, self.templayerdir)
File "/home/pokybuild/yocto-worker/oe-selftest-ubuntu/build/meta/lib/oeqa/selftest/cases/devtool.py", line 186, in _check_bbappend
result = runCmd('bitbake-layers show-appends', cwd=self.builddir)
File "/home/pokybuild/yocto-worker/oe-selftest-ubuntu/build/meta/lib/oeqa/utils/commands.py", line 201, in runCmd
raise AssertionError("Command '%s' returned non-zero exit status %d:\n%s" % (command, result.status, exc_output))
AssertionError: Command 'bitbake-layers show-appends' returned non-zero exit status 141:
NOTE: Reconnecting to bitbake server...
where status 141 is SIGPIPE.
We expect SIGPIPE not to be raised like this. I tried the commands in the original
commit to pipe through less with the change reverted and I don't see the error
shown. I therefore believe this is safe to revert.
(Bitbake rev: 94a18f1f2e51dd5d3928e6e0c17f2c19c8b5db49)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
While discussing with Richard we thought these might help document
and safeguard the basic requirements of clean_basepath.
A 'bonus' performance testcase is added but commented out since its
runtime is long and test machine specific. It is intended for developers
to test before and after their changes to the target function as a due
diligence verification.
(Bitbake rev: ee41549f26952d5f7af19a9b3d8a8b969866e2ef)
Signed-off-by: Jean-Francois Dagenais <jeff.dagenais@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Trying to have a new python process forked off an original doesn't work
out well and ends up having race issues. To avoid this, exec() a new
bitbake server process. This starts with a fresh python interpreter
and resolves various atexit and other multiprocessing issues once
and for all.
(Bitbake rev: 9501dd6fdd7a7c25cbfa4464cf881fcf8c049ce2)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The levels of indirection to set these verbose logging options is rather
crazy. This attempts to turn things into two specific options with
much more specific meanings. For now its all still controlled by the
commandline verbose option and should funciton as previously, with
the addition that the BB_VERBOSE_LOGS option can now be task specific.
(Bitbake rev: 423c046f2173aaff3072dc3d0882d01b8a0b0212)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This script took a documentation.conf and generated an HTML index of
each of the variables. The data in the yocto-docs manuals is now far
superior to this. The script has bitrotted and doesn't run, hasn't for
some time and wasn't reported until recently.
Easiest is just to remove it as anyone would reimplement it quite
differently now.
The referenced bug does have a patch which cleans up the code but I
don't see value in keeping this around.
[YOCTO #13881]
(Bitbake rev: 0829af7090065c429ba558d06423c2e7e7e05e90)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Directly support the various 'manage' commands from the Toaster
executable, so that users do not have to manually set up the required
environment and paths.
Examples:
$ . toaster manage createsuperuser
$ . toaster manage lsupdates
[YOCTO #13170]
(Bitbake rev: fd844e55bb885a51fe5ef8da1f625b34e646cf5f)
Signed-off-by: David Reyna <David.Reyna@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Adding the default log filter here is unnecessary because there are no
defined logging domains when it is called, which means it does no actual
filtering.
(Bitbake rev: dcdb8f2c14f09ce34d0a1facc33a441570912c05)
Signed-off-by: Joshua Watt <JPEWhacker@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Passes around the actual logging level as the default log level variable
instead of the debug count. This makes it easier to deal with logging
levels since the conversion from debug count and verbose flag only has
to occur once when logging is initialized and after that actual log
levels can be used
(Bitbake rev: 41bd155faf7f65cb0727fcce972715769b26ca89)
Signed-off-by: Joshua Watt <JPEWhacker@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
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>
