If files would be overwritten by the deployment, preserve them in a
separate location on the target so that they can be restored if you
later run devtool undeploy-target.
At the same time, also check for sufficient space before starting the
operation so that we avoid potentially failing part way through.
Fixes [YOCTO #8978].
(From OE-Core rev: a2da55712691bcf1066c53d813107d75213d6b10)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If you want to put the target device back to exactly how it was before
devtool deploy-target started poking things into it, then it would make
things easier if you didn't have to figure out which recipes were
deployed. Now that we have the list stored on the target we can
determine this reliably, so add a -a/--all option to undeploy-target to
undeploy everything that has been deployed.
One of the side-effects of this is that the dry-run functionality for
undeploy-target had to be reimplemented to actually run the script on
the target, since we have no way of knowing what's been deployed from
the host side. We don't need to do the same for deploy-target though
since we know exactly which files will be deployed without referring to
the target.
(From OE-Core rev: 41fed83060f0041e14e455d1446397bda277d953)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When running devtool deploy-target, we save a list of deployed files,
and this list is used by devtool undeploy-target (or the next time
deploy-target is run if the list is present, in case any files have been
renamed or deleted since the first time). We were writing this file to
the host, but it makes more sense to write the list to the target
instead, so that if we for example swap in a different board, or switch
hosts, things will work as expected.
In order to do this properly we have to construct a shell script and
ship it over to the target so we can run it. The manifest is written out
to a hidden directory in the root (/.devtool).
Fixes [YOCTO #7908].
(From OE-Core rev: a16a0c9334b785e2df896266c8911a2c7a1806b8)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Get the default value for updateserver from the configuration file and
show it in the help; also only make the parameter optional if it's
specified. This means we can also drop the check in the function as
argparse will then ensure it's specified if there's no config setting.
(From OE-Core rev: 82497bde58fc8bdae8d8acfbf025a1a90b14cc3e)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Add a long description used when running --help on the specific command.
(From OE-Core rev: eb7787d1652fd84a149fd394969f4f1099406051)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Naming these as "optional arguments" is perhaps slightly confusing since
some of the positional arguments might also be optional; in addition
it's rare (though possible) for options to be mandatory - up until
recently we had a recipetool option (-o) that was mandatory. It's not
perfect, but change it to "options" so it's at least a bit more
appropriate.
(From OE-Core rev: 55e675de6191bf7eccd26df29189f2a6faa40a20)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The listing of subcommands in the --help output for devtool was starting
to get difficult to follow, with commands appearing in no particular
order (due to some being in separate modules and the order of those
modules being parsed). Logically grouping the subcommands as well as
being able to exercise some control over the order of the subcommands
and groups would help, if we do so without losing the dynamic nature of
the list (i.e. that it comes from the plugins). Argparse provides no
built-in way to handle this and really, really makes it a pain to add,
but with some subclassing and hacking it's now possible, and can be
extended by any plugin as desired.
To put a subcommand into a group, all you need to do is specify a group=
parameter in the call to subparsers.add_parser(). you can also specify
an order= parameter to make the subcommand sort higher or lower in the
list (higher order numbers appear first, so use negative numbers to
force items to the end if that's what you want). To add a new group, use
subparsers.add_subparser_group(), supplying the name, description and
optionally an order number for the group itself (again, higher numbers
appear first).
(From OE-Core rev: e1b9d31e6ea3c254ecfe940fe795af44761e0e69)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If we didn't make any changes to the file then there's no point warning
the user that we have done.
(From OE-Core rev: 391b9ba30d802ac420ddf382588e03e718861c01)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If files had been created next to the recipe (for example devtool add,
edit the source and commit and then devtool update-recipe), running
devtool reset failed to preserve those files and gave an error due
to trying to rmdir the directory containing them which wasn't empty.
Fix the preservation of files in the "attic" directory properly so
we catch anything under the directory for the recipe, and replicate
the same structure in the attic directory rather than slightly
flattening it as we were before.
(From OE-Core rev: bbe63eb97ae7f78959f117d6066ef821c4da1c77)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Looking at Chris Larson's code for starting the user's editor for
"recipetool newappend" it was slightly better than what I wrote for
"devtool edit-recipe" in that it checks VISUAL as well as EDITOR and
defaults to vi if neither are set, so break this out to its own function
and call it from both places. The broken out version passes shell=True
however in case it's a more complicated command rather than just a name
of an executable.
(From OE-Core rev: 184a256931e8cdc7bea97a905c4e67a435964de0)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
There is no -N/--name option for devtool, that's a recipetool option -
with devtool you just specify the name as a positional argument.
(From OE-Core rev: d2bc0cba5ca8a7220ffe1ef96acf856fe972ce7c)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If the user specifies --basepath on the commandline, only the directory
specified should be searched for .devtoolbase. Otherwise when --basepath
is a child of the sdk directory, .devtoolbase will always be found and
devtool will only show options meant to be used within an sdk.
(From OE-Core rev: 3bb07c61220b89384a76c745e33be37aad5095c0)
Signed-off-by: Randy Witt <randy.e.witt@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We have an issue with PAT handling on older processes with limited PAT bits,
see the patch description for the full problem. This replaces the runqemu
workaround with a kernel patch until we can get the kernel trees sorted
out and discuss a proper fix with upstream. It should be safe everywhere
so is applied unconditionally.
(From OE-Core rev: e00f0794a535c8e68ae1c87c8b01dd65645d570b)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Processing of this option was lost during recent change of
wks parsting. It was discovered during the work on booting
wic images under qemu. Now, when -use-uuid is fixed it's
possible to specify root partition by partition uuid.
This will be done in the following commit.
(From OE-Core rev: b4882e0b84d7fd4c85ee95386e94722485eafc2b)
(From OE-Core rev: 73e9e3f150bf2de9b27c2ccc73e3dee334ee73fe)
Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Wic images should be boot as is, without pointing qemu to the kernel
binary. Current code doesn't use kernel, but sets KERNEL variable and
shows kernel path in the console output. This can confuse users.
Changed runqemu and runqemu-internal code to avoid setting KERNEL
variable and show kernel path.
(From OE-Core rev: 474caa7ed5ff05caa5d49d270b283882fa616ed1)
(From OE-Core rev: 35e776e00cce25f2c9c45500612fb66022ec4739)
Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Quemu should be able to run wic images this way:
runqemu <machine> <image recipe> wic
Tested with 'runqemu qemux86-64 wic-image-minimal wic'
(From OE-Core rev: 8716be799949cb8bde7fa49cbea61312a3a93bb7)
(From OE-Core rev: dd42931bf99b8bbd4ad452b3941d957f41b81796)
Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Use "out of" rather than "from" in the output.
(From OE-Core rev: c712529030c71b45bb8ae647c17319c2647aedff)
Signed-off-by: Jan Sarenik <jajomojo@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Since the upgrade of qemux86 to 4.4.1 we're seeing PAT issues when
starting the X server. We need to fix the problem but the failing
sanity tests mask out other issues and we need a workaround.
Merge this for now until we can figure out the full issue. This is
better than changing the kernel defconfig or reverting to old
kernel versions.
(From OE-Core rev: 2749ba318bf322cb5014689532372473004e92b9)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If you specify a local directory which happens to be a git repository
with an origin remote (and it is in fact remote), we can use that for
SRC_URI as implemented by OE-Core revision
b143d414846854dc8b3e0a47358daf5646eded38, however we also need to set S
if the recipe is going to be of any use fetching from that SRC_URI
later.
(From OE-Core rev: 8bbbd2d63f1bc752f9a30054a089dc2caf5fd84c)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When recipetool create is given a URL that starts with http(s):// and
contains /git/, such as the URLs at git.yoctoproject.org, it's fairly safe
to assume it's a git repository and not something that should be fetched
with wget, so rewrite the URL.
(From OE-Core rev: 3ca04757a670e8b6f78799cc0454d75691809ac4)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When auto-detecting the name for a recipe from the URL, strip off any
parameters (";name=value...") before parsing the URL, otherwise this
just ends up in the recipe name which is undesirable.
(From OE-Core rev: d3c46b5d0abd56bcadd4f2f1ef985f13d67f605b)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Fix a regression introduced in in OE-Core revision
aedfc5a5db1c4b2b80a36147c9a13b31764d91dd where specifying a local source
tree without specifying a name resulted in a traceback.
Fixes [YOCTO #9086].
(From OE-Core rev: 67ea9d21f20a371a0ee443b46326018cb1527b62)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
It's going to be more common for users not to have the prepared source
tree for a recipe already, so the default behaviour ought to be to
extract it for them from the recipe. Change the default to extract
(effectively making the -x option a no-op) and add a --no-extract/-n
option to disable it. Later we can look at trying to be smart and
reusing an existing source tree instead of erroring out if it exists;
for now this is just the default reversal.
(From OE-Core rev: 80a44e52609a89d9ffe816181ae193af491c06ac)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Both BitBucket and GitHub provide "release" downloads that unfortunately
don't include the actual project name. For recipetool this means we have
to have special handling for these URLs or else the current code assumes
the name of the project is something like "v0.9.1". Borrow and adapt
some code from autospec to do this, and put it in its own function for
clarity.
(From OE-Core rev: e8435fde7f82c39cc0efe1d4bf043b29f63898e9)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
CMake supports a find_library() directive to find named libraries, so
detect dependencies from this.
(From OE-Core rev: d0265bc67f797ee4b7760cf37335994133809abf)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When extracting source for a recipe, if there are additional custom
tasks run that make changes to the source, create a commit in the
generated git branch so they are contained. This is particularly
useful for tasks that come before do_patch since otherwise the changes
might get incorporated in the first applied patch, but otherwise it
helps avoid the tree being dirty at any point.
Fixes [YOCTO #7626].
(From OE-Core rev: 997a77d9b20af1778b804778e5d8c8a7424f7582)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
python-xml depends on python-elementtree as the latter just contains a C library
used by the former. However there's no point to this split apart from
increasing the number of packages, so merge -elementtree into python-xml.
(From OE-Core rev: 5f7206eba3953b7f29148ecfb791995773ee5fc7)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Make path to newly generated README file legitimate
(From meta-yocto rev: 32286bb798c2778457b5578b4b590629c96a0ee2)
Signed-off-by: Maciej Borzecki <maciej.borzecki@open-rnd.pl>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Take `pwd` to be <initial-dir>. The %s path is relative to it. The value
of %s is "output_folder/build". The current code works as follows:
Changing directory to %s and finding the sources (after cd'ing) to cpio
with output redirection to %s/initrd.cpio triggers the following error
"Error: exec_cmd: cd output_folder/build/INITRD && find . | cpio -o -H
newc >output_folder/build/initrd.cpio returned '1' instead of 0"
This happens because after the cd, `pwd` is <initial-dir>/%s and by the
redirect we write the result to to <initial-dir>/%s/%s/initrd.cpio which
obviously does not exist.
Fix this by getting the sources with "find %s" instead of "cd && find ."
(From OE-Core rev: 07fa4783566d22d46ce719a621eee5404932dbbe)
Signed-off-by: Ioan-Adrian Ratiu <adrian.ratiu@ni.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
.iso image creation fails if during the image creation syslinux
is baked and syslinux-native is not.
Added new check to verify if both syslinux and syslinux-native
are baked and bake them if these are not installed.
(From OE-Core rev: fd5749832960ad3b85697c2878490d6f008982a3)
Signed-off-by: Mihaly Varga <mihaly.varga@ni.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
A kickstart file for non-x86 boards may have no 'bootloader' stanza. It
is the usual case if bootloader is setup using other mechanism than
through wic, and is for instance a part of u-boot configuration. In such
case the 'bootloader' field in the KickStart class will be
uninitialized. Instead of adding an empty bootloader line in every
kickstart file call the bootloader parser with empty argument list to
get defaults namespace.
(From OE-Core rev: 264c03e854f77c3b62acb710384f66716ccbf469)
Signed-off-by: Maciej Borzecki <maciej.borzecki@open-rnd.pl>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When used with --verbose, the heading for each task looks like
=== The verbose changes of example.do_do_compile:
This should instead be
=== The verbose changes of example.do_compile:
(From OE-Core rev: 628ad5e06d1136809d110a71148721095cb084dc)
Signed-off-by: Olof Johansson <olof.johansson@axis.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When copying the sstate-cache into the extensible SDK, if the source
path had a trailing / and the destination path did not, there would be a
missing / between the path and the subdirectory name, and you'd end up
with subdirectories like "sstate-cacheCentOS-6.7". There are functions
in os.path for this sort of thing so let's just use them and avoid the
problem.
(From OE-Core rev: 5eb8f15c48b5f39a10eb2b63b026cf1ebfd05533)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The uninative sysroot is in ${STAGING_DIR}-uninative so delete that alongwith
$STAGING_DIR.
(From OE-Core rev: 258668c3cb8f5c00e084e821dae05ba750768bfb)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When you need to set EXTRA_OECONF for a recipe, you need to know what
options the configure script actually supports; the configure script
however is only accessible from within a devshell and (at least in the
case of autotooled software fetched from an SCM repository) may not
actually exist until do_configure has run. Thus, provide a "devtool
configure-help" subcommand that runs the configure script for a recipe
with --help and shows you the output through a pager (e.g. less),
prefaced by a header describing the current options being specified.
There is basic support for autotools, cmake and bare configure scripts.
The cmake support is a little hacky since cmake doesn't really have a
concise help option that lists user-defined knobs (without actually
running through the configure process), however that being a design
feature of cmake there's not much I can think of to do about that at
the moment.
(From OE-Core rev: 0e5d84d9705091b338000ef02720cfa090f76888)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When we run the tasks required to extract the source for a recipe (e.g.
within "devtool modify" or "devtool extract") if one of those tasks
fails you get a bb.build.FuncFailed exception; handle this properly so
you don't see a traceback.
(From OE-Core rev: 95d8631b3bdf216001e57f48277535c65a4cc49e)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If a recipe generated by "devtool add" has been modified since then when
you run "devtool reset", it will be moved into the "attic" subdirectory
of the workspace in case those modifications need to be preserved. It
seems natural that if those modifications were worth preserving we
should warn the user if such a file exists when they run "devtool add"
to create the same recipe again, so they can pick up where they left off
if they want to.
(From OE-Core rev: 0a39b907ff997c3a62c92ab22325c726b612de5b)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Provide an option to devtool build-image to specify the list of packages
instead of taking the list of packages produced by recipes in the
workspace. Sometimes you don't want all of these packages; other times
you want to add more.
This is the most immediate fix for [YOCTO #8855], though it is a little
crude so I would like to provide better means of customising the image
contents later.
(From OE-Core rev: b3a44951a74fe58714b72e71a7a558b67a71e1e3)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
standard.py is getting a bit large; move the "utility" commands to
another module.
(From OE-Core rev: 5089b93f5b341dc28c343f7afe15efda2081ed36)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Add simple initial eSDK test. Currently, only download size and
installation time of eSDK is measured. The eSDK to be tested is
generated from the same image that the other tests are run for. This
patch will add two new fields to the global results log and that needs
to be taken into account when examining the results.
(From OE-Core rev: c903c1e1f36a4dd1dc1b7a621fa7a6ffe7411119)
Signed-off-by: Markus Lehtonen <markus.lehtonen@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Make it possible to time also other than bitbake commands. The name of
the log file is changed from bitbake.log to commands.log.
(From OE-Core rev: 7b355dc96255b06f3108a7d02ab0ed408d64bf1b)
Signed-off-by: Markus Lehtonen <markus.lehtonen@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
I was a little bit hasty in OE-Core revision
c2cc5abe34169eae92067d97ce1e747e7c1413f5 - it turns out BitBake's
fetcher code is not consistent in whether it logs something useful or
not; when fetching from an http URL it does but with a git repository
it doesn't. In advance of any major reworking of fetch error handling in
BitBake, let's just print the text of the exception and then we know we
have shown something to the user.
Additionally, we were only catching FetchException here but there are
several other classes of exception that the fetcher can raise (e.g.
MalformedUrl); catch the parent BBFetchException class instead so we
avoid tracebacks for those other classes as well.
(From OE-Core rev: 578d3873a6415c9203c185c21cff472f7d2dab02)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If the URL ends in a / then we want to strip that off the path we split
out of the URL before calling os.path.basename() on it.
(From OE-Core rev: 308189beda8a31541481d09e3d5e86187e843d8d)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If you specify a local directory which happens to be a git repository
with an origin remote (and it is in fact remote), we can use that for
SRC_URI rather than leaving it blank in the recipe.
(From OE-Core rev: b143d414846854dc8b3e0a47358daf5646eded38)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Sometimes you don't want to build an entire project, just a subdirectory
of it; add a --src-subdir option to make that easier. (We still look for
a single subdirectory in what gets unpacked, e.g. what you might find
within a tarball, so whatever you specify with this option is added onto
the end of that.)
(From OE-Core rev: 59682d78f95732e014f78f13e0a05f843860d9bb)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Quoting is optional in CMakeLists.txt and is occasionally used, so strip
out quotes if they are present.
(From OE-Core rev: 4ffe2e1ec9df05b92a2ad5746fb0ca6d218fd77e)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When constructing the sstate-cache directory for the extensible SDK,
we were copying in any matching native sstate packages, and as the
signature doesn't actually change when the distro changes (since
NATIVELSBSTRING is just a path separator for the artifacts and is not
part of the signature) we ended up copying duplicated packages when the
distro changed e.g. upon host distro upgrade. Only search in the
NATIVELSBSTRING-named subdirectory for native packages and the issue
goes away.
Fixes [YOCTO #8885].
(From OE-Core rev: 6c6baf6aa1823b8b20123f505e45c2768a193ad5)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Add the ability to install additional pre-built items (from shared
state) into the extensible SDK. This can already be done implicitly by
adding something to DEPENDS within a recipe you're working on and then
running "devtool build", but it's useful to be able to explicitly
install things particularly if you're using the extensible SDK as a
traditional toolchain.
Note that for this command to be useful you need to have SSTATE_MIRRORS
set in your SDK configuration, and that mirror needs to be populated
with sstate artifacts for recipes you wish to be able to install.
(From OE-Core rev: 3474a42954908d1688fd3a6cb600eed315b27833)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Make the following improvements to the SDK update process:
* Use a manifest file with sha256sums to track files other than sstate
and metadata that we need to update - e.g. conf files. This allows us
to handle where files such as auto.conf may or may not be present,
as well as the configuration changing without affecting task signatures
- we still want the config files copied in that case rather than it
saying nothing needs to be done.
* Write the SSTATE_MIRRORS_append to site.conf rather than local.conf
so that local.conf remains static (since we don't want to trigger an
update every time). Also, If there is an SSTATE_MIRRORS value already
set in the configuration we can skip this and assume it contains the
needed packages.
* Allow the update process to be run in any directory, don't assume
we're already at the base of the SDK
* Where practical, fetch remote files into a temporary location and
then move them to the desired location at the end, to avoid a
failed update leaving the SDK in a broken state.
* Update all installed do_populate_sysroot / do_packagedata tasks
instead of using the SDK targets. This ensures any item installed
through dependencies after installation (e.g. when running
"devtool build") won't go stale.
(From OE-Core rev: 3d35631121f0e030bc8151f5c23d84008d06f44b)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* Use tempfile.mkdtemp() instead of hardcoding temp dir
* Set a variable early for the temp locked sigs file and use that
everywhere
* Delete the temp dir at the end
(From OE-Core rev: bad5d1a8c047a8118d30d9fa708b021d1599e0dc)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When you run devtool build, you need to have the pkgdata written out at
the end, so that if what you're adding is a library and the next thing
you add is something that depends on that library, the necessary
information to map the dependency back to the recipe is present. In
practical terms all this means is we need do_packagedata to run in
addition to do_populate_sysroot.
This does mean that do_package needs to run which wasn't running before,
and that means that the few package QA tests that run within do_package
such as installed-vs-shipped will now be run. This may be a bit
bothersome, and prompted a fix for one of our oe-selftest tests as a
result, but I don't see an easy way around it. Ultimately if you care
about using the recipe in an image you'll need to fix any such errors
anyway.
Fixes [YOCTO #8887].
(From OE-Core rev: 6579c7120ee5a541427ff5b6b07f838d52f9fe7c)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Add a variable SDK_INCLUDE_PKGDATA which you can set to "1" to include
pkgdata for all recipes in the world target. There are a couple of uses
for this:
1) If you use "devtool add" to add a recipe that builds something which
depends on anything in world, the dependency can then be correctly
mapped to the recipe providing it and that recipe can be added to
DEPENDS, since we have the pkg-config and shared library dependency
data within pkgdata.
2) You'll be able to search for these recipes and any files they
package for the target with "devtool search" since that also uses
pkgdata
This of course assumes you've tailored world through EXCLUDE_FROM_WORLD
to only include recipes you'd want built in your distro, but I think
that's a reasonable assumption; failing that there is a
WORLD_PKGDATA_EXCLUDE variable that you can set to exclude any recipes
you don't want.
Note that this patch relies on functionality implemented in a recent
BitBake patch and will not work without it.
Implements [YOCTO #8600].
(From OE-Core rev: 67149ea097d6fab7496b43e85a40853f40bd527e)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Upgrades python-setuptools to 19.2, easy_install works out of the box
adds the package python-plistlib to the manifest as it is needed by
setuptools now, and also updates runtime dependencies
(From OE-Core rev: 25efefac9f68d34bbb109645a515010b846c3a8b)
Signed-off-by: Alejandro Hernandez <alejandro.hernandez@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Added missing docstrings, fixed wrong indentation and long lines.
Final pylint score is 9.89/10
(From OE-Core rev: 6e5dd42727b40c6b5ba6235026a6cfc78f482ac9)
Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Added description of 'include' parser command to the
'wic help kickstart' output.
(From OE-Core rev: 7481f39382e63ecbb5de406559cc28e5689bd974)
Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
In order to give and example of 'include' feature of ks parser
and for testing purposes common parts of 3 canned wks files were
moved into common.wks.inc
(From OE-Core rev: 629c6381669bd4acdb1613229cd095881d2d9cd2)
Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Used custom argument type to implement search of include
.wks files in canned wks paths. Include files can be
specified either by full path or by name.
[YOCTO #8848]
(From OE-Core rev: 3695962ba4b685f304f1039978cec60d1b1712e3)
Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This function is going to be used by ks parser to find include .wks
files. get_boot_config name is a bit confusing as function is quite
generic. It looks if file is present in the canned wks directories.
Renamed get_boot_config -> get_canned.
Renamed parameter file_boot -> file_name.
Updated description.
(From OE-Core rev: 8ea9a4c0422c9600cd33ec6e815ebcf2d0aad364)
Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Extended parser to support inclusion of .ks files:
recursively called self._parse to parse included .ks
(From OE-Core rev: 33dd323ec6a1a1ed4e1a04e51de182c89c7b6bd9)
Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Interesting bug was found during implementation of 'include'
parser command.
Build directory was removed in do_configure_partition method of
bootimg- source plugins. This can cause removal of previously
prepared partition images if /boot partition is mentioned after
other partitions in .ks file.
Moved work directory removal to direct.py before processing
partitions.
(From OE-Core rev: ba98262573cf1600e0d477317f51d488b5f8c4bd)
Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This is a preparation for 'include' support.
Used unique counter instead of line number for partitions
in .ks file. Line numbers can be equal for different .ks files,
which can cause problems if one .ks file is included into
another.
(From OE-Core rev: cc2233b51f1d22d4e540f4a3e9ceedd7ede9ffa9)
Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This is a preparation for implementation of include statement.
Parser will be called recursively to parse included .wks files,
so it should be available as a method.
(From OE-Core rev: 7778b9851758f4f782cb5f5d5fb36e68aed3b275)
Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If a postinst has a problem (say, qemu crashes) and set -e isn't in operation,
the only mention of the problem is a single line in the rootfs log that doesn't
trigger any warnings.
(From OE-Core rev: 072800f89a136bb5da44627f25599d3060cca0a1)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
I found these when I was looking at libftdi and they seem to be
generic enough to show up in at least a couple of other packages so I
figure I'll add them.
(From OE-Core rev: 9fa3ff44e05930d4dfa153db777077e747ecbf45)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Add support for extracting dependencies from CMakeLists.txt. There's
still a bunch of things missing that are outside the scope of OE-Core
and we still lack a proper extension mechanism, but this is a good
start.
This also adds an oe-selftest test to exercise the new code a bit.
Implements [YOCTO #7635].
(From OE-Core rev: 77e73e6930381fdbd6e78d3913d6467572e16568)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We want to specify dependencies on virtual/* rather than whatever
library is selected in the current configuration.
(From OE-Core rev: e1ac0c45b27ded9962edaf34597f827d0b41ba82)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Some refactoring to allow access to the library/header/pkg-config
mappings and the DEPENDS / unmapped dependency output code from other
classes than AutotoolsRecipeHandler.
(From OE-Core rev: 40c10d998b90dd59c6d36c28f8ba11ec598bfa0f)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The regex for detecting git URLs was unanchored, leading to it matching
where it shouldn't have. An example of where this went wrong was
http://taglib.github.io/releases/taglib-1.9.1.tar.gz.
(From OE-Core rev: bacff751c88b680fbfb07843b18c59c8bc80a9ea)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Support a number of macros from autoconf-archive when reading
configure.ac to extract dependencies.
(From OE-Core rev: ee977a62c58ded361c2abd78654bd25637fe9ea1)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
There are a few different macros that can be used to pick up these
tools, add support for them all.
(From OE-Core rev: 7dfff4b7f05653aea230294ff1a7c023730deff9)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The presence of BOOST_REQUIRE or AX_BOOST.* indicates that boost is a
dependency.
(From OE-Core rev: 02570b1fc31c7f4e9643aea8365806089622c0e7)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* The regexes for PKG_CHECK_MODULES / AC_CHECK_LIB were a bit too strict
and thus we were skipping some macros.
* Add support for PKG_CHECK_EXISTS
* Avoid duplicates in warning on missing pkg-config dependencies
* Ignore dependency on musl (since this may come up if it's the selected
C library)
(From OE-Core rev: c58669fb0977f7f0cb79f252484d5c5ef0dfb7e4)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
kickstarter.py was not the best name for this module as previously
there was a directory with the same name in scripts/lib/wic/.
All files were removed from it, but .pyc files could still stay there
causing imports from wic.kickstart to fail with
ImportError: cannot import name KickStart.
(From OE-Core rev: b9d400be06bc4a4bb9f9c6a6a0c8e5ecfd4e2dfb)
Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Overriden error method to throw exception instead of
printing usage error message. Exception is caught by
KickStart code to add .ks file name and line number.
(From OE-Core rev: 373016ba08c2ec4dbcd44649d9c8cd57d5574402)
Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Removed imports of wic.kickstart from plugins as they're
not used in the code.
(From OE-Core rev: 33d8784470c506fabcf9627e754628cdea61dd07)
Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Caught argparse.ArgumentError
Included .ks file name and line number into the error messages.
(From OE-Core rev: 549c76ebda9afba0771d6d2c9b0b83f7a479c626)
Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Catch parsing errors and output them using msger.
(From OE-Core rev: 9c058f115583592f5cce2a969882fdd0c2ab535f)
Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This exception will be raised by kickstart parser
on parsing errors and processed in the code which
calls parser to produce meaningful error output.
(From OE-Core rev: 13092793693c1c0ea172701578506f4a70a093d2)
Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Without one of the --ondrive, --ondisk or --use-uuid options for a
partition with a mountpoint specified the automatically generated
fstab entry will be invalid.
[YOCTO #8844]
(From OE-Core rev: a524ced19db05e776834cd1f1db03c68a05f9c0b)
Signed-off-by: Joshua Lock <joshua.g.lock@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Used partitions and configfile bootloader attributes instead of
using getters get_bootloader_file and get_partitions.
(From OE-Core rev: d34dd190e1da00ca8c9b2cb0adba15b9f0de2920)
Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Used size and source_file attributes instead of using
setters. It's more pythonic, clear an consistent.
(From OE-Core rev: 7cf236047fa5d0d947fd214181c9a63ccb2509ac)
Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Got rid of get_rootfs and set_rootfs java-like getter and
setter. Renamed rootfs to rootfs_dir to be consistent with
the name of kickstart parameter --rootfs-dir.
(From OE-Core rev: 51ec52a62ce49d1a1a83489379990f78cfe849f9)
Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Used bootloader.timeout instead of kickstart.get_timeout getter.
Accessing attributes instead of getting them with getters is
more pythonic, shorter and readable. It also more consistent as
most of partition and bootloader attributes are used this way.
This change also takes care of appendLine bootloader attribute:
it's renamed to bootloader.append attribute provided by new parser.
(From OE-Core rev: 8088caeff5bf4ee9279b47a69c9f1e5537909601)
Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
New data structure is less nested than old one.
Adjusted bootloader and partitions fields:
self.ks.handler.bootloader -> self.ks.bootoader
self.ks.handler.partitions -> self.ks.partitions
(From OE-Core rev: b46da0731e3f7016d0ab2a67967f07c7e199f219)
Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Removed pykickstart-related code as it's replaced by
new kickstart parser.
(From OE-Core rev: 30bb1f3b6b832f9be691350581458c5fdaaaad70)
Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Used KickStart parser class instead of pykickstart API.
This commit breaks wic as data structures and field names
provided by new API are a bit different from old ones.
This issue will be addressed in the following commits.
(From OE-Core rev: f72439d321220b724bfe2b4a92fed46c2c19fb3f)
Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This module will replace existing pykickstart machinery
it contains only option used by wic, it's simple and
clear. And It will allow to remove a lot of old complex
code from 3rdparty/pykickstart/ and kickstart/custom_commands.
(From OE-Core rev: c7b67ccfda8b22c090aa74d96b7c9af5a97a9a98)
Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Copied partition-related API from kickstart/custom_commands/partition.py
to separate module in preparation for removal of all
pykickstart related code.
(From OE-Core rev: a915c4cbc33ef0a12546ac0000ecf8aedb6241d5)
Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
By default fc-cache will scan both system and user directories, which means it
attempts to scan $HOME/.fonts. As this is the build host's idea of $HOME this
generally doesn't exist, and causes fc-cache to exit with a failure.
Solve this by passing --system-only so that fc-cache will only scan system
directories, as is appropriate for a rootfs-time invocation.
(From OE-Core rev: 541315d6c56df6448f64c262f99d43d5c1e9400b)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* at least with git 2.6.3 I see git request-pull failing
when there is only :{BRANCH} as ending commit
* $ git request-pull origin/dizzy git://git.openembedded.org/openembedded-core-contrib jansa/dizzy-backports:jansa/dizzy-backports
The following changes since commit 7bb182bdd130266100fc541fd09b82d09c51cd80:
build-appliance-image: Update to dizzy head revision (2015-09-29 14:56:04 +0100)
...
And finds correct 7 changes there
* $ git request-pull origin/dizzy git://git.openembedded.org/openembedded-core-contrib :jansa/dizzy-backports
warn: No match for commit 6068d1c90336ddc1fb32856efd1d9ccf07733896 found at git://git.openembedded.org/openembedded-core-contrib
warn: Are you sure you pushed 'jansa/dizzy-backports' there?
The following changes since commit 97756472d3a69eaca95d105494ffea78c6b077e0:
build-appliance-image: Update to dizzy head revision (2014-10-18 16:16:27 +0200)
...
and lists all commits in _current_ branch since origin/dizzy, then it refuses
to continue, because there are too many changes.
* 6068d1c90336ddc1fb32856efd1d9ccf07733896 is this commit in jansa/master-submitted
branch so it really shouldn't be included in pull request from jansa/dizzy branch.
* git help says:
<end>
Commit to end at (defaults to HEAD). This names the commit at the tip of the history you are asking to be pulled.
When the repository named by <url> has the commit at a tip of a ref that is different from the ref you have locally, you can use
the <local>:<remote> syntax, to have its local name, a colon :, and its remote name.
* maybe the syntax got changes since git 2.1.0 when Saul added :${BRANCH}
* I haven't found how to respect ${COMMIT_ID in the new syntax
(From OE-Core rev: 2336d1e5de671f538f0cd493b75d29e1dfdb0caf)
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Rather than horrible workarounds, use the new --setscene-only option
of bitbake to pre-populate the SDK structures.
(From OE-Core rev: 38237b7ac53c416f85c4a70a61acafc3404c8b5f)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
It's logical that you would want to build BBCLASSEXTENDed items
separately through devtool build, so simply allow that - we're just
passing the name verbatim to bitbake, so all it means is adjusting the
validation.
(From OE-Core rev: 25dc5ac42c9da53c01416e7fdcc819d729281133)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If the recipe file itself was created in the workspace, and it uses
BBCLASSEXTEND (e.g. through devtool add --also-native), then we need to
clean the other variants as well.
(From OE-Core rev: e1bf6a30679a83d4dbcf37276204f639541e95f9)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We're doing this in a couple of places, let's just find the recipe file
if it exists within the workspace (which it will if it's been added
through "devtool add") when we read in the workspace.
(From OE-Core rev: 81cf5580993c99050e3f4d6d891bc67534721487)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Sometimes you need to build a variant of a recipe for the build
host as well as for the target (i.e. BBCLASSEXTEND = "native"); add a
--also-native command line option to "recipetool create" that enables
this and plumb it through from an identical option for "devtool add".
(We could conceivably do the same for nativesdk, but I felt it might be
confusing within the context of the extensible SDK, where nativesdk
isn't really relevant to the user.)
(From OE-Core rev: f3bea83db173cce921a9a30f04e88b7e3ed98854)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We need to run the clean for all recipes that are being reset before we
start deleting things from the workspace; if we don't, recipes providing
dependencies may be missing when we come to clean a recipe later (since
we don't and couldn't practically reset them in dependency order). This
also improves performance since we have the startup startup time for the
clean just once rather than for every recipe.
(From OE-Core rev: c10a2de75a99410eb5338dd6da0e0b0e32bae6f5)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If the recipe name ends with -native then we should inherit native;
likewise if it starts with nativesdk- then inherit nativesdk.
(Note that the recipe name must actually be specified by the user in
order to trigger this - we won't do it based on any name auto-detected
from e.g. the tarball name.)
Since we're doing this based on the name, "devtool add" will also gain
this functionality automatically.
(From OE-Core rev: a216fb1f5953327790dce3d2c1a9af616c0b410d)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
As a matter of general convention we expect recipe names to be lower
case; in fact some of the packaging backends insist upon it. Since in
this part of the code we're auto-determining the name, we should convert
the name to lowercase if it's not already so that we're following
convention and avoiding any validation issues later on.
(From OE-Core rev: 64986decbc11afa0d1e11251f5f7adcba1860d19)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
For debugging purposes it's useful to be able to skip the preparation
step so you can inspect what the state of the build system is first.
(From OE-Core rev: 0bba4b5afd2ce2c3a79445eee886979a77f1a4d8)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Running "raise" with no arguments here is invalid, we're not in
exception handling context. Rather than also adding code to catch the
exception I just moved the check out to the parent function from which
we can just exit.
(From OE-Core rev: 0164dc66467739b357ab22bf9b8c0845f3eff4a4)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* Clone the correct path - we need .git on the end
* Pull from the specified path instead of expecting a remote to be set
* up in the repo already (it isn't by default)
(From OE-Core rev: 1a60ee8bd21e156022c928f12bb296ab5caaa766)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We read the updateserver setting from the config file but we never
actually used that value - the code then went on to use only the value
supplied on the command line.
Fix courtesy of Dmitry Rozhkov <dmitry.rozhkov@intel.com>
(From OE-Core rev: 1c85237803038fba539d5b03bf4de39d99380684)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We need to call git update-server-info here on the created repository or
we can't share it over plain http as we need to be able to for the
update process to function as currently implemented.
(From OE-Core rev: 3ab40bf9d5f19d91e45f7bae77f037b2544e889b)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The yocto-layer script puts and extra "meta-" prefix on the given layer
name even when the prefix is already there. This fix avoids duplicating
the prefix in these situations.
The change was done inside the create subcommand since this is a parsing
specific to the layer creation. Parsing this in the main method of
yocto-layer was not the right way to go.
Before the change:
$ yocto-layer create meta-layer
[...]
New layer created in meta-meta-layer.
After the change:
$ yocto-layer create meta-layer
[...]
New layer created in meta-layer.
[YOCTO #8050]
(From meta-yocto rev: e21c79eb830ed1593e81f2d58815664109a10933)
Signed-off-by: Humberto Ibarra <humberto.ibarra.lopez@intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The 3.14 and 3.19 kernel have been removed from oe-core, so we drop
our bbappends.
(From meta-yocto rev: e82a9e75b2d02387fc58232ee469ed0ae661b996)
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Hooking up a serial console is a "developer mode", the chances are pretty good
developers are interested in watching the kernel boot log on the console so
they can spot any problems or diagnose any failed boots (e.g. can't find root
fs).
(From OE-Core rev: d03e399623b9320268a2b56e4928bb7effa9146c)
Signed-off-by: Trevor Woerner <twoerner@gmail.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Regardless of which image is built using which layers, try to ensure the image
on the SD device being prepared is the one that is booted automatically when
the board is powered.
(From OE-Core rev: 51dc79d55d0985e64838a08d39a22e8cd3fcd59a)
Signed-off-by: Trevor Woerner <twoerner@gmail.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* add more php5 entries
* add builder user (from builder.bb)
* add .bashrc and .profile in HOME directory of created user
* add imgdata directory generated by image.py
(From OE-Core rev: 49c744321ff1dfb16491d300ff46b6b5d5aa3f14)
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Add an option for random MACHINE into oe-selftest:
--machine [random/all]
1. random: will set a random MACHINE for each test
2. all: will run tests for all machines
Custom machine sets only weak default values (??=) for MACHINE in machine.inc.
This let test cases that require a specific MACHINE to be able to
override it, using (?= or =).
e.g.:
oe-selftest --run-tests signing --machine random -->
will run all tests switching MACHINE randomly for each test
oe-selftest --run-tests signing --machine all -->
for each machine will run all tests
oe-selftest --run-all-tests --machine random
Also update oeqa/selftest/base.py to accomodate this feature.
Fix for [YOCTO #5880].
(From OE-Core rev: 4a9c3653eecd9a3c1b45bab5e16c8d679c55f8bd)
Signed-off-by: Daniel Istrate <daniel.alexandrux.istrate@intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This option will list all available tests in a comprehensive manner.
Fix for [YOCTO #8868]
(From OE-Core rev: 8b9ea3ee39bceef7ee6faeef64f33bd9dbad2e4b)
Signed-off-by: Daniel Istrate <daniel.alexandrux.istrate@intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
--list-classes does a weak validation when determining test names:
(if method.startswith("test_") which could report any class attribute
that starts with 'test_' as a valid test case.
This fix checks that the class attribute that starts with 'test_'
is also callable (is a method).
Fix for [YOCTO #8862]
(From OE-Core rev: 175810503d5596370cf7d840539ebdf35cf30278)
Signed-off-by: Daniel Istrate <daniel.alexandrux.istrate@intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Coverage data tracking initiates too early, causing coverage data from the
oe-selftest environment setting to be added to each run. Even when no tests are run
oe-selftest reports around 24% of coverage due to this extra data.
Change the custom resultclass used by the TextTestRunner to one generated from the
command arguments. The generated class processes coverage when needed, running
coverage setup just before the first testcase is run and reporting after the last
one finished.
[Yocto #8846]
(From OE-Core rev: d66a4c5cb77f745e973daf34b84724f91549f391)
Signed-off-by: Humberto Ibarra <humberto.ibarra.lopez@intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When a file is given using --sourceparams then wic directly use that file
instead of copying them to build folder. At time of assembling it os.rename
is called which renames all the files to name. In that process the original
file is renamed. When image recipe is rebuilt then wic complains about
missing file which was renamed in previous build.
[YOCTO #8854]
(From OE-Core rev: 33c52b1f2d39feb641465bf42e8b16d0ab22a316)
Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Copied layers with 'cp -a' instead of calling shutil.copytree as
copytree fails to copy broken symlinks.
More pythonic fix would be to use copytree with 'ignore' parameter,
but this could slow down copying complex directory structures.
[YOCTO #8825]
(From OE-Core rev: e5b841420b9fdd33829f7665a62cd06a3017f7e6)
Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Each time oe-selftest runs, the oe-selftest.log file is overwritten.
This patch solves it by adding time stamp to each selftest log file
and doing a symlink named as oe-selftest.log to the last one created.
(From OE-Core rev: da8097480ad70e7a75608d733c63c3ae5a337974)
Signed-off-by: Costin Constantin <costin.c.constantin@intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Having fetched the source and unpacked it to a temporary directory, we
then move part of it to the destination directory, or if the source is at
the top level we move the whole temporary directory, but in the latter
case we were later attempting to delete the temporary directory which no
longer existed. Clear out the variable so that doesn't happen.
(From OE-Core rev: 91714a52e91cddba5a16c73cf5765d1f47f7856c)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* tar and binutils we can assume are there
* libsocket is only relevant on BSD systems, so we can ignore it.
* Detect more things implying gettext/intltool is needed
* Detect glib-2.0 requirement.
(From OE-Core rev: 2c4c78a6a9970533f3352f1067b2263f45098493)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Much of this was copy/pasted from the extract subcommand code; make it
specific to sync.
(From OE-Core rev: 08ca966dd48db881d8bfb7d7fa0aba49f1f7cffe)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We deliberately leave the source tree alone when resetting in case it
contains any work in progress belonging to the user; tell them that
we're doing this so they aren't surprised about it still existing later
on.
(From OE-Core rev: 1c616802ba2cfb37f8403f1dc6cf91ce3bd99ac2)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If a recipe in the workspace actually exists as a file within the
workspace (e.g. after doing "devtool add" or "devtool upgrade") then
show the path to the recipe file on the status line for the recipe.
(From OE-Core rev: 29833828a90c8433af3b231b50e99cd97edf19ff)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
As per the changes to "devtool add", make the source tree path optional
and use the default path if none is specified.
(From OE-Core rev: 83707d1334fb094fd1877bcfd07a83866601048a)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Having to specify -f is a little bit ugly when a URI is distinctive
enough to recognise amongst the other positional parameters, so take it
as an optional positional parameter. -f/--fetch is still supported, but
deprecated.
(From OE-Core rev: aedfc5a5db1c4b2b80a36147c9a13b31764d91dd)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
recipetool create now has all the logic in it for auto-detecting the
name and version, and using those in the file name - so we can make the
name an optional parameter for devtool add and we pick up the file name
that recipetool has used after the fact.
(From OE-Core rev: 70ab08146e930f1fc55fdf5726a87303e20bd60f)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Assuming we're fetching source remotely (from a URI) we can default the
source tree that will be extracted from it to a "sources" directory
under the workspace in order to save the user specifying it if they
don't have a preferred location.
(From OE-Core rev: ffdad964c7271972e4b067e4898bf7c338c25b68)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Python's argparse module can't handle when several optional positional
arguments (set with nargs='?') are intermixed with other options. If the
positional arguments aren't optional then this isn't an issue; thus when
changing positional arguments to optional (as we are doing with devtool)
we need this workaround.
This is a pretty horrible hack, but we don't want this flexibility of
ordering to disappear simply because we made some arguments optional.
Unfortunately the corresponding bug remains unresolved upstream even in
Python 3, and argparse is not really designed to be subclassed so it
doesn't make things like this easy.
(From OE-Core rev: 98fd5de373e16fe5d69a3065f844efc8037385bc)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The bbappend already exists at this point, so we know what its path is -
there's no need to figure it out from scratch here.
(From OE-Core rev: c0754d672966901f22dff1bcd40bbd08d1219c7a)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We're repeating this in a couple of places, so we might as well have a
function to do it.
(From OE-Core rev: 67a28109a1ee1383d1b17a8dafa4fe510948238b)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Add a few clarifying words.
(From OE-Core rev: 2103fa9dc7faf2189c8b426b87fb9d421a9983ac)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Add an "edit-recipe" subcommand that runs your default editor (as
specified by the EDITOR environment variable) on the specified recipe in
the workspace. Note that by default the recipe file itself must be in
the workspace - i.e. as a result of "devtool add" or "devtool upgrade";
however there is a -a/--any-recipe option to override this.
(From OE-Core rev: dbfe8fa2e86c2bb50bef47c389017cdf93543321)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Often the filename (e.g. source tarball) contains the name and version
of the software it contains.
(This isn't intended to be exhaustive, just to catch the common case.)
(From OE-Core rev: 944eacfb849ee69b41e12c9de4f264406281ac6a)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Some build systems (notably autotools) support declaring the name and
version of the program being built; since we need those for the recipe
we can attempt to extract them. It's a little fuzzy as they are often
omitted or may not be appropriately formatted for our purposes, but it
does work on a reasonable number of software packages to be useful.
(From OE-Core rev: 3b3fd33190d89c09e62126eea0e45aa84fe5442e)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Sometimes we want to force one handler to run before another; if the two
handlers are in different plugins that's difficult without some kind of
priority number, so add one and sort by it.
(From OE-Core rev: 0219d4fb9cefcee635387b46fc1d215f82753d92)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If the user specifies a URL that just returns a web page, then it's
probably incorrect (or broken); attempt to detect this and show an error
if it's the case.
(From OE-Core rev: 83b1245b2638eb5d314fe663d33cd52a776a34a7)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If you specify a URL ending in /, BitBake's fetcher returns a localpath
of ${DL_DIR}, and if you then try to unpack that it will attempt to copy
the entire DL_DIR contents to the destination - which at least on my
system filled my entire /tmp. Obviously we should fix the fetcher, but
at least detect and stop that from happening here for now.
(From OE-Core rev: 7e63a672517518644a37ce006e05b5494c29cf6e)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If SRC_URI happened not to be in the pre-generated lines then this code
would error out. This is unlikely to happen with the way the create code
is structured at the moment, but handle it just in case.
(From OE-Core rev: 95d33e90f2d5d9dd5ccc950856b8a939fefb831e)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
In my testing here it appears make -qn returns an error (exit code 2)
whereas make -n doesn't; I can't immediately tell why based on the
documentation. We don't actually care for it to be quiet since we're
capturing the output, so let's just leave -q off and have this work
properly as a result.
(From OE-Core rev: 30c4cd9efdac400d713dff645f23f2627277d75a)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If a fetch error occurs, the fetcher already prints a reasonable error -
we don't need the traceback as well, so catch that and exit if it
occurs.
(From OE-Core rev: c2cc5abe34169eae92067d97ce1e747e7c1413f5)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When you grab a URL for a github repository you'll almost certainly find
it in https://github.com/path/to/repository.git format; but bitbake's
fetcher can't handle that because it'll see https:// at the start and
assume it should use wget to fetch it. If the URL starts with http:// or
https:// and the path part ends with .git then assume it's a git
repository and adjust it accordingly.
(From OE-Core rev: bdbc4cf41d30eddb8a9ed882dedcc1670ce8fdd6)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
For scripts that use Python's standard argparse module to parse
command-line arguments, create a subclass which will show the usage
the usage information when a command-line parsing error occurs. The most
common case would be when the script is run with no arguments; at least
then the user immediately gets to see what arguments they might need to
pass instead of just an error message.
(From OE-Core rev: d62fe7c9bc2df6a4464440a3cae0539074bf99aa)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If the SDK update server hasn't been set in the config (when building
the extensible SDK this would be set via SDK_UPDATE_URL) and it wasn't
specified on the command line then we were failing with a traceback
because we didn't pass the default value properly - None is interpreted
as no default, meaning raise an exception if no such option exists.
Additionally we don't need the try...except anymore either because with
a proper default value, NoSectionError is caught as well.
(From OE-Core rev: 9763c1b83362f8445ed6dff2804dd7d282861f79)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If no mountpoint is specified for a partition command the partition
will be created but not mounted — mention this in the kickstart
help text.
[YOCTO #8820]
(From OE-Core rev: d1ff1fef987457eb1a5ffe42dbabc7808fa7d598)
Signed-off-by: Joshua Lock <joshua.lock@collabora.co.uk>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The script oe-buildenv-internal is called from oe-init-build-env.
Make sure oe-init-buildenv does not return an error if BB_ENV_EXTRAWHITE is
already set, otherwise this will cause oe-init-build-env to fail.
(From OE-Core rev: 9ae79973cfdabd1b4dacddce32735c65fe3544e4)
Signed-off-by: Juro Bystricky <juro.bystricky@intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Cc: Paul Eggleton <paul.eggleton@linux.intel.com>
(From OE-Core rev: 3c4de5430aff2d7443f064d698014615e867c58c)
Signed-off-by: Christopher Larson <chris_larson@mentor.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
I ran into an issue where a patch just deleting a single file
within the repository (meta/recipes-devtools/m4/m4/make.patch)
would get skipped by combo-layer.
It turns out this has the patch header (commented to avoid breaking scripts):
: diff --git a/meta/recipes-devtools/m4/m4/make.patch b/meta/recipes-devtools/m4/m4/make.patch
: deleted file mode 100644
: index 79fb415..0000000
: --- a/meta/recipes-devtools/m4/m4/make.patch
: +++ /dev/null
: @@ -1,42 +0,0 @@
and this is classed as > 5 headers in filterdiff. When we piped the path
through filterdiff, the --- line disappears, then the second time we pass
through filterdiff, it shows no lines changed and the patch is assumed
to be empty and skipped.
Changing MAX_HEADERS in filterdiff is one way to fix this, another would
be to grep out "deleted file mode" lines. Instead, we can use new
git syntax to exclude files from the git format-patch instead and avoid
filterdiff entirely.
(From OE-Core rev: 296c70afeef75396dea9ae436058314d406dc257)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>