| Age | Commit message (Collapse) | Author | Files |
|---|
|
Commit e9672387 split one long line into a multi-line string, but in
the process white space between words was lost. This results in badly
formatted output when this message is printed.
Signed-off-by: Peter Urbanec <openembedded-devel@urbanec.net>
|
|
For some recipes that inhrient cmake, the ${B} may be removed by
cmake_do_configure() while sstate_hardcode_path() running, this
causes build errors:
Exception: OSError: [Errno 2] No such file or directory: \
'/path/to/build'
The function sstate_hardcode_path() called command:
$SSTATE_SCAN_CMD which extended as "find ${SSTATE_BUILDDIR} ..."
So the proper function dirs could be ${SSTATE_BUILDDIR}.
Signed-off-by: Wenzong Fan <wenzong.fan@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
|
|
The too long line would cause "git send-email" report errors:
patch contains a line longer than 998 characters
Though we can use "--no-validate" to force the send.
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
|
|
The code:
bb.fatal("foo1")
bb.fatal("foo2")
Would make the second one not work, use bb.error for first one to fix
the problem.
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
|
|
The packagegroup allarch rpm files for multilib can overwrite each other since
they are in theory indentical (in contrast to the other backends). We therefore
need to whitelist this to avoid build failures now this overwrite failure
is fatal.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Update the sstate file's timestamps after it is installed, it will be
very useful for removing the old sstate file, especially, it's not easy
to remove when use the shared SSTATE_DIR, we can easily remove them with
this change, for example:
$ find state-cache -type f -ctime +10 -exec rm -f {} \;
Will remove the sstate file which isn't used by recent 10 days.
We can use the -atime, but it is not always available, for example,
when mounted with "-o noatime".
The touch is a very light weight action, and the
scripts/sstate-cache-management.sh also requires this.
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
|
|
When files overlap in the sysroot, something bad usually happened. We've had
two independent cases recently where a couple of months after one of these
warnings was shown, builds failed due to corruption.
This change moves the warning to become a fatal error. The complaint I've had
about this is that we need to tell the user what happened and more importantly
how to recover from it. If we could recover from it, great but the trouble is
we simply don't know what happened.
As a compromise, we can document several of the possible scenarios in the error
message. We don't normally go to this level of detail however in this case, I'm
lacking other viable alternatives.
I do believe it is important to stop as corruption occurs rather than letting the
build contunue into territory that is not deterministic amongst other things.
The complex message is followed by a simpler one in case the long message is too
much for the user.
(From OE-Core rev: 179ac7de03977b6e440409eddb2166819e07286a)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Signed-off-by: Hongxu Jia <hongxu.jia@windriver.com>
|
|
I've been giving things some thought, specifically why sstate doesn't
get used more and why we have people requesting external toolchains. I'm
guessing the issue is that people don't like how often sstate can change
and the lack of an easy way to lock it down.
Locking it down is actually quite easy so patch implements some basics
of how you can do this (for example to a specific toolchain). With an
addition like this to local.conf (or wherever):
SIGGEN_LOCKEDSIGS = "\
gcc-cross:do_populate_sysroot:a8d91b35b98e1494957a2ddaf4598956 \
eglibc:do_populate_sysroot:13e8c68553dc61f9d67564f13b9b2d67 \
eglibc:do_packagedata:bfca0db1782c719d373f8636282596ee \
gcc-cross:do_packagedata:4b601ff4f67601395ee49c46701122f6 \
"
the code at the end of the email will force the hashes to those values
for the recipes mentioned. The system would then find and use those
specific objects from the sstate cache instead of trying to build
anything.
Obviously this is a little simplistic, you might need to put an override
against this to only apply those revisions for a specific architecture
for example. You'd also probably want to put code in the sstate hash
validation code to ensure it really did install these from sstate since
if it didn't you'd want to abort the build.
This patch also implements support to add to bitbake -S which dumps the
locked sstate checksums for each task into a ready prepared include file
locked-sigs.inc (currently placed into cwd). There is a function,
bb.parse.siggen.dump_lockedsigs() which can be called to trigger the
same functionality from task space.
A warning is added to sstate.bbclass through a call back into the siggen
class to warn if objects are not used from the locked cache. The
SIGGEN_ENFORCE_LOCKEDSIGS variable controls whether this is just a warning
or a fatal error.
A script is provided to generate sstate directory from a locked-sigs file.
(From OE-Core rev: 7e14784f2493a19c6bfe3ec3f05a5cf9797a2f22)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
The "grep -e (x|y)" doesn't work, for example:
$ echo xy | grep -e '(x|y)'
No output
We can use "grep -E" (extended regexp) or "grep -e x -e y" to fix it.
It only affected the cross recipes.
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
|
|
The use of [ and && here means $? is reset and the exit 1 error
interception wasn't working, leading to "file changed as we read it"
errors from sstate_create_package when heavily using hardlinks.
Fix this by placing $? into a variable.
(From OE-Core rev: 6e51f900b76b06c09a3d6927f8db7398e2c035ed)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
In some cases we do either need to add extra sstate manipulation
functions, or change the existing modification functions. This patch
parametrizes it to SSTATEPOSTCREATEFUNCS after sstate_create_package
Signed-off-by: Hongxu Jia <hongxu.jia@windriver.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
In some cases we do either need to add extra sstate manipulation
functions, or change the existing modification functions. This patch
parametrises them to SSTATECREATEFUNCS and SSTATEPOSTUNPACKFUNCS and
abstracts the "hardcoded path" functions into separate functions using
these new variables.
We may use this new functionality to improve binary relocating using
patchelf for example, this at least lets us have the hooks to be able to
experiment.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
do_package_setscene
If we have done do_package_qa_setscene we do not also need
do_package_setscene. This means we can again for example rebuild an image
without needing do_package sstate packages to be present.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
same tmpdir
Currently if you try and switch between linux/darwin/mingw SDK builds in the
same TMPDIR, things break. This is due to sstate not reflecting the SDK_OS in
the manifest names.
Since they are different, reflect this in the manifest naming and allow
this to work.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
When the preconfigure task was added to gcc, it wasn't added to sstate's list
of possible shared work tasks. This meant that diffsigs wasn't able to find
the preconfigure sigdata/info file since it has inconsistent naming.
This adds the task name to the list. Ideally this list would be autogenerated
or not even required, right now its a sanity test that the shared work
code works as intended so is best left as is.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
With the renaming of the cross packages, its no longer possible to use
endswith("-cross") and similar to detect cross packages. Replace these
references with other techniques.
This resolves certain build from sstate failures which were due to the
system believing cross packages were target packages and therefore
dependency handling was altered.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
|
|
This allows them to co-exist together in the native sysroot, with one
set of cross tools per target architecture.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
We recently added multiple provider warnings. These could get issued
from -cross recipes due to the way these currently overlap in the
native sysroot. Filter out these warnings for now, until such times
as we improve the cross recipes so they don't have an overlapping
namespace.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
A while ago we stopped supporting sstate names which were different from the
taskname. This patch finishes cleaning up some code remnants from that
which were causing data duplication and confusion.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Looking at the code, its clear 'task' is meant not to have the do_ prefix,
however its also clear it can be left in through some code paths.
One result of this can be files not being cleaned from the sysroot correctly.
Fix this.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
This is a patch to update the missed sstate event with
info about the sstate files locations that were found.
It's needed as to display the found file in the toaster ui.
Also fixes a bug where a setscene task may have appeared in the
missed list even if it was found in a sstate mirror.
Signed-off-by: Alexandru DAMIAN <alexandru.damian@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Toaster needs to record the attempts to restore
setscene tasks that don't have a sstate file.
We build a list of tasks for which we can't find an
sstate file, and if we're running under Toaster data
collection, we send it off with a MetadataEvent.
Signed-off-by: Alexandru DAMIAN <alexandru.damian@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
This was stomping over the value added in buildhistory.bbclass, leading
to task signatures *still* changing when buildhistory was added to
INHERIT.
Fixes [YOCTO #5897].
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Bitbake can't interpret the python execution of these functions so
include the dependency manually.
[YOCTO #4507]
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
I have a feeling this code exists from the time before we had proper
coverage of one sstate task by another task. At that time it was a
"poor" persons version of that idea, we now have much better
code internal to bitbake which handles this.
Worse, this code actually breaks certain rebuild scenarios,
e.g.:
bitbake libtool-cross
bitbake libtool-cross -c cleansstate
rm tmp -rf
bitbake libtool-cross
would fail as binutils-cross wasn't installed from sstate.
The easiest fix is to remove the obsolete/broken code.
[YOCTO #5773]
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
The code here that deletes stamps was also deleting the taint files; so
forcing an sstate task with -f would force it to execute and then
because the taint file was deleted in the process, the next execution
would simply restore the output from sstate again. We need to exclude
the taint files just like we did in bb.build.make_stamp().
Fixes [YOCTO #5805].
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
After the change to allow target recipes to depend on native recipes, the
native checksums becomes all the more critical. Add to this that we're now
accounting for pre/postfuncs and we have a cache reuse issue since the
distro LSB string is getting coded in when it shouldn't be.
This excludes that string and allows one set of native sstate to share
checksums with another set from a different host distro. They're separated
into different directories so this is fine for our use cases.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Now that bitbake is recursing into pre/postfuncs, we need to ensure
the dependencies of these functions is correct. We don't want dependencies
on MACHINE or other related variables. This patch adds in appropriate
variable exclusions to achieve this.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
There is a potential problem if we don't remove the previous version's
stamp, for example:
The depend chain is:
libtool-native -> autoconf-native -> m4-native
We have two m4-native: 1.4.9 and 1.4.7
1) Clean all of them to make a fresh build so that we can reproduce the
problem
$ bitbake m4-native autoconf-native libtool-native -ccleansstate
2) Build libtool-native so that the m4-native_1.4.17 will be built
$ bitbake libtool-native
3) Set PREFERRED_VERSION_m4-native = "1.4.9" and build again
$ bitbake libtool-native
4) Set PREFERRED_VERSION_m4-native = "1.4.17" and build again
$ bitbake libtool-native -ccleansstate && bitbake libtool-native
Then the build will fail:
[snip]
| m4: unrecognized option '--gnu'
| Try `m4 --help' for more information.
| autom4te: m4 failed with exit status: 1
[snip]
The is because when we change m4-native to 1.4.17 and build
libtool-native again:
5) libtool-native depends on autoconf-native, and autoconf-native's
version isn't change, so it can remove the current stamp and mirror
the sstate (the one depends on m4-native_1.4.9) from the SSTATE_DIR
correctly.
6) The mirrored autoconf-native depends on m4-native_1.4.17's
do_populate_sysroot, and the stamp is already there (which is made
by step 2), so it would do nothing, but this is incorrect, since
the one that really in the sysroot is m4-native_1.4.9, then the
error happens.
Remove previous version's stamp in sstate_clean() will fix the problem.
[YOCTO #5422]
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
do_package doesn't exist and are noexec anyway for native/cross/crosssdk
packages.
Signed-off-by: Ming Liu <ming.liu@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
This patch mainly aims to add optimisation for crosssdk setscene dependency
validating which we haven't handled in current logic, and which I think we
could have as we've already implemented to native/cross, although there
are albeit not many crossdk tasks, we could still get some performance
enhancement.
Signed-off-by: Ming Liu <ming.liu@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
The way the "all arch" PKGSPEC is enabled, it causes corruption
of the datastore of sstate operations against other tasks.
Data store copies are cheap and allow us to use that trick, resetting
to a clean copy of the data afterwards.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Like fetch, unpack and patch, populate_lic doesn't vary between different
archs so we should mark it as such. This means better sstate cache reuse
with fewer duplicate files as well as less confusing sstate debugging.
sstatesig also needs to account for the fact BPN is used for sstate files
in these cases.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Currently the code has problems differentiating between "gcc-cross" and "gcc-cross-initial"
sstate files. We could add in a ton of special casing but tests show this isn't scaling
well. Using a more unique separator resolves the issue.
The choice of which separator to use is a hard one. We need something which isn't commonly
used in PN, PV, PR, *_OS and *_ARCH which rules out '-', '_' and it needs to work ok with
webservers/http which makes ';' and '%' harder.
The change also sets SSTATE_SWSPEC globally since writing out differently named siginfo
files for the fetch/unpack/patch tasks is a waste of diskspace, the hashes match for
all PN in the majority of cases and if they don't, its not a big issue as the hash is
different. This makes the results from sstate debugging more understandable.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
When originally developed, it was thought a task may have more than one associated
sstate archive. The way the code has grown that idea is now not possible or needed.
We can therefore assume one sstate archive per task and drop the crazy name
mapping code. Simpler is better in this case.
The downside is that various sstate archives will change name so this forces a cache
rebuild. Given the other sstate changes going in at this time, this isn't really
a bad thing as things would rebuild anyway.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
For a shared workdir, any one of the fetch/unpack/patch tasks may run yet the
PN and architecture fields in SSTATE_PKGSPEC may differ. This makes looking up
the appropriate siginfo file near impossible.
I've tried several different ways of resolving this and this is the neatest
solution I could find, its still rather ugly. I believe the usefulness of
better sstate debugging outweighs the ugliness of the code.
This patch also changes the sstate_checkhashes() code to look for siginfo
files rather than the actual sstate packages themselves. This means the
function can be used in other contexts to find info files for tasks that
may not have sstate data. It is assumed that sstate mirrors will have both
files available. This is done to allow bitbake to query whether tasks have
matching signatures in sstate directories or not.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Currently siginfo files are only written for sstate tasks. In order to be truly
debuggable, its helpful to have the siginfo for intermediate tasks. This
adds that functionality so the extra siginfo files are written out too.
This will be used to add better sstate debugging in future changes.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
sstate_package creates hardlink from sysroot to SSTATE_BUILDDIR, and
sstate_create_package stores SSTATE_BUILDDIR into a archive file by
tar, these two task can be run simultaneously for different packages,
and make a hardlink for a file will lead to the change of the links
number of file, and if tar is reading this file, it will fail with exit
code 1, and report "file changed as we read it":
DEBUG: Executing shell function sstate_create_package
tar: x86_64-linux/usr/share/aclocal/xorg-macros.m4: file changed as we read it
4b3e353a5[sstate.bbclass: fix parallel building issue] tries to use the
tar parameter --ignore-failed-read to fix, but it does not work, and
tar parameter --warning=no-file-changed can close the warning, but can
not change the exit code. so close shell immediate exit, only fail
if tar returns not 1 and 0.
Exit codes of tar:
http://www.gnu.org/software/tar/manual/html_section/Synopsis.html
Signed-off-by: Roy Li <rongqing.li@windriver.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
sstate_package creates hardlink from sysroot to SSTATE_BUILDDIR, then
sstate_create_package will store SSTATE_BUILDDIR into a archive file by
tar, but once other packages install the same file into sysroot, the
creating the archive file will fail with below error:
DEBUG: Executing shell function sstate_create_package
tar: x86_64-linux/usr/share/aclocal/xorg-macros.m4: file changed as we read it
This kind of error is harmless, use --ignore-failed-read to ignore it.
The error in tar occurs when the timestamp of the file changes and this
can happen when the number of symlinks change. The file will be included
in the archive.
[YOCTO #5122]
Signed-off-by: Roy.Li <rongqing.li@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
These have been deprecated for a long time, convert the remaining
references to the correct modules and prepare for removal of the
compatibility support from bitbake.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
ant reported on irc that the sstate absolute to relative symlink creation
code wasn't working in klibc. He was correct although the level of breakage is
rather surprising since it only worked for one level of symlink (usr/include) with
everything else being broken.
The reason is probably that nothing really uses absolute paths, we use relative
paths where at all possible already. Nothing in the target sysroot should use
absolute paths for a start. In this regard, the klibc-dev package is broken and
needs fixing. It will currently break when building for one machine, then switching
to another of the same TUNE_PKGARCH and installing from sstate but that is a
separate issue.
This patch fixes the symlink creation code by firstly passing in the correct
value we need (where the symlink will end up) and seccondly, actually using it.
I've also tweaked the debug message to contain appropriate information and got
right of the double "//" value the existing code created in favour of the form
'./..' which looks neater.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
BB_NO_NETWORK disables any fetching, however if we're using an external
sstate cache, we may want to be able to fetch those objects even if we are
not fetching the upstream sources. Denote this situation by setting
SSTATE_MIRROR_ALLOW_NETWORK in local.conf. When it is found, for sstate
cache fetches, mask off BB_NO_NETWORK for the local function.
Signed-off-by: Joe MacDonald <joe.macdonald@windriver.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
|
|
This avoids unnecessary duplication of setup. The only visible change in
behavior will be the case if siginfo exists and the archive does not, in which
case it'll redownload both, but this doesn't seem unresasonable to me,
particularly since the archive is downloaded first, making this case
particularly unlikely.
Signed-off-by: Christopher Larson <chris_larson@mentor.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
The default FILESPATH isn't really of use, as we don't expect to find sstate
archives buried in layer recipe directories, and the default MIRRORS is
intended for use for fetching SRC_URI, not sstate.
Signed-off-by: Christopher Larson <chris_larson@mentor.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
dependencies
The do_package_setscene task needs to depend on fakeroot in order to correctly
install its files.
We can whitelist the dependency in the sstate handling code for some
performance improvements since we only need this if we're installing the
package from sstate.
Also use an append operator in base.bbclass for clarity.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
sstate has a logic to fixup hardcoded paths in scripts,
but it misses in some specific cases, so add
EXTRA_STAGING_FIXMES to the fixup hardcoded paths
mechanism, so that we can specify what hardcoded paths
need to be fixed in a recipe, e.g.
EXTRA_STAGING_FIXMES = "STAGING_BINDIR_TOOLCHAIN"
Signed-off-by: Jackie Huang <jackie.huang@windriver.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
In python 3 print is a function call. In some cases bb.note is a more
appropriate call to make.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Make hard links for staging files instead of copy to save the disk space
(3G will be saved for a core-image-sato build), and it doesn't affect
much on the build time.
The following directories are affected:
1) The sysroot
2) The DEPLOY_DIR
3) The pkgdata
[YOCTO #4372]
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
|
|
Otherwise we might end up creating directories under sstate-cache with whatever
random umask has been selected for the task that we're trying to package. This
would be a bad thing since it might result in losing group write access for
newly created dirs, and/or losing group read access for the sstate files
themselves.
Signed-off-by: Phil Blundell <philb@gnu.org>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
|
