| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
dependencies rehash
An example:
NOTE: recipe binutils-cross-testsuite-2.32.0-r0: task do_check: Started
ERROR: Taskhash mismatch b074da4334aff8aa06572e7a8725c941fa6b08de4ce714a65a90c0c0b680abea versus 17375278daed609a7129769b74a1336a37bdef14b534ae85189ccc033a9f2db4 for /home/pokybuild/yocto-worker/qemux86-64/build/meta/recipes-devtools/binutils/binutils-cross-testsuite_2.32.bb:do_check
NOTE: recipe binutils-cross-testsuite-2.32.0-r0: task do_check: Succeeded
Is caused by a rehash in a dependency happening somewhere earlier in the build
and the taint being reset.
Change the code so that nostamp taints are preserved to avoid the issue.
(Bitbake rev: c42d00ff293d0538cad1b84c108bf7f5f49d4d84)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit 61624a3fc38e8546e01356d5ce7a09f21e7094ab)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We've seen cases where a task can execute with a given pid, complete
and a new task can start using the same pid before the UI handler has
had time to adapt.
Traceback (most recent call last):
File "/home/pokybuild/yocto-worker/qemux86-alt/build/bitbake/lib/bb/ui/knotty.py", line 484, in main
helper.eventHandler(event)
File "/home/pokybuild/yocto-worker/qemux86-alt/build/bitbake/lib/bb/ui/uihelper.py", line 30, in eventHandler
del self.running_tasks[event.pid]
KeyError: 13490
This means using pids to match up events on the UI side is a bad
idea. Change the code to use task ids instead. There is a small
amount of fuzzy matching for the progress information since there
is no task information there and we don't want the overhead of a task
ID in every event, however since pid reuse is unlikely, we can live
with a progress bar not quite working properly in a corner case like
this.
[YOCTO #13667]
(Bitbake rev: a109d034cf4fc059fd5a1e1d03246dac65522dd6)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit e427eafa1bb04008d12100ccc5c862122bba53e0)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
| |
(Bitbake rev: 6f0b82627edc82601f80f0f096bf96db43afefa8)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit 3aad9978be2a40d4c535a5ae092f374ba2a5f627)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Based on the hashserv's new ability to accept hash mappings, update runqueue
to use this through a helper function in siggen.
This addresses problems with meta-extsdk-toolchain and its dependency on
gdb-cross which caused errors when building eSDK. See the previous commit
for more details.
(Bitbake rev: 222df6d6b832868c6e87334f8acdd74b730a91d6)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit 39098b4ba2133f4d9229a0aa4fcf4c3e1291286a)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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: 0d154434ed8e3e88ad440a8dd21a164e72ba4ac5)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit 674692fd46a7691a1de59ace6af0556cc5dd6a71)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When follow the instructions of multiconfig from Yocto dev manual that
set in core-image-sato recipe:
do_image[mcdepends] = "multiconfig:x86:arm:core-image-minimal:do_rootfs"
it show too many annoying warnings look like:
| WARNING: Deferring mc:x86:virtual:native:/buildarea6/kkang/poky/meta/recipes-support/libxslt/libxslt_1.1.33.bb:do_populate_sysroot
| after mc:arm: virtual:native:/buildarea6/kkang/poky/meta/recipes-support/libxslt/libxslt_1.1.33.bb:do_populate_sysroot
Treat them as infomations rather than warnings.
(Bitbake rev: cfa307aabf710d79c404a8571b4158b864a94727)
Signed-off-by: Kai Kang <kai.kang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
| |
(Bitbake rev: 8569ccb5e9fbdeaaf96b78bd02a263b26de54059)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
accounted for in migrations
Setscene hard dependencies were not being correctly handled during task migration.
For example, do_package of recipe X might become valid due to hashequiv yet we're
still rebuilding pseudo-native, a harddep of do_package. This would mean
it would try to execute that setscene task despite pseudo not being present.
Fix this by ignoring tasks with failed harddependencies. This does mean
stlightly more rebuilds than is optimal but it avoids build crashes. Ultimately
the new runqueue model can likely better handle these cases than the older codebase
could but that is for another more invasive patch.
(Bitbake rev: 9a1072060350dc2e0eee14a5cc5af20c900f8a6d)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Bibake is currently too 'chatty' when hash equivalence is enabled. Fix
this by only printing the log output if a rehash happens and it matches
an sstate object.
Also, pass a summary option to the hash checking function. This was
already changed to a mechanism which allows addition of new parameters
so this should be backwards and forwards compatible.
(Bitbake rev: c5c5d786ca968d0e48002fe8acbcc8a63a954b67)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
| |
If a hash is reported to the hash server, the stamp written out by the
current task didn't account for any new hash the server may have provided.
Fix this so the correct stamp is written. This means "bitbake X; bitbake X"
no longer rebuilds lots of things when hashequiv is active.
(Bitbake rev: 4299afdd290f9d1c5616598f5fe83c195a64b63c)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
| |
The server is now restarting when running commands which doesn't make
sense. Only restart if its configuration has changed. This should
potentially fix various memory resident bitbake usages too.
(Bitbake rev: 7c847b01c30fc42cc78244f00fdf5eaa7b5df716)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The key problem is that currently running setscene tasks are not
accounted for when processing task migrations. This means can allow
two of the same task to execute at the same time with unpredictable
effects.
This change allows us to stop doing that and refactor the code slightly
to make it clearer that these conditions don't arrive even with
deferred tasks.
(Bitbake rev: 33ffc2128b1a74fa7179a8341db68cddf402536f)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
bitbake/lib/bb/fetch2/clearcase.py:148: SyntaxWarning: "is" with a literal. Did you mean "=="?
if command is 'mkview':
bitbake/lib/bb/fetch2/clearcase.py:155: SyntaxWarning: "is" with a literal. Did you mean "=="?
elif command is 'rmview':
bitbake/lib/bb/fetch2/clearcase.py:159: SyntaxWarning: "is" with a literal. Did you mean "=="?
elif command is 'setcs':
Python 3.8 is quite correct and we so mean "==" here, fix it to
avoid the warnings.
(Bitbake rev: 2cccc14304855cb55f339e465f6ba6ed0c69a7ab)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
|
| |
md5_file() uses a mmap() window to improve performance when hashing files, so
refactor the code and do the same for SHA1 and SHA256.
(Bitbake rev: 94ede642dce8cdbf09f566e3f7e9e260d33fda27)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
| |
Add a basic test for bb.utils.md5_file() etc.
(Bitbake rev: d535e78b14136e74d6e96ff24d3464d62637459d)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
|
| |
This should have been removed together with expanded_data in commit
e3694e73 (cooker/command: Drop expanded_data).
(Bitbake rev: 987996f01d55bc6433aeb7f43c209eb12f6d796b)
Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
With PRSERV_HOST = "localhost:0", this message would occasionally pop up
during the initial cache read:
WARNING: /home/matic/ambayocto/poky/bitbake/lib/bb/cache.py:446: ResourceWarning: unclosed <socket.socket fd=10, family=AddressFamily.AF_INET, type=SocketKind.SOCK_STREAM, proto=0, laddr=('127.0.0.1', 45655)>
value = pickled.load()
The file location stated is irrelevant; it just happens to be wherever
CPython decides to run the garbage collector. The issue is that after we
fork off a PRServer, self.socket is also duplicated. The parent side of
it also needs to be closed.
(Bitbake rev: cd970c9efa805ec3e7ba952df1701b347441ec7b)
Signed-off-by: Gavin Li <gavin@matician.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fix mercurial fetching after breakage from changes to the core fetcher.
Fix username and password usage and setting moddir needed by setup_revisions.
(Bitbake rev: c61c8356cce4d7307f74147dcf2b2cf103db84a8)
Signed-off-by: Volker Vogelhuber <v.vogelhuber@digitalendoscopy.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
| |
[YOCTO #13586]
(Bitbake rev: 566a6fe8c217c02f1ba5afc621ae9c3523f35d03)
Signed-off-by: Christopher Larson <chris_larson@mentor.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When bitbake determines if a git clone needs updating, it only checks for the
needed srcrevs, not the revs listed in BB_GIT_SHALLOW_REVS, which will fail if
using shallow and the needed rev was added to the upstream git repo after a
previous fetch. Ensure that we also check for shallow revs.
[YOCTO #13586]
(Bitbake rev: 24e3c7189e7d41bcbb46078a41c3a9daf391202a)
Signed-off-by: Christopher Larson <chris_larson@mentor.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There was a weird error in OE-Core where "devtool modify virtual/kernel"
was showing basehash mismatch errors. This was due to SRCPV sometimes being:
AUTOINC+b867b78b50_47b80ef7bd and sometimes AUTOINC+b867b78b50_255a750d28.
The latter hash comes from KBRANCH and meant sometimes the correct branch
was seen, sometimes it was not. The issue was complicated by the execution
using a remote datastore over tinfoil.
The problem turns out to be a fetcher caching error. If the datastore
changes, the cached url data may not be valid.
We therefore ensure we match cached url data against the datastore that
generated it, which appears to fix this issue.
(Bitbake rev: 1a79651c518abc35b99005c137ab7e82a99c75b0)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
SIGTERM handler
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: 4d7017a48c17e9b64d5824c77abe94cc3ab0f579)
Signed-off-by: Ivan Efimov <i.efimov@inango-systems.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
| |
(Bitbake rev: 5d83d828cacb58ccb7c464e799c85fd2d2a50ccc)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
BBMULTICONFIG
The syntax to use multiconfig builds changed from multiconfig:foo:target
to mc:foo:target, change the syntax on bitbakes documentation.
Clarify that BBMULTICONFIG defines additional configurations along with
the one coming from local.conf.
(Bitbake rev: 648ec12d776d801a6839f759975c91a93aa3a36e)
Signed-off-by: Alejandro Enedino Hernandez Samaniego <aehs29@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
|
| |
Toaster directly supports the last two stable branches of Yocto
Project. With "Zeus" being released, it is time to replace "Thud".
[YOCTO #13579]
(Bitbake rev: 29374386fd7fcfac9d4070584dff76327845595e)
Signed-off-by: David Reyna <David.Reyna@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
| |
This allows metadata to depend on SignatureGeneratorUniHashMixIn which was recently added.
(Bitbake rev: f0f814407fdd2fffa7071c36c011b489bfcd53da)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Some of the objects that bitbake reports to Toaster as dependencies to packages
are known objects that are not packages, for example library files and kernel
modules. In the Toaster logs, mark these as "Info" instead of "Warning".
[YOCTO #13386]
(Bitbake rev: 0d66f644d647900e8f5afa526a6d9cee687c41cc)
Signed-off-by: David Reyna <David.Reyna@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There were three issues in this one bug.
1) The Add Layer button allows empty layers
2) The internal XHR URL was wrong, which caused a hidden AJAX error
and did not correctly complete the action nor disable the button
after an add.
3) There was a race condition between typing in the dependent layer
select text box (which would normally disable the add button), and
the typeahead pull-down selection (which would normally enable the
add button). This forced the user to select the typedahead layer twice.
[YOCTO #13385]
(Bitbake rev: c4ccf3a792ae7e8549b879ba77ff7f7edb0e665a)
Signed-off-by: David Reyna <David.Reyna@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The hashserve can delete its socket whilst the cleanup us happening leading to
backtraces and test failures.
Add code to avoid this race condition.
[YOCTO #13542]
(Bitbake rev: efd7b025cee25d0ee668c09476395d08fcf5ae1a)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
| |
The full paths make the cache useless in the sdk. They also bloat the
cache size. They're for human debugging benefit only so compromise and
reduce this to the filename.
(Bitbake rev: 3b275c4083eae1d3781f0862919af9de83932b0f)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
| |
A minor performance optmisation to keep lists smaller when running large
builds. We can do this since once a task has been built, we don't need
to worry about it. This improves a major bottleneck that shows up on
performance profile charts in dryruns.
(Bitbake rev: cd6b89230823707c3c9bb9e6883bf5a971916581)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
| |
There are some runqueue code paths where the unihash cache would not be
saved where for example only parsing or an occurred. Save the cache at the
end of runqueue generation to ensure entries are cached.
(Bitbake rev: 9eee0d36870c11dd303894a6151c33a83bd3a1bc)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
| |
Use the unihash in the output filename of sigdata files else the contents
of stamp directories is misleading. Write the unihash into the singature to
make it clear what happened.
(Bitbake rev: feb01ee54d3706fe93768f332054c7532f7209e4)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
|
| |
We need to set the setscene tasklist before we call into the
taskhash/unihash code else the behaviour is inconsistent.
Avoid reporting hashes for non setscene tasks since we'd never
query that.
(Bitbake rev: 419a7840b8627278db694029c25df00214d01d96)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently runqueue will rerun setscene tasks multiple times as hashes
change. This has caused numerous problems since a setscene task may
become "unavailable" for some future signature combination and the code
then can't easily "unskip" tasks its already passed into the execution
queue.
At least for now, only run setscene once and assume they're equivalent
at that point. In practise that has been much more stable in testing.
Tweak the test to match the change in behaviour.
(Bitbake rev: 4205a3ef23834f317642bba155d67cd772176fb6)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
| |
The setscenetasks list needs to be available in the worker contexts
else the signature behaviour there mismatches what the server does.
Add the data to get/set_taskdata to ensure this happens.
(Bitbake rev: 632980ef90fe126b7ba3d138f4d574ae05914779)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Tasks were not migrating consistently, particularly:
* if a task was rehashed which had already run
* if a task which was valid became invalid due to a rehash
We need to always run the migration code for rehashed tasks and then
reprocess them for hash validity. This means rearranging the code.
It also means several tests are no longer correct and can't be written
correctly to work on all possible workflows so those are removed.
(Bitbake rev: 8443989ee41e9b162972935513e437b5c66ea74d)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 <JPEWhacker@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
|
| |
The HashConnectionError class was moved to the client module and needs
to be updated.
[YOCTO #13537]
(Bitbake rev: 9fb862685e5e5a2aa534bc25cab1e4158d708b40)
Signed-off-by: Joshua Watt <JPEWhacker@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
| |
The os module is required to connect to a unix domain socket
(Bitbake rev: 31a5111bcd0080a583d0d95fad3e09ae78bdf0fa)
Signed-off-by: Joshua Watt <JPEWhacker@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The variable values that result from parsing multiconfig should be
included in the cooker data hash, otherwise changes to these files won't
be detected, which will allow the parsing cache to be loaded with the
old values for the multiconfigs. This can either manifest as the
variable values simply not updating, or getting basehash changed errors
when building.
This bug was previously undetected because all of the multiconfig base
files were a direct file dependency in all parsed recipes. This was
fixed in 34137a00f60 ("bitbake: bitbake: cooker: Rename __depends in all
multiconfigs"), exposing this bug.
[YOCTO #13541]
(Bitbake rev: c74481aa15226e1bff9d53e4ee4b702ebfa1ad32)
Signed-off-by: Joshua Watt <JPEWhacker@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
| |
(Bitbake rev: f31f35e8527c60a95931a4a8311a4cd237770b42)
Signed-off-by: Jacob Kroon <jacob.kroon@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
| |
Add a test case to exercise the detection of git-lfs repositories and the
behaviour of the lfs parameter.
(Bitbake rev: a7cf4fc72cce357c425084dc2c5f35b5ed1a4b7b)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
| |
Refactor the git-lfs checking: this means both clearer code in the download()
function and allows unit testing to monkeypatch the functionality.
(Bitbake rev: 33cf9172ded50a869f7201ba463ab9ecc69b8252)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Autobuilder type infrastructure can benefit from deletion of certain files as
background IO due to the way Linux filesystem priority works.
We have problems where build directories as part of oe-selftest being
delete starves the running tasks of IO to the point builds take much
longer to compelte.
Having this option of running the deletion at "idle" helps a lot with
that.
(Bitbake rev: 797354d285f6d624d9adb52bab65823572da0e39)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
According to sstate_checkhashes which is defined in sstate.bbclass, the
currentcoun should be a number (0, not None).
Fixed:
$ bitbake base-files -Sprintdiff
> bb.plain("Sstate summary: Wanted %d Found %d Missed %d Current %d (%d%% match, %d%% complete)" % (total, len(found), len(missed), currentcount, match, complete))
TypeError: %d format: a number is required, not NoneType
(Bitbake rev: 45cb73e2846eaffe8964a573875f54808e8f3633)
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add a new 'lfs' option to the git fetcher so that we can optionally not fetch
git-lfs content, for repositories that contain LFS data that we don't
actually need for building.
By default lfs is set to 1, so if the repository has LFS content then git-lfs is
required. Setting lfs to 0 will mean that git-lfs won't be required to fetch,
and some files will be missing.
(Bitbake rev: be0b78ccfc5ede98041bc0545a15092494b12b26)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently, show-recipes will append "(skipped)" marker to recipes which
were skipped due these recipes does not satisfied the configurations.
Example: $ bitbake-layers show-recipes -r
ace
backport-iwlwifi
core-image-rt (skipped)
core-image-rt-sdk (skipped)
core-image-tiny
Add -b/--bare to enable output names without "(skipped)" marker.
Example: $ bitbake-layers show-recipes -r -b
ace
backport-iwlwifi
core-image-rt
core-image-rt-sdk
core-image-tiny
(Bitbake rev: 87796e580cd160a535eb5fb9e31846a7cf1a249e)
Signed-off-by: Yeoh Ee Peng <ee.peng.yeoh@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently, show-recipes will show recipes from all configured layers.
Assume, meta-intel layer was added to conf/bblayers.conf.
Example of default $ bitbake-layers show-recipes:
core-image-rt:
meta-intel unknown (skipped)
meta unknown (skipped)
Add -l/--layer to enable showing recipes from user selected layer.
Example: $ bitbake-layers show-recipes -l meta-intel
core-image-rt:
meta-intel unknown (skipped)
(Bitbake rev: 8c38d95c4474ea171cb55b0e336d9090451e89ce)
Signed-off-by: Yeoh Ee Peng <ee.peng.yeoh@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently, show-recipes will show all recipes available (both
recipes with different version and recipes provided by more
than one layer).
Example of default $ bitbake-layers show-recipes:
core-image-rt:
meta-intel unknown (skipped)
meta unknown (skipped)
yajl:
meta-oe 2.1.0
meta-oe 1.0.12
Add -r/--recipes-only to enable showing recipes only. This
provide a focus view on unique recipes available.
Example of $ bitbake-layers show-recipes -r:
core-image-rt (skipped)
yajl
(Bitbake rev: 048bd051a9b422a38c181f57bb5090a05684a5c3)
Signed-off-by: Yeoh Ee Peng <ee.peng.yeoh@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|