linux/poky.git/bitbake/lib/hashserv, branch uninative-2.10

bitbake: hashserv: Fix broken AF_UNIX path length limit

2020-12-10T13:39:15+00:00

Fixes the bug were long paths would break Unix domain socket clients (for real this time; the previous attempt was missing os.path.basename). Adds some tests to prevent regressions (Bitbake rev: 77790e3656048eff5cb1a086c727d86d32773b68) Signed-off-by: Joshua Watt Signed-off-by: Richard Purdie

bitbake: hashserv: client: Fix AF_UNIX path length limits

2020-12-09T12:27:25+00:00

Restores a fix for unix domain socket path length limits when using the synchronous hash equivalence client that was accidentally removed when the async client was added. Unfortunately, it's much more difficult to fix the same problem when using the async client directly due to the interaction of chdir() and async code, but this will at least restore the old behavior in the synchronous case. (Bitbake rev: 53e85022a8b1c8f407c9418260c59beffb96f0f9) Signed-off-by: Joshua Watt Signed-off-by: Richard Purdie

bitbake: bitbake: hashserve: Add support for readonly upstream

2020-11-24T15:26:12+00:00

Adds support for an upstream server to be specified. The upstream server will be queried for equivalent hashes whenever a miss is found in the local server. If the server returns a match, it is merged into the local database. In order to keep the get stream queries as fast as possible since they are the critical path when bitbake is preparing the run queue, missing tasks provided by the server are not immediately pulled from the upstream server, but instead are put into a queue to be backfilled by a worker task later. (Bitbake rev: e6d6c0b39393e9bdf378c1eba141f815e26b724b) Signed-off-by: Joshua Watt Signed-off-by: Richard Purdie

bitbake: bitbake: hashserve: Add async client

2020-11-24T15:26:12+00:00

Adds support for create a client that operates using Python asynchronous I/O. (Bitbake rev: cf9bc0310b0092bf52b61057405aeb51c86ba137) Signed-off-by: Joshua Watt Signed-off-by: Richard Purdie

bitbake: bitbake: hashserv: Fix localhost sometimes resolved to a wrong IP

2020-09-23T19:55:53+00:00

Using localhost for direct builds on host is fine. A case with a misbehavior has been sighted on a Docker build. Even when the host supports IPv6, but Docker is not configured correspondingly - some versions of the asyncio Python module seem to misbehave and try to use IPv6 where it's not supported in the container. This happens at least on some Ubuntu 18.04 based containers, resolving the IP explicitly appears to be the fix. (Bitbake rev: 0e20f91c11afdc17ea776aa02e0cc8b0d59a23d4) Signed-off-by: Anatol Belski Signed-off-by: Richard Purdie

bitbake: lib: fix most undefined code picked up by pylint

2020-08-25T17:14:53+00:00

Correctly import, and inherit functions, and variables. Also fix some typos and remove some Python 2 code that isn't recognised. (Bitbake rev: b0c807be5c2170c9481c1a04d4c11972135d7dc5) Signed-off-by: Frazer Clews Signed-off-by: Richard Purdie

bitbake: hashserv: Chunkify large messages

2020-06-28T07:36:56+00:00

The hash equivalence client and server can occasionally send messages that are too large for the server to fit in the receive buffer (64 KB). To prevent this, support is added to the protocol to "chunkify" the stream and break it up into manageable pieces that the server can each side can back together. Ideally, this would be negotiated by the client and server, but it's currently hard coded to 32 KB to prevent the round-trip delay. (Bitbake rev: e27a28c1e40e886ee68ba4b99b537ffc9c3577d4) Signed-off-by: Joshua Watt Signed-off-by: Richard Purdie

bitbake: lib: remove unused imports

2020-01-19T13:31:05+00:00

removed unused imports which made the code harder to read, and slightly but less efficient (Bitbake rev: 4367692a932ac135c5aa4f9f2a4e4f0150f76697) Signed-off-by: Frazer Clews Signed-off-by: Richard Purdie

bitbake: hashserv: Add support for equivalent hash reporting

2019-12-04T12:12:45+00:00

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

bitbake: hashserv: Don't daemonize server process

2019-09-27T12:02:19+00:00

The hash server process is terminated and waited on with join(), so it should not be a daemon. Daemonizing it cause races with the server cleanup, especially in the selftest because the process may not have terminated and cleanup up its socket before the test cleanup runs and tries to do it. [YOCTO #13542] (Bitbake rev: 7c829675581818f92d57056b57fbd3880829b6bd) Signed-off-by: Joshua Watt Signed-off-by: Richard Purdie