We missed on adding nanbield to the release manuals. It's now EOL so
let's add it directly to the oudated release manuals section.
(Bitbake rev: b891878a7f08b15ee5d6d037d99fbc769cc905e4)
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Fixed:
- BBMULTICONFIG = "qemux86-64 qemuarm64" and more than 70 layers in BBLAYERS
$ bitbake -p -P
Check profile.log.processed, the record() cost more than 20 seconds, it is less
than 1 second when multiconfig is not enabled, and there would be the following
error when more muticonfigs are enabled:
Timeout while waiting for a reply from the bitbake server
Don't change the type of loginfo['detail'] or re-assign it can make record()
back to less than 1 second, this won't affect COW since loginfo is a mutable
type.
The time mainly affected by two factors:
1) The number of enabled layers, nearly 1 second added per layer when the
number is larger than 50.
2) The global var such as USER_CLASSES, about 1 ~ 2 seconds added per layer
when the layers number is larger than 50.
(Bitbake rev: 0596aa0d5b0e4ed3db11b5bd560f1d3439963a41)
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Enforce the default remote name to "origin", as assumed in numerous
places.
This prevents build failures in case the system/user configuration sets
this to a different value.
(Bitbake rev: 1d7360031164f04887c792fb0b2dd86c6ccfcc23)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Update the test cases since the implementation is changed:
* test_shallow_multi_one_uri()
The a_branch and v0.0 had the same revision, and it required fetch a_branch
and remove histories of v0.0 which were conflicted, and bitbake reported:
fatal: no commits selected for shallow requests
Make a_branch and v0.0 have different revs to fix the problem.
And now the 'rev^' is not needed, so update self.assertRevCount() as well.
* test_shallow_multi_one_uri_depths()
Update self.assertRevCount(), now git only fetches the required revs.
* test_shallow_fetch_missing_revs()
The command is:
$ git fetch --shallow-exclude=v0.0 master
But master and v0.0 uses the same revision, so there is no commit to fetch.
* test_shallow_fetch_missing_revs_fails()
Two unneeded committs are not fetched now:
- rev^
- One not specified or required tag.
So update self.assertRevCount()
(Bitbake rev: 48eff9d9a660ad6b9bd8b53a7dcec600ef42b1d1)
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This patch can make the following settings much more faster:
BB_GIT_SHALLOW = "1"
BB_GENERATE_MIRROR_TARBALLS = "1"
* The previous implementation was:
- Make a full clone for the repo from local ud.clonedir
- Use git-make-shallow to remove unneeded revs
It was very slow for recipes which have a lot of SRC_URIs, for example
vulkan-samples and docker-compose, the docker-compose can't be done after 5
hours.
$ bitbake vulkan-samples -cfetch
Before: 12 minutes
Now: 2 minutes
$ bitbake docker-compose -cfetch
Before: More than 300 minutes
Now: 15 minutes
* The patch uses git shallow fetch to fetch the repo from local
ud.clonedir:
- For BB_GIT_SHALLOW_DEPTH: git fetch --depth <depth> rev
- For BB_GIT_SHALLOW_REVS: git fetch --shallow-exclude=<revs> rev
Then the git repo will be shallow, and git-make-shallow is not needed any
more.
And git shallow fetch will download less commits than before since it doesn't
need "rev^" to parse the dependencies, the previous code always need 'rev^'.
(Bitbake rev: a5a569c075224fe41707cfa9123c442d1fda2fbf)
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* to avoid wrong http response in checkstatus function:
in wget checkstatus() we are using 'HTTPConnectionCache' to share connections
1. state_file1(exists on http server) use shared connection <shared1> to send request
2. http_server recieved request of state_file1, but delayed by some reason to sent respone
3. state_file1 checkstatus() failed by timeout and drop shared connection <shared1>
4. state_file2(not exists on http server) get shared connection <shared1> and send request
5. http_server finally send 200 response for state_file1
6. state_file2 recived 200 response and thought it was exists on http_server
(Bitbake rev: bf6d0282ab88b4edc4b9e58184cd76cce965abbd)
Signed-off-by: y75zhang <yang-mark.zhang@nokia-sbell.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This fixes the following error when calling 'bitbake-dumpsig' or
'bitbake-diffsigs' when having only a single sigfile available:
| Traceback (most recent call last):
| File "[..]/poky/bitbake/bin/bitbake-dumpsig", line 171, in <module>
| files = find_siginfo_task(tinfoil, options.taskargs[0], options.taskargs[1])
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
| File "[..]/poky/bitbake/bin/bitbake-dumpsig", line 83, in find_siginfo_task
| sig2 = latestsigs[1]
| ~~~~~~~~~~^^^
| IndexError: list index out of range
Handle this by adding (and returning) the path for the second sigfile
only if one is found. This way it will work for both diffsigs and
dumpsig use case.
The calling argparse code already deals with find_siginfo_task()
returning only a single file.
For 'bitbake-dumpsig' it will just dump the single sigfile, for
'bitbake-diffsigs' it will emit a proper error message again:
| ERROR: Only one matching sigdata file found for the specified task (systemd configure)
(Bitbake rev: 25057d33e9131f3214a06bbb316c916c744f8f03)
Signed-off-by: Enrico Jörns <ejo@pengutronix.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If modules do something like "from glob import glob" then we end up
checksumming the glob code. That leads to bugs as the code can change
between different python versions for example, leading to checksum
instability.
We should ignore functions not from the current file as implemented
by this change.
(Bitbake rev: 1e6f862864539d6f6a0bea3e4479e0dd40ff3091)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Currently, if a pylib function changes contents, the taskhash remains
unchanged since we assume the functions have stable output. This is
probably a poor assumption so take the code of the function into account
in the taskhashes. This avoids certain frustrating build failures we've
been seeing in automated testing.
To make this work we have to add an extra entry to the python code parsing
cache so that we can store the hashed function contents for efficiency as
in the python module case, that isn't used as the key to the cache.
The cache version changes since we're adding data to the cache.
(Bitbake rev: b2c3438ebe62793ebabe2c282534893908d520b4)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The bb_cache.dat might be an invalid symlink when error happens, then
os.path.exists(symlink) would return False for it, the invalid symlink
wouldn't be removed and os.symlink can't update it any more.
Use os.path.islink(symlink) can fix the problem.
(Bitbake rev: 1387d7b9ee3f270488f89b29f36f9f240e44accc)
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* avoids long trace when BB_HASHSERVE points to non-existent socket
file, e.g.:
BB_HASHSERVE = "unix:///OE/no-socket.sock"
or when running the build before starting the bin/bitbake-hashserv.
* now it shows just warnings like it did in kirkstone
many of them, e.g. 6 just for rebuilding zlib-native, but better than long trace
for nonexistent socket file:
WARNING: zlib-native-1.3.1-r0 do_create_spdx: Error contacting Hash Equivalence Server unix:///OE/no-socket.sock: [Errno 2] No such file or directory
for existing file, but before starting bin/bitbake-hashserv:
WARNING: zlib-native-1.3.1-r0 do_create_spdx: Error contacting Hash Equivalence Server unix:///OE/hashserv.sock: [Errno 111] Connection refused
ERROR: An uncaught exception occurred in runqueue############################################################### | ETA: 0:00:00
Traceback (most recent call last):
File "/OE/build/oe-core/bitbake/lib/hashserv/__init__.py", line 80, in create_client(addr='unix:///OE/no-socket.sock', username=None, password=None):
if typ == ADDR_TYPE_UNIX:
> c.connect_unix(*a)
elif typ == ADDR_TYPE_WS:
File "/OE/build/oe-core/bitbake/lib/bb/asyncrpc/client.py", line 241, in Client.connect_unix(path='/OE/no-socket.sock'):
self.loop.run_until_complete(self.client.connect_unix(path))
> self.loop.run_until_complete(self.client.connect())
File "/usr/lib/python3.12/asyncio/base_events.py", line 687, in _UnixSelectorEventLoop.run_until_complete(future=<Task finished name='Task-6' coro=<AsyncClient.connect() done, defined at /OE/build/oe-core/bitbake/lib/bb/asyncrpc/client.
py:150> exception=FileNotFoundError(2, 'No such file or directory')>):
> return future.result()
File "/OE/build/oe-core/bitbake/lib/bb/asyncrpc/client.py", line 152, in AsyncClient.connect():
if self.socket is None:
> self.socket = await self._connect_sock()
await self.setup_connection()
File "/OE/build/oe-core/bitbake/lib/bb/asyncrpc/client.py", line 85, in connect_sock:
sock = socket.socket(socket.AF_UNIX, socket.SOCK_STREAM, 0)
> sock.connect(os.path.basename(path))
finally:
FileNotFoundError: [Errno 2] No such file or directory
ERROR: Running idle function
Traceback (most recent call last):
File "/OE/build/oe-core/bitbake/lib/hashserv/__init__.py", line 80, in create_client(addr='unix:///OE/no-socket.sock', username=None, password=None):
if typ == ADDR_TYPE_UNIX:
> c.connect_unix(*a)
elif typ == ADDR_TYPE_WS:
File "/OE/build/oe-core/bitbake/lib/bb/asyncrpc/client.py", line 241, in Client.connect_unix(path='/OE/no-socket.sock'):
self.loop.run_until_complete(self.client.connect_unix(path))
> self.loop.run_until_complete(self.client.connect())
File "/usr/lib/python3.12/asyncio/base_events.py", line 687, in _UnixSelectorEventLoop.run_until_complete(future=<Task finished name='Task-6' coro=<AsyncClient.connect() done, defined at /OE/build/oe-core/bitbake/lib/bb/asyncrpc/client.
py:150> exception=FileNotFoundError(2, 'No such file or directory')>):
> return future.result()
File "/OE/build/oe-core/bitbake/lib/bb/asyncrpc/client.py", line 152, in AsyncClient.connect():
if self.socket is None:
> self.socket = await self._connect_sock()
await self.setup_connection()
File "/OE/build/oe-core/bitbake/lib/bb/asyncrpc/client.py", line 85, in connect_sock:
sock = socket.socket(socket.AF_UNIX, socket.SOCK_STREAM, 0)
> sock.connect(os.path.basename(path))
finally:
FileNotFoundError: [Errno 2] No such file or directory
Summary: There were 2 ERROR messages, returning a non-zero exit code.
1605616 09:29:05.369352 Parse cache valid
1605616 09:30:14.500863 Registering idle function <function BBCooker.buildTargets.<locals>.buildTargetsIdle at 0x7f43988c09a0>
1605616 09:30:14.500927 Removing idle function <bound method Command.runAsyncCommand of <bb.command.Command object at 0x7f43a961c350>>
1605616 09:30:14.573274 Exception Traceback (most recent call last):
File "/OE/build/oe-core/bitbake/lib/bb/server/process.py", line 435, in idle_thread_internal
retval = function(self, data, False)
^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/OE/build/oe-core/bitbake/lib/bb/cooker.py", line 1487, in buildTargetsIdle
retval = rq.execute_runqueue()
^^^^^^^^^^^^^^^^^^^^^
File "/OE/build/oe-core/bitbake/lib/bb/runqueue.py", line 1651, in execute_runqueue
return self._execute_runqueue()
^^^^^^^^^^^^^^^^^^^^^^^^
File "/OE/build/oe-core/bitbake/lib/bb/runqueue.py", line 1567, in _execute_runqueue
if self.rqdata.prepare() == 0:
^^^^^^^^^^^^^^^^^^^^^
File "/OE/build/oe-core/bitbake/lib/bb/runqueue.py", line 1290, in prepare
unihashes = bb.parse.siggen.get_unihashes(ready)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/OE/build/oe-core/bitbake/lib/bb/siggen.py", line 713, in get_unihashes
with self.client() as client:
File "/usr/lib/python3.12/contextlib.py", line 137, in __enter__
return next(self.gen)
^^^^^^^^^^^^^^
File "/OE/build/oe-core/bitbake/lib/bb/siggen.py", line 595, in client
self._client = hashserv.create_client(self.server, **self.get_hashserv_creds())
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/OE/build/oe-core/bitbake/lib/hashserv/__init__.py", line 88, in create_client
raise e
File "/OE/build/oe-core/bitbake/lib/hashserv/__init__.py", line 80, in create_client
c.connect_unix(*a)
File "/OE/build/oe-core/bitbake/lib/bb/asyncrpc/client.py", line 241, in connect_unix
self.loop.run_until_complete(self.client.connect())
File "/usr/lib/python3.12/asyncio/base_events.py", line 687, in run_until_complete
return future.result()
^^^^^^^^^^^^^^^
File "/OE/build/oe-core/bitbake/lib/bb/asyncrpc/client.py", line 152, in connect
self.socket = await self._connect_sock()
^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/OE/build/oe-core/bitbake/lib/bb/asyncrpc/client.py", line 85, in connect_sock
sock.connect(os.path.basename(path))
FileNotFoundError: [Errno 2] No such file or directory
broke the idle_thread, exiting
1605616 09:30:14.673756 Exiting (socket: True)
1605616 09:30:14.683153 Exiting as we could obtain the lock
sys:1: ResourceWarning: unclosed file <_io.TextIOWrapper name='/OE/build/oe-core/bitbake-cookerdaemon.log' mode='a+' encoding='UTF-8'>
sys:1: ResourceWarning: unclosed <socket.socket fd=17, family=1, type=1, proto=0>
ResourceWarning: Enable tracemalloc to get the object allocation traceback
(Bitbake rev: 550c86969e5a137ffef61b08a520a4855232fb1c)
Signed-off-by: Martin Jansa <martin.jansa@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The test_single_layer_page test case consistently fails. It is not obvious why
but if we change the argument in the following from 8 to 7 it passes.
url = reverse("layerdetails", args=(TestProjectPage.project_id, 8))
E selenium.common.exceptions.TimeoutException: Message: An element matching "#change-notification" should be visible
=========================== short test summary info ============================
FAILED ../bitbake/lib/toaster/tests/functional/test_project_page.py::TestProjectPage::test_single_layer_page
(Bitbake rev: c7e12145d8ea641925e3c06ba4f11c2dae66288a)
Signed-off-by: Tim Orling <tim.orling@konsulko.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
In line with changes in gen_fixtures.py:
* Add projectscarthgap
- Add Scarthgap to slot 1.
* Move Kirkstone down to slot 4
* Drop projectdunfell
- Drop EOL Dunfell from slot 5
(Bitbake rev: a4ae788f95d8e54713528374a9171c636aa747c5)
Signed-off-by: Tim Orling <tim.orling@konsulko.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
gen_fixtures.py:
* Add Scarthgap to slot #1
* Drop EOL Mickledore
* Move Kirkstone to lower slot
* Drop optional slot for EOL Dunfell
Refresh oe-core.xml and poky.xml
(Bitbake rev: 11c7214a292cd296eed5490b6726e672f9179131)
Signed-off-by: Tim Orling <tim.orling@konsulko.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Some distributions (namely Fedora Core 40) have started replacing
wget with wget2. There are some changes to wget2 that make it
incompatible with wget:
1. ftp/ftps is not supported anymore
2. progress 'dot' is not yet supported
3. Relative paths in -P and -O are not correctly dealt with
Item 1: Is already dealt with since Scarthgap by only adding the
option --passive-ftp when the URL specifies ftp/sftp. While that
won't help if ftp/sftp is actually required it at least does
not break http/https downloads.
Item 2: While not supported it at least does not break the operation.
Item 3: If there are relative path components in -P or -O then wget2
only deals with them correctly if there is one, and only one, relative
path component at the beginning of the path:
-P ./downloads works
-P ../downloads works
-P ../../downloads does not work
-P ./../downloads does not work
-P /home/user/downloads/../downloads does not work
In cases where there are more than one relative path component at
the beginning of the path and/or one or more reltaive path
component somewhere in the middle or end of the path, wget2 aborts
with the message Internal error: Unexpected relative path: '<path>')
Such can happen if DL_DIR includes relative path components e.g.
DL_DIR = "${TOPDIR}/../../downloads".
This patch canonicalizes DL_DIR before it is passed to wget.
(Bitbake rev: 3e4208952b086adc510e78c1c5f9cf4550d79dc9)
Signed-off-by: Rudolf J Streif <rudolf.streif@ibeeto.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The save comes with an IO overhead which can slow down the rehash loop in bitbake
a lot. We only needed to do this when recipes were doing unihash cache copying. Now
they aren't doing that, drop this IO pain point.
(Bitbake rev: dfc15ef99302dea22a051c9eb8398ffd5cf1fc20)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The code in OE-Core using this has been replaced with something more fit
for purpose. Drop these function calls as they were never a great idea in the
first place and cause IO slowdown for runqueue needing to sync the cache.
(Bitbake rev: 2c8fa57778c4bd2a5c48a60b701ac57de4289cb2)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Upstream changed their urls, update our test to match.
(Bitbake rev: dc391b86540ec5e0a0f1d811c776a22d443b1c06)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The default connection timeout for websockets is 10 seconds, so use the
provided client timeout instead (which defaults to 30 seconds).
(Bitbake rev: 23681775e5941e54ebead469addf708fca1e6beb)
Signed-off-by: Joshua Watt <JPEWhacker@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
On Fedora40, "localhost" sometimes resolves to ::1 and sometimes to 127.0.0.1
and python only binds to one of the addresses, leading to test failures.
Use 127.0.0.1 explicitly to avoid problems of the name resolution, we're trying
to test things other than the host networking.
(Bitbake rev: 9adc6da42618f41bf0d6b558d62b2f3c13bedd61)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When we intercepted the file download to a temp file, we broke the
exist/size checks which need to happen before the rename. Correct
the ordering.
For some reason, python 3.12 exposes this problem in the selftests
differently to previous versions.
(Bitbake rev: c56bd9a9280378bc64c6a7fe6d7b70847e0b9e6d)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When switching from normal mode to stream mode, skip calling
self._set_mode() again because this will cause a recursion into the
_set_mode() function and causes problems.
Also cleanup some of the error checking during this process
This bug affected when a client would attempt to switch from one stream
mode to another, and meant that the server would get an invalid message
from the client. This would cause the server to disconnect the client,
and the client would then reconnect in normal mode which was the mode it
wanted anyway and thus it would carry on without any errors. This made
the bug not visible on the client side, but resulting in a lot of
backtrace JSON decoding exceptions in the server logs.
(Bitbake rev: 1826bc41ab3369ac40034c5eaf698748b769b881)
Signed-off-by: Joshua Watt <JPEWhacker@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Similar to looking up unihashes, use the batch API when checking if a
unihash exists to speed up lookups
(Bitbake rev: 0ac521ff37b578f7487bca0eccc7dc9e5974991b)
Signed-off-by: Joshua Watt <JPEWhacker@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Batching support on the client side has proven to be a much more
effective way of dealing with server latency than multiple client
connections and is also much nicer on the server, so drop the client
pool support from asyncrpc and the hash server
(Bitbake rev: 6f80560f1c7010d09fe5448fdde616aef8468102)
Signed-off-by: Joshua Watt <JPEWhacker@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Drops support for client pools, since batching support in the client
code has proven to be much more effective
(Bitbake rev: 85dafaf8e070459f7de7bfb37300d8b60a27002e)
Signed-off-by: Joshua Watt <JPEWhacker@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
cooker: We can call multiprocessing close() unconditionally and tweak a
comment give 3.8 is now the minimum version.
lib/bb: We can drop the logger addition code only needed before 3.6
asyncrpc/hashserv: Since the minimum version is 3.8, we can drop the
conditional code.
(Bitbake rev: 16f4386400f88ba50605307961c248bef09895c1)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We've seeing profiling tracebacks when parse errors occur during
profiling. Try and avoid these but not processing invalid profiles.
(Bitbake rev: 171bd9dd575307fbd61b5179ad86131d76add067)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
It makes sense to switch to a more recent version and keep up to date
with upstream changes and things like new python version support.
(Bitbake rev: f5462156036e71911c66d07dbf3303cde862785b)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
SO_REUSEPORT is a socket option that allows multiple servers to listen
on the same TCP port, and the kernel will automatically load balance the
connections between them. This is particularly helpful for the hash
server since it runs in a single thread. To take advantage of a
multi-core server, multiple servers can be started in parallel with this
option (up to 1 per CPU) and the kernel will load balance between them.
(Bitbake rev: d72d5a7decb489e2af0ebc43cfea0ca3e4353e9b)
Signed-off-by: Joshua Watt <JPEWhacker@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Uses the batching API of the client to reduce the effect of latency when
making multiple queries to the server
(Bitbake rev: a54734b4ac2ddb3bce004e576cf74d6ad6caf62a)
Signed-off-by: Joshua Watt <JPEWhacker@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Changes the stream mode to do "batch" processing. This means that the
sending and reciving of messages is done simultaneously so that messages
can be sent as fast as possible without having to wait for each reply.
This allows multiple messages to be in flight at once, reducing the
effect of the round trip latency from the server.
(Bitbake rev: e768d0f17bdb97f6ff013ec3a41f182fecd47a55)
Signed-off-by: Joshua Watt <JPEWhacker@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Task dependency data is becoming unwieldy with the number of indices it
contains. Convert it to use a named tuple instead, which allows members
to be indexed by a named property or an index (which allows it to retain
backward compatibility).
(Bitbake rev: 26446cca4d22734c3f1b328a205c169dadb7e494)
Signed-off-by: Joshua Watt <JPEWhacker@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Adds a --quiet option to suppress the message for each ping, and report
the median ping time.
(Bitbake rev: 3c85b5e2d9b9c39507ed362aaa115b7f6f155966)
Signed-off-by: Joshua Watt <JPEWhacker@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Improve the rehash code to query unihashes in parallel since this is more
efficient on slower links.
(Bitbake rev: c1949d5350342eaaf6ab988d7bfba99496d55523)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Improve the runqueue init code to call unihash queries in parallel since
this is faster and more efficient, particularly on slower links with longer
round trip times.
The call to the function from cooker is unneeded since that function calls
prepare() and hence this functionality will already have run, so drop
that obsolete call.
(Bitbake rev: 721c97a115a7a4bf21955be79391bd6e0099f40e)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The initial hash serve loop exits in the case where interrupts are present
but probably checks a bit too often. Tweak that and also allow the slow
rehash loop to break on interrupt, improving bitbake Ctrl+C response.
(Bitbake rev: 4534365591fd17bcc2b684900863b67bc69519ae)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
With hashserve enabled, there are two slow paths/loops, one at initial runqueue
generation and also during the rehash process when new outhashes are found.
Add timing information at the hashserve log level for when these loops
take longer than 30s or 60s overall. This will leave evidence in the logs when
things are running particularly slowly.
(Bitbake rev: 6c357ede08e0b2a93bdaad2c1d631994faf2b784)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Improves the way statistics are reported for the stress test. This makes
it easier to compare them to the ping test
(Bitbake rev: ce166ae25793c11b0a190c531bef0c296fd74497)
Signed-off-by: Joshua Watt <JPEWhacker@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Adds a ping subcommand to bitbake-hashclient which can be useful to
measure connection latency
(Bitbake rev: 337487fdffae92091fc33b2346d46c39db5a130f)
Signed-off-by: Joshua Watt <JPEWhacker@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
I don't know why there is hardcoded knowledge of S in the fetcher but there
shouldn't be and the OE unpack changes highlight this doing things it
shouldn't.
Drop the S reference and use rootdir which is the only place it should
be touching.
(Bitbake rev: 84f102954e10a3390fca9c26d5c3c639e952a2c9)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Simplify the importone() hook:
- to make it independent from the "history" mode which is
client specific.
- remove the "history" parameter
- we want all values to be imported for binary
reproducibility purposes.
- using the store_value() function (which warrants
you don't save the same value twice and doesn't write
when you're using a read-only server) is enough.
(Bitbake rev: 000704a53470ab1ead840403b5531f22ebf1fd49)
Signed-off-by: Michael Opdenacker <michael.opdenacker@bootlin.com>
Cc: Joshua Watt <JPEWhacker@gmail.com>
Cc: Tim Orling <ticotimo@gmail.com>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Add a test_checksum_value() to test whether
a (version, pkgarch, checksum, value) entry already
exists in the database.
This is used to protect the store_value() function from
an error when trying to store a duplicate entry in the database.
Also check whether the current database is open in read-only mode.
(Bitbake rev: b7f6c085a7cf8ac83695242a0299e2d5f7abc69a)
Signed-off-by: Michael Opdenacker <michael.opdenacker@bootlin.com>
Cc: Joshua Watt <JPEWhacker@gmail.com>
Cc: Tim Orling <ticotimo@gmail.com>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Remove a possible race condition by allowing a read-only
server to create the PR table anyway. This avoids a failure
if both a read-only and read-write server try to access
an empty database at the same time.
(Bitbake rev: b171caec5ebbe579bf4b8b2005930240ae5c8ce2)
Signed-off-by: Michael Opdenacker <michael.opdenacker@bootlin.com>
Suggested-by: Joshua Watt <jpewhacker@gmail.com>
Cc: Tim Orling <ticotimo@gmail.com>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
sqlite3 can allow multiple processes to access the database
simultaneously, but it must be opened correctly. The key change is that
the database is no longer opened in "exclusive" mode (defaulting to
shared mode). In addition, the journal is set to "WAL" mode, as this is
the most efficient for dealing with simultaneous access between
different processes. In order to keep the database performance,
synchronous mode is set to "off". The WAL journal will protect against
incomplete transactions in any given client, however the database will
not be protected against unexpected power loss from the OS (which is a
fine trade off for performance, and also the same as the previous
implementation).
The use of a database cursor enabled to remove the _execute() wrapper.
The cursor automatically makes sure that the query happens in an atomic
transaction and commits when finished.
This also removes the need for a "dirty" flag for the database and
for explicit database syncing, which simplifies the code.
(Bitbake rev: 385833243c495dc68ec26a963136c1ced3f272d0)
Signed-off-by: Michael Opdenacker <michael.opdenacker@bootlin.com>
Signed-off-by: Joshua Watt <JPEWhacker@gmail.com>
Cc: Tim Orling <ticotimo@gmail.com>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
