| Age | Commit message (Collapse) | Author |
|---|
|
Tweak the deadlock breaking messages to be explict about which task is
blocked on which other task. The messages currently imply it is "freeing"
the blocking task which is confusing.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
We have to prefer one multiconfig over another when deferring tasks, else
we'll have cross-linked build trees and nothing will be able to build.
In the original population code, we sort like this but we don't after
rehashing. Ensure we have the same sorting after rehashing toa void
deadlocks.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Prevent the scheduler from starting new tasks if the current cpu or io
pressure is above a certain threshold and there is at least one active
task. This threshold can be specified through the
"BB_PRESSURE_MAX_{CPU|IO}" variables in conf/local.conf.
The threshold represents the difference in "total" pressure from the
previous second. The pressure data is discussed in this oe-core commit:
061931520b buildstats.py: enable collection of /proc/pressure data
where one can see that the average and "total" values are available.
From tests, it was seen that while using the averaged data was somewhat
useful, the latency in regulating builds was too high. By taking the
difference between the current pressure and the pressure seen in the
previous second, better regulation occurs. Using a shorter time period
is appealing but due to fluctations in pressure, comparing the current
pressure to 1 second ago achieves a reasonable compromise. One can look
at the buildstats logs, that usually sample once per second, to decide a
sensible threshold.
If the thresholds aren't specified, pressure is not monitored and hence
there is no impact on build times. Arbitary lower limit of 1.0 results
in a fatal error to avoid extremely long builds. If the limits are higher
than 1,000,000, then warnings are issued to inform users that the specified
limit is very high and unlikely to result in any regulation.
The current bitbake scheduling algorithm requires that at least one
task be active. This means that if high pressure is seen, then new tasks
will not be started and pressure will be checked only for as long as at
least one task is active. When there are no active tasks, an additional task
will be started and pressure checking resumed. This behaviour means that
if an external source is causing the pressure to exceed the threshold,
bitbake will continue to make some progress towards the requested target.
This violates the intent of limiting pressure but, given the current
scheduling algorithm as described above, there seems to be no other option.
In the case where only one bitbake build is running, the implications of
the scheduler requirement will likely result in pressure being higher
than the threshold. More work would be required to ensure that
the pressure threshold is never exceeded, for example by adding pressure
monitoring to make and ninja.
Signed-off-by: Aryaman Gupta <aryaman.gupta@windriver.com>
Signed-off-by: Randy Macleod <randy.macleod@windriver.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
|
|
Signed-off-by: Jose Quaresma <jose.quaresma@foundries.io>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
|
|
When we call the remove with recurse=True we first check if the
remove operation is safe in _check_unsafe_delete_path.
But the check is been done on the path instaed of the expanded
python glog.
Signed-off-by: Jose Quaresma <jose.quaresma@foundries.io>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
|
|
Adds TCP Keep Alive support to the async RPC server. This should help
prevent file descriptor exhaustion on the server when client connections
are interrupted and the socket never closes (e.g. no FIN is sent from
the client).
A keep alive is sent after 30 seconds of inactivity, then every 15
seconds after that up to a maximum of 2 minutes.
Signed-off-by: Joshua Watt <JPEWhacker@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
A long time ago, we made DL_DIR a final fallback for the local fetcher.
Since then we added checksum support and task hashes and the world
has changed. There were warnings added some time ago if this fallback
triggers and it is now time to drop it entirely.
The original use case was for sstate however the sstate code now sets
FILESPATH correctly so DL_DIR is no longer needed.
There have been a few small bugs exposed by this change, missing mkdir
calls and some minor test issues that needed tweaks. In general this
simplifies and improves the fetcher code flow though.
This completes a cleanup that ensures local files are correctly covered
at parse time which ensures rebuilds and reparses happen at the right
times.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
If the mirrors code is trying to create a symlink and the
parent directory doesn't exist, as might be the case for sstate
mirrors where the fetch is into a subdir, it can silently fail.
Ensure the directory exists in this case to avoid issues.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
If the local fetcher was not able to find the file anywhere but it
was included in the SRC_URI for checksumming just make it a fatal
error. Ensure a list of searched locations is included too to match
the runtime error that would have resulted.
Signed-off-by: Paulo Neves <ptsneves@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
* in recipe with 17 git repos in SRC_URI I've accidentally pasted one SRCREV to
be one character shorter and because fetcher uses:
if not ud.revisions[name] or len(ud.revisions[name]) != 40 or (False in [c in "abcdef0123456789" for c in ud.revisions[name]]):
to decide which SRCREV values are fixed SRCREVs this one was
considered as tag or branch name, because it was only 39 chars long
The original error message wasn't very helpful as it doesn't show
which repo or which SRCREV was considered missing:
do_fetch: Bitbake Fetcher Error: FetchError("Recipe uses a floating tag/branch without a fixed SRCREV yet doesn't call bb.fetch2.get_srcrev() (use SRCPV in PV for OE).", None)
with SRCPV included in PV as error recomments it's a bit better:
bb.data_smart.ExpansionError: Failure expanding variable SRCPV, expression was ${@bb.fetch2.get_srcrev(d)} which triggered exception FetchError: Fetcher failure: Unable to resolve '0a92994d729ff76a58f692d3028ca1b64b145d9' in upstream git repository in git ls-remote output for github.com/Maratyszcza/FP16
The variable dependency chain for the failure is: SRCPV -> PV -> WORKDIR -> T
with this change the first error will read:
do_fetch: Bitbake Fetcher Error: FetchError("Recipe uses a floating tag/branch '0a92994d729ff76a58f692d3028ca1b64b145d9' for repo 'github.com/Maratyszcza/FP16' without a fixed SRCREV yet doesn't call bb.fetch2.get_srcrev() (use SRCPV in PV for OE).", None)
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Currently if you trigger one of the comment errors, the newline characters
are stripped and the line numbers are incorrect. In one case it prints
the empty line which is also unhelpful.
Rework the code around these errors so the line numbers are correct
and the lines in question are more clearly displayed complete with newlines
so the user can more clearly see the error.
I also added a couple of simplistic test cases to ensure that errors
are raised by the two known comment format errors.
[YOCTO #11904]
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
As specified by git submodule manual relative urls can start either
with '..' or './', second case was incorrectly managed leading to an
interpretation of urls starting with './' as absoulte urls.
Signed-off-by: Gennaro Iorio <gennaro.iorio@schindler.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
I realised only the first logging message was being displayed in a given
parsing process. The reason turned out to be the UI handler failing
with a "pop from empty list". The default handler was then lost and
no further messages were processed.
Fix this by catching the exception correctly in the connection writer code.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
The f.close() statement should have been removed in
459ad524756a3f9b50feeedf31e33502dceae8d5.
Signed-off-by: Ola x Nilsson <ola.x.nilsson@axis.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
With PREMIRRORS set and BB_NO_NETWORK = "1" bitbake should not try to
fetch into non-initialized git directory if tarball is broken (or not in
gzip format)
[Yocto 14822]
Signed-off-by: Pavel Zhukov <pavel.zhukov@huawei.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
When atexit functions run, stdout and stderr operations may fail, e.g.
when output is piped to less but has been exited by the user.
This removes error print from output of "bitbake -e sqlite3 | less"
if user presses "q" before bitbake has finished processing:
[Errno 32] Broken pipeError in atexit._run_exitfuncs:
Traceback (most recent call last):
File "/home/builder/src/poky/bitbake/lib/bb/event.py", line 135, in print_ui_queue
sys.stdout.flush()
Signed-off-by: Mikko Rapeli <mikko.rapeli@bmw.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Existing test uses fake local repo for better performance. Adding
test which uses real (but still small) project hosted on
yoctoproject.org.
Signed-off-by: Pavel Zhukov <pavel.zhukov@huawei.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Function "git" is defined in super class FetcherTest already.
Signed-off-by: Pavel Zhukov <pavel.zhukov@huawei.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
As reported by Martin Jansa <Martin.Jansa@gmail.com>:
bitbake/lib/bb/cooker.py:16: DeprecationWarning: module 'sre_constants' is deprecated
import sre_constants
it's deprecated since 3.11 with:
https://github.com/python/cpython/issues/91308
The correct replacement for our usage is re.error so use that instead.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
In theory this should have been worked around but is still occurring. Add
it to the list of things to ignore when bitbake is shutting down.
Traceback (most recent call last):
File "/usr/lib64/python3.9/threading.py", line 973, in _bootstrap_inner
self.run()
File "/home/pokybuild/yocto-worker/oe-selftest-fedora/build/bitbake/lib/bb/server/process.py", line 698, in startCallbackHandler
event = self.reader.get()
File "/home/pokybuild/yocto-worker/oe-selftest-fedora/build/bitbake/lib/bb/server/process.py", line 722, in get
res = self.reader.recv_bytes()
File "/usr/lib64/python3.9/multiprocessing/connection.py", line 221, in recv_bytes
buf = self._recv_bytes(maxlength)
File "/usr/lib64/python3.9/multiprocessing/connection.py", line 426, in _recv_bytes
return self._recv(size)
File "/usr/lib64/python3.9/multiprocessing/connection.py", line 384, in _recv
chunk = read(handle, remaining)
TypeError: an integer is required (got type NoneType)'
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
We're seeing UI deadlocks occasionally and this is possibly due to the
use of a daemonic thread in the UI event queue processing. This thread
could terminate holding a threading Lock() which would cause issues
for the process when exitting.
Change the shutdown process to handle this more cleanly.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
The open coded lock acquire/release in the UI event handler doesn't
cover the case an exception occurs and if one did, it could deadlock
the code. Switch to use 'with' statements which would handle this
possibility.
We have seen deadlocks in the UI at exit this so this removes a
possible cause.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Basic test to cover functionality of BB_FETCH_PREMIRRORONLY using
local git repository. Local repository has been chosen to allow easy
manipulation with the repo to simulate behaviour reported in
[Yocto 13233]
Signed-off-by: Pavel Zhukov <pavel.zhukov@huawei.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
This should fix [Yocto 13353] and related to [Yocto 13233] as well.
Previously if git repo mirror has been updated in between of two builds
fetcher of the second build didn't try updated mirror but switched to
git clone from upstream instead. This is problem for offline builds.
Fix this to raise MirrorException if BB_FETCH_PREMIRRORONLY has been
specified by the mirror doesn't contain SRC_REV.
[YOCTO #13353]
[YOCTO #13233]
Signed-off-by: Pavel Zhukov <pavel.zhukov@huawei.com>
Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
This allows OE to depend on the unihash copy functionality.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
We see rare failures in eSDK generation with zero sized unihash cache files. This is
almost certainly due to races in the cache file being updated. Add a copy function
where the cache file can be copied with the lock held to avoid this.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Very occasionally we see errors in eSDK testing on the autobuilder where the task
hashes in the eSDK don't match what was just built. I was able to inspect one of
these build directories and noticed that the bb_unihashes.dat file in the eSDK
was zero sized. Whilst inspecting the code to understand the cause, I noticed that
updated hashes are not saved out in subsequent updates of the values in the rehash
process.
Add a missing sync call to ensure this happens.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
* fixes:
bitbake/lib/bb/fetch2/osc.py:93: DeprecationWarning: invalid escape sequence '\d'
match = re.match('<directory ?.* rev="(\d+)".*>', output)
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Add support to query latest revision. This makes it possble to use
osc fetcher without specifying the rev parameter.
Signed-off-by: Gunjan Gupta <viraniac@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
We currently have no API to be able to remove all the potential stamps of a
task. It is unusual to need to do this, particularly as you could race against
other things happening in the system but we do have a use case for this in
cleaning up sysroots in OE-Core. The alternative is to mess with CLEANMASK in
OE-Core but that is just going to add potential for errors.
We need the first part of the make_stamp() function so separate that out so
it can be called seperately.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
If SRC_URI contains python function that extends vardepvalueexclude its
value is being tracked by sstate-cache, which can lead to rebuilds if
value is set dynamically (for example gerrit replicas).
Return empty string if vardepvalueexclude is checked to fix this
behaviour.
Signed-off-by: Tomasz Dziendzielski <tomasz.dziendzielski@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
The current fetcher seemed to have some issues that made it difficult when
trying to use the same. This patch fixes the following
* Make consistent use of the path that needs to be used as oscdir
* The path mentioned in os.access in download function was not same as
ud.moddir which would result into invoking of fetch command instead of
update command even if directory already existed
* Before creating oscrc, make sure oscdir exists and create it if it does
not exist
* Updated the configuration to use apiurl and added a new parameter to
control whether http or https needs to be used to connect to apiurl
Signed-off-by: Gunjan Gupta <viraniac@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
compare_sigfiles() recursively calculates differences on all dependent
tasks with changed hashes. This is done in arbitrary/alphabetical order, and
only the last of those results is returned, while everything else is discarded.
This changes the behavior to instead return the first difference and not calculate
any more, which significantly speeds up diffs of tasks with many dependencies.
Signed-off-by: Adriaan Schmidt <adriaan.schmidt@siemens.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
We don't have less in HOSTTOOLS in OE and this can confuse git. Force the
pager to cat to be consistent and minimal everywhere.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
File names containing colons cause split() to return a list with more
than two elements, which will lead to a stack trace ending in:
ValueError: too many values to unpack (expected 2)
Split only once at the last colon, thereby making sure that only two
elements are returned.
Signed-off-by: Roland Hieber <rhi@pengutronix.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Users are misreading this message. Reorder the wording to make
the empahsis clearer on the shell environment.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
We're using the wrong data store when trying to locate siginfo files,
fix this. Thanks to Gregory Lumen <gregorylumen@microsoft.com> for
spotting.
[YOCTO #14774]
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
The path has been encoded by urllib.parse.quote(), so decode it back for ssh.
Fixed when fetch from PREMIRRORS via ssh:
$ bitbake bonnie++ libsigc++-2.0 -cfetch
scp: /path/to/downloads/libsigc%2B%2B-2.10.7.tar.xz: No such file or directory
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
This probably means the osc fetcher isn't being used but fix the missing
parameter.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
This is set at the start of the loop anyway so it does nothing. Drop
the pointless code.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
The function has a loop where the variable is never used which I was going
to fix but the entire function never seems to be called so remove it entirely.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
Richard Purdie
Aryaman Gupta
Jose Quaresma
Joshua Watt
Paulo Neves
Martin Jansa
Gennaro Iorio
Ola x Nilsson
Pavel Zhukov
Mikko Rapeli
Gunjan Gupta
Tomasz Dziendzielski
Schmidt, Adriaan
Roland Hieber
Robert Yang