| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
With the move to a server idle thread, we always need threading. The
existing accessor functions could end up turning this off!
I was going to hold the lock whilst changing it, check if the value
was already set, cache the result and also fix the event code to always
release the lock with a try/finally.
Instead, disable the existing functions and use a with: block
to handle the lock, keeping things much simpler.
(Bitbake rev: 645c9d3b50e55f69b222cc338373cdfd91d524ce)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When idle handlers want to exit, returning "False" isn't very clear
and also causes challenges with the ordering of the removing the idle
handler and marking that no async command is running.
Use a specific class to signal the exit condition allowing clearer code
and allowing the async command to be cleared after the handler has been
removed, reducing any opportunity for races.
(Bitbake rev: 102e8d0d4c5c0dd8c7ba09ad26589deec77e4308)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
| |
When finishing a command, we need to ensure any parsing processes that may have
been started are cleaned up before we reset the cooker state.
(Bitbake rev: 6569ab64bea35de21acc89053ba76e2828163f3f)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
| |
(Bitbake rev: 89435442946767cfe58eedde363802add8f1ab29)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently if the idle functions loop suffers a traceback, it is
silently dropped and there is no log message to say what happened.
This change at least means the traceback is in the cooker log, making
some debugging possible.
Add some logging to show when handlers are added/removed to allow
a better idea of what the server code is doing from the server log
file.
(Bitbake rev: 9cf3102dc36513124fe5ead2f1e448b51833b6ac)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
As far as I could tell, the current code could result in some strange
situations where some data was set back to the original data store copy
but the multiconfig data was not restored. There are also some changes made
to the datastore which did not persist.
The data store was also being reset at every client reset, which seems
a little excessive if we can reset it to the original condition properly.
Move the __depends -> __base_depends rename into databuilder along with
the __bbclasstype change so these are saved in the original data.
Tweak the databuilder code to be clearer and easier to follow on which
copies are where, then save copies of all the mc datastores.
Finally, drop the cache invalidation upon reset for the base config
as we shouldn't need that now (oe-selftest -r tinfoil works with memory
resident bitbake which was the original reproducer requiring that change).
(Bitbake rev: 5f8b9b9c35b4ec0c8c539bf54ca85f068f4a5094)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
| |
Currently heartbeat events are always generated by the server whilst it is
active. Change this so they only appear when builds are running, which is
when most code would expect to be executed. This removes a number of races
around changes in the datastore which can happen outside of builds.
(Bitbake rev: 8c36c90afc392980d999a981a924dc7d22e2766e)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
| |
If there are events queued and there is an exception in the main loop
of the UI code, it will print tracebacks on the console indefinitely.
Avoid that by improving the loop exit conditions.
(Bitbake rev: 2d0940b920a22b244f3ba6849c7cd019578386b4)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
| |
Joshua Watt pointed out maintaining the counting on both sides of the
connection isn't needed. Remove the receiver side counting and simplify
the code, also allowing errors if the counts do go out of sync.
(Bitbake rev: aeacfd391903fe68ae600470fc2bbad0502d401e)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
| |
By inspection, tinfoil handles two of the three command exit cases but
one is missing. Add the CommandExit case in case this is the cause of
one of our recipetool/devtool hangs. Regardless, the fix is necessary.
(Bitbake rev: eadddd94835b6b6a8517dfed3d29e6dbb2d35988)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
| |
We're still seeing occasional SiggenRecipeInfo coherency issues, add
some further reset points into the parsing code to ensure the cache is
cleared before reparsing.
(Bitbake rev: 26ed783caf11dc9ebf53d3790681eb44c0c360f0)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I've been seeing event handlers where 'd' seems to disappear half way through
event handler execution. This is problematic when multiple threads are active
since this code assumes single threading.
The easiest fix is to change the handler function calls to contain d as a
parameter as we do elsewhere for other functions. This will break any non-text
handlers but I was only able to spot one of those in runqueue. It will also
break handlers than call functions that assume 'd' is in the global namespace
but those failures should be obvious and we can fix those to pass d around.
This solution avoids manipulating builtins which was always a horrible thing
to do anyway and solves the issue without needing locking, thankfully.
(Bitbake rev: 1e12f0a4b592dacd006d370ec29cd71d2a44312e)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There is a bug in the current cache code where the restored data structures
were "inverted" leading to some very weird issues, not sure how anything worked
like that, this patch fixes it.
Also fix some issues with multiconfig cache ordering problems by resetting
the stream counters when appropriate.
(Bitbake rev: cd06beb948eff5eaf2d474f5b127d51a61b0b2ef)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We've seen cases where the bitbake.sock file appears to disappear but the
server continues to hold bitbake.lock. The most likely explaination is
that some previous build directory was moved out the way, a server there
kept running, eventually exited and removed the sock file from the wrong
directory.
To guard against this, save the inode information for the sock file and check
it before deleting the file. The new code isn't entirely race free but should
guard against what is a rare but annoying potential issue.
(Bitbake rev: b02ebbffdae27e564450446bf84c4e98d094ee4a)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
| |
Tweak the code to remove duplication and only set if the attribute isn't
already there to avoid overwriting.
(Bitbake rev: 513e6c4e9233e0d0bc31e1169077fdbf9aaf4ec3)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The data in SiggenRecipeInfo is large and has a lot of duplication. The size
causes a few problems, impacting:
- bitbake's overall memory usage
- the amount of data sent over IPC between parsing processes and the server
- the size of the cache files on disk
- the size of "sigdata" hash information files on disk
The data consists of strings (some large) or frozenset lists of variables.
To reduce the impact we can:
a) deplicate the data
b) pass references to the object on the second usage
(e.g. over IPC or saving into pickle).
This patch does this for SiggenRecipeInfo mostly behind the scenes
but we do need a couple of reset points so that streamed data is written
correctly on the second usage.
(Bitbake rev: 9a2b13af483c20763d6559a823310954884f6ab1)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
| |
Add a simple ping command so the UI can check the server is still there.
(Bitbake rev: fd3359de0b9f18fac187a629df203be0b2c87545)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
| |
(Bitbake rev: 8f9402b291421ebcbf0a3ab97791c87af4b3f36e)
Signed-off-by: Frank de Brabander <debrabander@gmail.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
| |
Removed in BitBake through
https://git.openembedded.org/openembedded-core/commit/?id=3667e589ba16eb261cfd72c2b11429f482c239f6
(Bitbake rev: 50261fe047dfb41c3ce9d91b9b8245ce465d69b3)
Signed-off-by: Michael Opdenacker <michael.opdenacker@bootlin.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
| |
(Bitbake rev: 4f57853f46423f9e50b0140cd3d4aaffdcd5a08d)
Signed-off-by: Michael Opdenacker <michael.opdenacker@bootlin.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Namespace in this context means a branch, a tag, etc., clarify
it in the description. Also, fix a typo "a any", replace with
plain "any".
This patch is based of feedback on new applied patch
d32e5b0e ("fetch2/git: Prevent git fetcher from fetching gitlab repository metadata")
(Bitbake rev: b4999425c812b25cb359d5163d11e3c1b030dc28)
Signed-off-by: Marek Vasut <marex@denx.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The application order of override syntax :append, :prepend, :remove is
inobvious and undocumented. The order does not match variable parse
history, i.e. output of "bitbake -e", either.
Add note documenting the exact order in which :append, :prepend, :remove
are applied to variable in lib/bb/data_smart.py getVarFlag(). Add note
that this order does not match the variable parse history order. This
is mostly to prevent others from running into this and scratching their
heads, trying to find out what is going on.
Reviewed-by: Quentin Schulz <foss+yocto@0leil.net>
(Bitbake rev: 7379c2855b8497e56481d1ec7b5953e850550b85)
Signed-off-by: Marek Vasut <marex@denx.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Converts the main bitbake program to use argparse instead of the
deprecated optparse.
The resulting Namespace returned by argparse should be equivalent to the
one returned from optparse; the only major difference is that the
positional "target" arguments are consumed by argparse and returned as
the "targets" property instead of an additional argument from
parse_args().
(Bitbake rev: bb2ea00274a594b7cc87a7cb0b165e9b28f6f3f4)
Signed-off-by: Joshua Watt <JPEWhacker@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
|
| |
Log when the socket file already exists and is removed before
recreating a new socket.
Log when unlinking the socket file failed.
(Bitbake rev: cfd7c9899f988bab6d9fe7bbfbdb60603fb5ed34)
Signed-off-by: Frank de Brabander <debrabander@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
| |
We need to be able to exclude dependencies from the python module
dependency code. Add support for the vardepexclude flag for these. It
only works from the configuration namespace rather than per recipe
for efficiency.
(Bitbake rev: 1aa672b01037fda4ca82f2c7e394783287c09ecd)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Moving code into python modules is a very effective way to reduce parsing
time and overhead in recipes. The downside has always been that any
dependency information on which variables those functions access is lost
and the hashes can therefore become less reliable.
This patch adds parsing of the imported module functions and that dependency
information is them injected back into the hash dependency information.
Intermodule function references are resolved to the full function
call names in our module namespace to ensure interfunction dependencies
are correctly handled too.
(Bitbake rev: 605c478ce14cdc3c02d6ef6d57146a76d436a83c)
(Bitbake rev: 91441e157e495b02db44e19e836afad366ee8924)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
"fn" can mean different things in bitbake, we added support for class
extensions and then mutlticonfigs by extending it. In siggen, it generally
means that mc is prefixed to it and that it is a virtual filename.
Replace "fn" with "mcfn" in the code to make this clearer as if I'm getting
confused, everyone else likely is as well. "mcfn" is sometimes referred
to as taskfn as well but mcfn is probably the easiest to understand as the
taskname isn't included.
(Bitbake rev: e1c1139ab90f8da1b5036db11d943daefbe87859)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The current method of passing either a task's datastore, or
dataCaches and a filename into the stamp functions is rather
horrible.
Due to the different contexts, fixing this is hard but we do control
the bitbake side of the API usage so we can migrate those to use other
functions and then only support a datastore in the public bb.build API
which is only called from task context in OE-Core.
(Bitbake rev: c79ecec580e4c2a141ae483ec0f6448f70593dcf)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
One of the challenges in maintaining the code is that it sometimes uses
a datacaches structure and sometimes a datastore. Rather than continue
the current dual API madness, have the worker contexts create a dummy
datacaches structure with the entries we need. Whilst this does need to
be kept in sync with the real structure, that doesn't change and this
allows the code to be simplified.
With this new approach, we can unify the stamps dependency code again.
(Bitbake rev: c6d325fc9b53e9d588ab273ee3c2a99a70fba42c)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
feature for signature dumping
Now that we have cache support for the taskdep/gendep/lookupcache data,
we can switch to use that cooker feature and skip the secondary reparse to
write the sig files. This does make the initial parse longer but means the
secondary one isn't needed.
At present parsing with the larger cache isn't optimal but we have plans
in place which will make this faster than the current reparse code being
removed here.
(Bitbake rev: 5951b5b56449855bc2a30146af65eb287a35fcef)
(Bitbake rev: 1252e5bce51ae912ecff9dcc354a371786ff2c72)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
| |
It is becomming clear the siggen needs access to our cache data but we
can't always obtain it in the contexts we need to. Add it directly,
meaning over time we should be able to simplify the APIs and stop
convoluting new ones!
(Bitbake rev: 6b213590ed0e77683cf7fbce6bbe9605ddecf3d3)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We're struggling to understand how bitbake.sock can sometimes disappear
in live builds when we can't see where it could have been deleted.
This causes connection failures to the server and failed builds.
Add some extra debugging around the server log and client retry
log messages to give more information for the next time this issue
occurs.
(Bitbake rev: 376a516dc8c96727fd042ada65f803013601ee2d)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
| |
Most of our older distros with python older than 3.8 already need buildtools
tarballs apart from Ubuntu 18.04. 3.8 allows us to fix a few things, tidy
code in places and is widely available or can be obtained with buildtools.
Therefore update our minimum version to 3.8.
(Bitbake rev: 744310f360d2288ac2ef07745abc86852126b5b9)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
| |
do_setscene was from a different era before our modern setscene
per task code. It hasn't been used for years so remove some old
obsolete references to it.
(Bitbake rev: ef72282298f7c4db74383c23bb0251dd06d3c6d3)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
| |
All siggens in common use should now support multiconfig, drop the
compatibility code.
(Bitbake rev: b36545b4df6d935ed312ff407d4e0474c3ed8d1a)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When obtaining latest upstream versions, the code needs
to check if the existing tarball is in a versioned directory
(e.g. component-name/x.y/component-name-x.y.z.tar.gz) and
if it is, it needs to first obtain the list of all
such versioned directories and then check all of them by going
one step up in the directory hierarchy.
Existing code was returning a correct match when the component
name did not have numbers, e.g. a check on 'source/epiphany/43/'
would return 43, but was stopping too soon when the component
name itself had numbers ('source/libxml2/2.10/' would return libxml2).
This change ensures the last match is taken instead of the first.
Also, adjust the fetcher tests to check that versioned directories
are correctly traversed in this case (e.g. the step to go one level
up is taken and a new tarball is discovered in a different versioned
directory).
(Bitbake rev: b6601be22c6d776327acdcd1fa931400f41ac786)
Signed-off-by: Alexander Kanavin <alex@linutronix.de>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
| |
In the HTML page footer.
(Bitbake rev: 897f238e5e34d3f8f23e3b7ac8a19ef8bb0aca22)
Signed-off-by: Michael Opdenacker <michael.opdenacker@bootlin.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
metadata
The bitbake git fetcher currently fetches 'refs/*:refs/*', i.e. every
single object in the remote repository. This works poorly with gitlab
and github, which use the remote git repository to track its metadata
like merge requests, CI pipelines and such.
Specifically, gitlab generates refs/merge-requests/*, refs/pipelines/*
and refs/keep-around/* and they all contain massive amount of data that
are useless for the bitbake build purposes. The amount of useless data
can in fact be so massive (e.g. with FDO mesa.git repository) that some
proxies may outright terminate the 'git fetch' connection, and make it
appear as if bitbake got stuck on 'git fetch' with no output.
To avoid fetching all these useless metadata, tweak the git fetcher such
that it only fetches refs/heads/* and refs/tags/* . Avoid using negative
refspecs as those are only available in new git versions.
Per feedback on the ML, Gerrit may push commits outsides of branches or
tags during CI runs, which currently works with the 'nobranch=1' fetcher
parameter. To retain this functionality, keep fetching everything in case
the 'nobranch=1' is present. This still avoids fetching massive amount of
data in the common case, since 'nobranch=1' is rare. Update 'nobranch'
documentation.
Reviewed-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com>
(Bitbake rev: d32e5b0ec2ab85ffad7e56ac5b3160860b732556)
Signed-off-by: Marek Vasut <marex@denx.de>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In checkstatus() opener.open() is used to check if an artifact is available.
The check fails if the uri contains username password in the format:
"username:password@hostname..". Moreover, the checkstatus function already uses
the username from the "ud" object to craft a header, is username and password is
provided.
This fix ensure the uri in the Requests object used does not contain username as
password.
(Bitbake rev: 88350002d45e0aa85ecd5356da2c8d71e450641e)
Signed-off-by: Kasper Revsbech <kasper.revsbech.ext@siemensgamesa.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
|
| |
We keep seeing server issues where the lockfile is present but we can't
connect to it. Reuse the lockfile debugging code from the server to
dump better information to the console from the client side when we
run into this issue. Whilst not pretty, this might give us a chance
of being able to debug the problems further.
(Bitbake rev: 22685460b5ecb1aeb4ff3436088ecdacb43044d7)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
| |
We have timestamps in the server logs but we don't know which
UI messages correlate to them. Add some timestamps to the messages
which doesn't make them pretty but which might make it possible to
debug problems.
(Bitbake rev: a1a86f8c311cb1fc4f5562f1c77f82aa95141eee)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Some layers think they're going to be 'clever' and copy the values from
another layer, e.g. using ${LAYERSERIES_COMPAT_core}. The whole point of
this mechanism is to make it clear which releases a layer supports and
show when a layer master branch is bitrotting and is unmaintained.
Therefore add some code to avoid people doing this. I wish we didn't have
to but...
(Bitbake rev: 6709aedccbb2e7ddbb1b2e7e4893481a7b536436)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
BB_GLOBAL_PYMODULES
For many years OE-Core has injected it's own python modules into the
python namespace using an immediate expansion of a variable in base.bbclass.
It also added all entries from BBPATH to sys.path.
We really need this to become a first class citizen of the langauge, this new
addpylib directive allows that. Usage is of the form:
addpylib <directory> <namespace>
The namespace is imported and if there is an attribute BBIMPORT, that
list of names is iterated and imported too.
This mirrors what OE-Core has done for a long time with one difference in
implmentation, sys.path is only appended to. This means later imported
namespaces can't overwrite an earlier one and can't overwrite the main
python module space. In practice we've never done that and it isn't
something we should encourage or support.
The new directive is only applied for .conf files and not other filetypes
as it only makes sense in that context. It is also only allowed in the
"base configuration" context of cookerdata since adding it at the recipe
level wouldn't work properly due to the way it changes the global namespace.
At the same time, move the list of modules to place in the global namespace
into a BB_GLOBAL_PYMODULES variable. It is intended that only the core layer
should touch this and it is meant to be a very small list, usually os and sys.
BB_GLOBAL_PYMODULES is expected to be set before the first addpylib directive.
Layers adding a lib directory will now need to use this directive as BBPATH
is not going to be added automatically by OE-Core in future. The directives are
immediate operations so it does make modules available sooner than the current
OE-Core approach.
The new code appends to sys.path rather than prepends as core did, as
overwriting python standard library modules would be a bad idea and naturally
encouraging people to collaborate around our own core modules is desireable.
(Bitbake rev: afb8478d3853f6edf3669b93588314627d617d6b)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
| |
(Bitbake rev: 5d27c555f7e1cc2064a39a1ce862e09a399185f7)
Signed-off-by: Michael Opdenacker <michael.opdenacker@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Get rid of the duplicate code and add extra check that the
locale en_US.UTF-8 is available on the system. This new helper
method is now located right above the method filter_environment()
which sets LC_ALL environment variable to 'en_US.UTF-8'.
[YOCTO #10165]
(Bitbake rev: a4ce040a6fd540a1cac52f808f909f9fcf8c961c)
Signed-off-by: Frank de Brabander <debrabander@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
| |
Starts the sync thread slightly earlier to give it some extra time to
dump out the caches while the main process tears down the parsing
processes
(Bitbake rev: 105f2897b0618713b036fc0f7a6e0f3e78d1707a)
Signed-off-by: Joshua Watt <JPEWhacker@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
| |
Uses an event to terminate the parser threads instead of a queue. This
is not only simpler, but saves about 500ms on shutdown time
(Bitbake rev: 2aed34e1d4bf24bba6263f168ff31b55b5fbe982)
Signed-off-by: Joshua Watt <JPEWhacker@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
bitbake cache
Being able to track siggen hash construction data can be useful for cache
debugging. For now, add an extra cache class which contains this information.
It can be enabled in the same way as the hob data cache through a feature flag
to cooker. This allows us to experiment with the data without carrying larger
patches around and ultimately may allow use to have a hash mismatch debugging
mode that is more easily enabled.
(Bitbake rev: 0736a8a03da8b774fafbd28f746bef4705378049)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The basehash data is really internal bitbake data and passing an object
directly is more efficient than creating and then extracting variables.
This will match the format of other data we may optionally wish to
store in the cache so more to the more efficient method. Nothing I
can see is using this data today (and nothing should be).
(Bitbake rev: e621093a1bf37cd75ede3fb77ab6845556870fc7)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
| |
Make a small change in the layout of the code in build_dependencies
which makes subsequent patches easier to read. No functionality change,
just moving the function definitions to the start of the function block.
(Bitbake rev: fff13b1e5e8397130b4378e0ba2301336ec651a2)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|