New crosstap python implementation is total replacement for
crosstap shell script, that has superseding capabilities.
New script support cross compiling of SystemTap scripts
for user-land, by using supplied image rootfs. Whereas old
script could only deal with scripts against kernel. New script
has more complex logic and additional capabilities.
As invocation interface new script support old "legacy"
mode and provides alternative new regular options interface
to access additional functionality.
(From OE-Core rev: 1cbbcf26e0a9ca6e0b34a89512bf75dbae8bfaf0)
Signed-off-by: Victor Kamensky <kamensky@cisco.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
A flaw was found when I run:
$ recipetool create "ssh://git@xxx.xxx:7999/xxx.git"
the url turned out to be: "git://git@xxx.xxx/7999/xxx.git;protocol=ssh"
after parsing, the port number was parsed as part of the path, this is
definitely wrong and lead to fetching failures.
This issue could be fixed in reformat_git_uri, by filtering out port
numbers when formatting ":".
(From OE-Core rev: 4290e04b69360b5e1da9f37166015e30f66cb335)
Signed-off-by: Ming Liu <liu.ming50@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
After we switched to RSS, this script was not working for a long time.
'bitbake package-index' can do the same thing and works well. So remove
this script.
(From OE-Core rev: 94fea92f5e7f7c0765e89743a1586b22186a16cd)
Signed-off-by: Yi Zhao <yi.zhao@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
LayerError doesn't exist and will lead to an error when this failure
code path is hit.
(From OE-Core rev: 7780482772d005c77825dc3e99e63f00911156bf)
Signed-off-by: Anuj Mittal <anuj.mittal@intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Fix a crash when generating a txt report and the two commits to be
compared were not consecutive (but there were some tested commits
between them).
(From OE-Core rev: f3afd2c47f4c740df52dfd80e208ce721d5ebf6e)
Signed-off-by: Markus Lehtonen <markus.lehtonen@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Building world means recipes that are excluded from world build for whatever
reason get skipped from the manifests, which isn't useful. Instead building
universe and pass -k so that the expected dependency failures are not fatal.
(From OE-Core rev: 2d798f9f56fbd7cd20de4b797a476ad24c214ff3)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This is very useful for updating patch context so that any fuzz is eliminated.
Simply issue:
devtool modify <recipe>
devtool finish --force-patch-refresh <recipe> <layer_path>
Without this flag, devtool will not deem the commits in the workspace
different to patches in the layer, even if the commits have different,
up-to-date context line in them.
(From OE-Core rev: 7e1d1887be8faaaab9996fca9a3fd750aeb7b62f)
Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Using --exclude-path and a wks.in file we can create an image that takes
the /boot/ directory for the boot partition, has an empty /boot/
directory in the rootfs partition. The boot partition gets mounted to
/boot/ after startup.
(From OE-Core rev: db904053e8ee80fb6930c5e7e22287927e0f25e2)
Signed-off-by: California Sullivan <california.l.sullivan@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Set a miniumum FAT16 volume size because images are
not valid to parted if this minimum value is not respected.
The value set is determined experimentally forr a logical
sector size of 512. This fixed my local problem but, there
may be better solutions.
(From OE-Core rev: f7dfb4d43247d3c13a4e0a3853007d63b9512b83)
Signed-off-by: Paulo Neves <ptsneves@gmail.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The partition plugin is used as the base for other plugins.
One of the methods the plugins use, is the prepare_rootfs
method.
The prepare_rootfs method wrongly assumes that the value
ROOTFS_SIZE from bitbake datastore is relevant to every
invocation of prepare_rootfs, which it clearly is not, for
example in the bootimg-partition case.
This commit adds an optional argument to prepare_rootfs
where a caller can tell prepare_rootfs if it is an actual
rootfs and whether related rootfs information retrieved from
bitbake is valid. The default behavior of this optional
argument is to assume that the invocation is an actual
rootfs, to maintain compatibility with previous
implementations.
(From OE-Core rev: 654d72d55194ec41bc1aacfcc6b2c8c9a305b042)
Signed-off-by: Paulo Neves <ptsneves@gmail.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
do_post_partition hook is needed if some operations like security signing
the parition needs to be done. source plugins can make use of this to implement
post operatiosn in do_post_partition. do_post_partition is called after
do_prepare_partition if present.
(From OE-Core rev: 5055489b9ab3fda32a285d0d165d080d11a4d432)
Signed-off-by: Parthiban Nallathambi <pn@denx.de>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* We now match on more than just target recipes, so don't specify that
only target recipes are searched.
* We're printing the SUMMARY value in addition to the name, so mention
that so it's clear where that text is coming from.
* Remind users that they should use quotes around the keyword to avoid
shell expansion when using regular expressions.
(From OE-Core rev: cc68971557fe065e59ff47657f650051eb85db3c)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If pkgdata isn't present or is incomplete, then you get either a
traceback or you don't see the results you were hoping for. The recipe
cache that bitbake collects during startup contains some useful
information for each recipe that we could search through as well, and
we can access it easily using tinfoil's all_recipes() API function,
so add some code that does that. (We still show a warning if pkgdata
isn't present, as there are certain dynamic packages that are generated
at packaging time that won't show up in the cache).
One side-effect of this is that we will start showing non-target
recipes - that's actually a good thing, since seeing those is useful,
however we exclude nativesdk recipes when in the eSDK to avoid confusion
since nativesdk isn't directly applicable there.
Fixes [YOCTO #12356].
(From OE-Core rev: b8406383886d09a80a9a002150dcf364fa9902d7)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If the user doesn't specify a port then we should avoid specifying one
on the ssh/scp command line in case the user has configured one for the
host they are connecting to, which was being overridden unnecessarily.
Fixes [YOCTO #12381].
(From OE-Core rev: f1020eef09fada7ef2231d5528576553f3f6bfe1)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
After OE-Core rev 5e3fe00a0233d563781849a44f53885b4e924a9c we call
os.path.abspath() on the original layer path, but we later compare that
to the destination layer path. If that layer path isn't absolute but is
effectively the same path, it should be writing to the original recipe
but because we weren't making it absolute we were writing a bbappend
instead. Call os.path.abspath() on the destination path as well to avoid
that.
(From OE-Core rev: a85a78dcf226d160e9b504bfa67b306a9175ac29)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If the .devtool_md5 file doesn't contain a reference to the bbappend
file (e.g. because devtool was interrupted before it could write that
out) then _check_preserve() won't delete it, so we need to delete it
separately because otherwise the recipe won't actually be reset.
(From OE-Core rev: 751d27600a3df18d96baaa48696acf33ee964bec)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Fix two aspects of handling BBCLASSEXTENDed targets (e.g.
openssl-native) that have been run through "devtool upgrade":
* Fix recipe name not showing up in "devtool status"
* Fix "devtool reset" not deleting empty directories under the recipe
directory within the workspace, which may lead to problems if you
subsequently run "devtool upgrade" on the same target again
(From OE-Core rev: 56e04260d64de9c5b83893d97cf41b7ea9a45878)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
atm, 'oe-init-build-env' expects 'bitbake' to be within the OE core git
repository. This complicates the project setup because you have to
manage the 'bitbake' directory or symlink manually (or specify the
bitbake location explicitly).
Looking for 'bitbake' outside the main git repository will ease project
management significantly. Now, you can put everything into git submodules,
clone the project with
| git clone --recursive ...
and continue immediately with
| ..../oe-init-build-env
E.g. when you had previously
| .
| |-- build/
| `-- sources/
| `-- org.openembedded.core/
| `-- bitbake -> ../bitbake
(where 'bitbake' must be created manually after cloning the project),
you can have now
| .
| |-- build/
| `-- sources/
| |-- bitbake/
| `-- org.openembedded.core/
which is completely managed by 'git'.
Patch adds $OEROOT/.. to the search path for 'bitbake'
(From OE-Core rev: 5b3afc9cfe38a9fb435fbe5fcabc59b9a60f4657)
Signed-off-by: Enrico Scholz <enrico.scholz@sigma-chemnitz.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Make sure that we're passing a bool value. Without this, buildhistory
shows all the output for all the keys/fields when it shouldn't be by
default.
(From OE-Core rev: b30153a15715a83c0f9a7d7d1883a15404992a19)
Signed-off-by: Anuj Mittal <anuj.mittal@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
singletask.lock is written out while certain tasks execute for recipes
that have externalsrc.bbclass enabled - this includes recipes in
devtool's workspace. It appears that there's a race where
singletask.lock will be there one minute and then when we try to get the
file checksum of it (since we want to know if anything in the source
tree has changed) it will be gone, and git chokes. To fix that, add
singletask.lock to .git/info/exclude in the repository, regardless of
whether we created the repository or not. In any case singletask.lock
should never be tracked by git, so this is a good thing to be doing for
that reason as well.
This fixes oe-selftest failures in test_devtool_modify that we've seen
on the Yocto Project autobuilder:
bb.data_smart.ExpansionError: Failure expanding variable
do_compile[file-checksums], expression was ${@srctree_hash_files(d)}
which triggered exception CalledProcessError: Command
'['git', 'add', '-A', '.']' returned non-zero exit status 128.
Note that this only fixes this issue for devtool; if you are using
externalsrc independently of devtool there's a chance this will still
be an issue unless you add singletask.lock to your .gitignore.
(From OE-Core rev: 334ba846c795fc0d8c73ce05a1b0882739c86650)
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>
This allows postinsts scripts to explicitly request a deferral to first boot
(by calling 'postinst_intercept delay_to_first_boot') instead of 'exit 1' which
should be used only to indicate actual script failures.
(From OE-Core rev: 853ac4a061e47c70b61e255c3cf6109d2058d2cc)
Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
distrocompare.sh is added to compare the added list of recipes
between two releases. The output of the script will share the
information of the licenses required and other distributions
that are using the package.
If a single input is provided, it will compare the current
branch with the provided branch/commit-ish package list.
To run : distrocompare.sh <older hash> <newer hash>
E.g. distrocompare.sh morty 92aa0e7
E.g. distrocompare.sh morty pyro
E.g. distrocompare.sh morty
output : The script will produce a file ending with
new_recipe_list.txt preceeded by the branch name from input
(From OE-Core rev: 32b363c2ba91fde4f10e5fe2c898b2fc2702aa85)
Signed-off-by: Tan Shen Joon <shen.joon.tan@intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When searching for variables, include colon to ensure the script doesn't
find a variable that starts with the same name.
(From OE-Core rev: 3d2c87c4f4115b01534ab198c27682c7e4c5f31f)
Signed-off-by: Amanda Brindle <amanda.r.brindle@intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
In lookup_recipe, package_info, and list_pkg_files, check if the package
name exists in runtime-rprovides. If so, and the provider package has a
different name than the inputted package, print a note that says the
specified package is in another package's RPROVIDES. If the provider
package has the same name as the inputted package, continue as before.
Fixes [YOCTO 11943]
(From OE-Core rev: f78478f0d0379ea02727c81ad2455207c70d140b)
Signed-off-by: Amanda Brindle <amanda.r.brindle@intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Refactor functions lookup_recipe and package_info to be consistent with
list_pkg_files. Print the appropriate information as soon as it's found,
rather than storing it in a mappings variable and wait to print after
searching all packages.
(From OE-Core rev: 64d3ce83d5c48d479709b4c1355e23b3768493fb)
Signed-off-by: Amanda Brindle <amanda.r.brindle@intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
See previous commit (python2 version) for more info, since mostly
everything applies here as well.
Old manifest file had several issues:
- Its unorganized and hard to read and understand it for an average
human being.
- When a new package needs to be added, the user actually has to modify
the script that creates the manifest, then call the script to create
a new manifest, and then submit a patch for both the script and the
manifest, so its a little convoluted.
- Git complains every single time a patch is submitted to the manifest,
since it violates some of its guidelines.
- It changes or may change with every release of python, its impossible
to know if the required files for a certain package have changed
(it could have more or less dependencies), the only way of doing so
would be to install and test them all one by one on separate individual
images, and even then we wouldnt know if they require less dependencies,
we would just know if an extra dependency is required since it would
complain, lets face it, this isnt feasible.
- The same thing happens for new packages, if someone wants to add a new
package, its dependencies need to be checked manually one by one.
Features/Fixes:
- A new manifest format is used (JSON), easy to read and understand.
This file is parsed by the python recipe and python packages
read from here are passed directly to bitbake during parsing time.
- It provides an automatic manifest creation task (explained on previous
commit), which automagically checks for every package dependencies and
adds them to the new manifest, hence we will have on each package
exactly what that package needs to be run, providing finer granularity.
- Dependencies are also checked automagically for new packages
(explained on previous commit).
This patch has the same features as the python2 version but it differs
in the following ways:
- Python3 handles precompiled bytecode files (*.pyc) differently.
for this reason and since we are cross compiling, wildcards couldnt be
avoided on python3 (See PEP #3147 [1]).
Both the manifest and the manifest creation script handle this
differently, the manifest for python3 has an extra field for cached
files, which is how it lets the user install the cached files or not
via : INCLUDE_PYCS = "1" on their local.conf.
- Shared libraries nomenclature also changed on python3, so again, we
use wildcards to deal with this issue ( See PEP #3149 [2]):
- Fixes python3 manifest, python3-core should be base and everything
should depend on it, hence several packages were deleted:
python3-enum, re, gdbm, subprocess, signal, readline.
- When building python3-native it adds as symlink to it called
nativepython3, which is then isued by the create_manifest task.
- Fixes [YOCTO #11513] while were at it.
References:
[1] https://www.python.org/dev/peps/pep-3147/
[2] https://www.python.org/dev/peps/pep-3149/
(From OE-Core rev: 54ac820b8a639950ccb534dcd9d6eaf8b2b736e0)
Signed-off-by: Alejandro Hernandez <alejandro.hernandez@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The reason we have a manifest file for python is that our goal is to
keep python-core as small as posible and add other python packages only
when the user needs them, hence why we split upstream python into several
packages.
Although our manifest file has several issues:
- Its unorganized and hard to read and understand it for an average
human being.
- When a new package needs to be added, the user actually has to modify
the script that creates the manifest, then call the script to create
a new manifest, and then submit a patch for both the script and the
manifest, so its a little convoluted.
- Git complains every single time a patch is submitted to the manifest,
since it violates some of its guidelines.
- It changes or may change with every release of python, its impossible
to know if the required files for a certain package have changed
(it could have more or less dependencies), the only way of doing so
would be to install and test them all one by one on separate individual
images, and even then we wouldnt know if they require less dependencies,
we would just know if an extra dependency is required since it would
complain, lets face it, this isnt feasible.
- The same thing happens for new packages, if someone wants to add a
new package, its dependencies need to be checked manually one by one.
This patch fixes those issues, while adding some additional features.
Features/Fixes:
- A new manifest format is used (JSON), easy to read and understand.
This file is parsed by the python recipe and python packages read
from here are passed directly to bitbake during parsing time.
- It provides an automatic manifest creation task (explained below),
which automagically checks for every package dependencies and adds
them to the new manifest, hence we will have on each package exactly
what that package needs to be run, providing finer granularity.
- Dependencies are also checked automagically for new packages (explained below).
- Fixes the manifest in the following ways:
* python-core should be base and all packages should depend on it,
fixes lang, string, codecs, etc.
* Fixes packages with repeated files (e.g. bssdb and db, or
netclient and mime, and many others).
- Sitecustomize was fixed since encoding was deprecated.
- The JSON manifest file invalidates bitbake's cache, so if it changes
the python package will be rebuilt.
- It creates a solution for users that want precompiled bytecode files
(*.pyc) INCLUDE_PYCS = "1" can be set by the user on their local.conf to
include such files, some argument they get faster boot time, even when the
files would be created on their first run?, but they also sometimes give a
magic number error and take up space, so we leave it to the user to
decide if they want them or not.
- Fixes python-core dependencies, e.g.
When python is run on an image, it TRIES to import everything it needs,
but it doesnt necessarily fails when it doesnt find something, so even if
we didnt know, we had errors like (trimmed on purpose):
# trying /usr/lib/python2.7/_locale.so
# trying /usr/lib/python2.7/lib-dynload/_locale.so
# trying /usr/lib/python2.7/_sysconfigdata.so
while it didnt complain about _locale it should have imported it,
after creating a new manifest with the automated script we get:
# trying /usr/lib/python2.7/lib-dynload/_locale.so
dlopen("/usr/lib/python2.7/lib-dynload/_locale.so", 2);
import _locale # dynamically loaded from /usr/lib/python2.7/lib-dynload/_locale.so
How to use (after a new release of python, or maybe before every OE
release):
- A new task called create_manifest was added to the python package,
which may be invoked via:
$ bitbake python -c create_manifest
This task runs a script on native python on our HOST system, and since
the python and python-native packages come from the same source, we can
use it to know the dependencies of each module as if we were doing it
on an image, this script is called create_manifest.py and in a very
simplistic way it does the following:
1. Reads the JSON manifest file and creates a dictionary data structure
with all of our python packages, their FILES, RDEPENDS and SUMMARY.
2. Loops through all of them and runs every module listed on them
asynchronously, determining every dependency that they have.
3. These module dependencies are then handled, to be able to know which
packages contain those files and which should RDEPEND on one another.
4. The data structure that comes out of this, is then used to create a
new manifest file which is automatically copied onto the user's python
directory replacing the old one.
Create_manifest script features:
- Handles modules which dont exist anymore (new release for example).
- Handles modules that are builtin.
- Deals with modules which were not compiled (e.g. bsddb or ossaudiodev)
- Deals with packages which include folders.
- Deals with packages which include FILES with a wildcard.
- The manifest can be constructed on a multilib environment as well.
- This method works for both python modules and shared libraries used
by python.
How to add a new package:
- If a user wants to add a new package all that has to be done is
modify the python2-manifest.json file, and add the required file(s)
to the FILES list, the script should handle all the rest.
Real example:
We want to add a web browser package, including the file webbrowser.py
which at the moment is on python-misc.
"webbrowser": {
"files": ["${libdir}/python2.7/lib-dynload/webbrowser.py"],
"rdepends": [],
"summary": "Python Web Browser support"}
Run bitbake python -c create_manifest and the resulting manifest
should be completed after a few seconds, showing something like:
"webbrowser": {
"files": ["${libdir}/python2.7/webbrowser.py"],
"rdepends": ["core","fcntl","io","pickle","shell","subprocess"],
"summary": "Python Web Browser support"}
Known errors/issues:
- Some special packages are handled differently: core, misc,
modules,dev, staticdev.
All these should be handled manually, because they either include
binaries, static libraries, include files, etc. (something that we
cant import).
Specifically static libraries are not not supported by this method
and have to be handled by the user.
- The change should be transparent to the user, other than the fact
that now we CANT build python-foo (it was pretty dumb anyway, since
what building python-foo actually did was building the whole python
package anyway), but doing IMAGE_INSTALL_append = " python-foo"
would create an image with the requested package with no issues.
[YOCTO #11510] [YOCTO #11694] [YOCTO #11695]
(From OE-Core rev: 6959e2e4dba5bbfa6ffd49c44e738cc1c38bc280)
Signed-off-by: Alejandro Hernandez <alejandro.hernandez@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Add it to handle recipe-depends.dot and task-depends.dot. E.g.:
* Print why rpm is built
$ oe-depends-dot -k rpm --why/-w recipe-depends.dot
Because: core-image-sato libdnf libsolv dnf
* Print bzip2-native's depends
$ oe-depends-dot -k bzip2-native --depends/-d recipe-depends.dot
Depends: automake-native gnu-config-native libtool-native quilt-native autoconf-native
* Remove duplicated dependencies to reduce the size of the dot files.
For example, A->B, B->C, A->C, then A->C can be removed. The dot files are too
big, we nearly couldn't use 'dot -T' to generate pictcures for target recipes,
remove the duplicated dependencies makes is it possible.
$ bitbake core-image-sato -g
$ oe-depends-dot -r recipe-depends.dot
Saving reduced dot file to recipe-depends-reduced.dot
$ du -sh recipe-depends*.dot
608K recipe-depends.dot
32K recipe-depends-reduced.dot
It has been recuded from 608K to 32K, now we can generate a picture,
otherwise, it is too big:
$ dot -Tpng recipe-depends-reduced.dot -O
It also can handle task-depends.dot.
(From OE-Core rev: 7dc7860691304d63e7ad728d2180474906fe0a5c)
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This script was unused since yocto-bsp tool had been removed.
(From meta-yocto rev: 594ced59dc80c11d573ae4a16e1aff910a8d9300)
Signed-off-by: Yi Zhao <yi.zhao@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Colour value removes in red and additions in green, making it easier to scan the
output for relevant changes.
This adds a --colour option to specify whether colouring should be on, off, or
detected. The default is detected, and depends on whether stdout is a TTY (same
behaviour as git).
(From OE-Core rev: 4208f1546c92f069e432d1865269ce539db8cea7)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Under some conditions, ioctl FIGETBSZ can't return real value.
We can try to use fallback via os.stat() to get block size.
Source of patch:
17365f4fe9
(From OE-Core rev: d8f7cf2d38934c248be91101236f7537d0d31ea7)
Signed-off-by: Dogukan Ergun <dogukan.ergun@gmail.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When we run wic within eSDK:
$ wic create mkefidisk -e core-image-minimal
ERROR: BUILDDIR not found, exiting. (Did you forget to source oe-init-build-env?)
In order to figure out variable values, one must have sourced
the OE build environment setup script. However, when we are in
within the eSDK environment which isn't initialised like the
normal OE build environment, we can't use wic utility with eSDK.
Reference:
https://www.yoctoproject.org/docs/latest/mega-manual/mega-manual.html#wic-requirements
While wic ought to be fixed to be able to run without bitbake
& native tools [YOCTO #11281], but this is a workaround to set
BUILDDIR in the environment so that bitbake environment is setup
for wic to build its required native tools.
(From OE-Core rev: 03fa13a269d2887cc5d13fd474fb39a2be037f2c)
Signed-off-by: Chang Rebecca Swee Fun <rebecca.swee.fun.chang@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
wic modules in scripts/lib/ are needed for wic to work, but path to
the python module is not exported in eSDK environment and we were
using an absolutized path of wic script within the sysroots.
We now changed to use real script path instead, where the wic modules
are located. This will also resolved the tracebacks found when running
wic from within the eSDK environment.
Traceback (most recent call last):
File "/tmp/deploy/sdk/poky_sdk/sysroots/x86_64-pokysdk-linux/usr/bin/wic", line 58, in <module>
from wic import WicError
ImportError: No module named 'wic'
(From OE-Core rev: dcea30b885797ece3439cf1201795a975628d664)
Signed-off-by: Chang Rebecca Swee Fun <rebecca.swee.fun.chang@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
wic needs a set of tools to be available from sysroots.
wic will find bitbake executable within the environment,
and wic was unable to locate bitbake executable within eSDK
because it wasn't setup with the OE build environment script.
Hence, we need to add bitbake file path into the environment
PATH for wic to be able to discover it and import bb modules.
(From OE-Core rev: 89df0d31c9dd22ceba4c95a2a56ca78e58d871a8)
Signed-off-by: Chang Rebecca Swee Fun <rebecca.swee.fun.chang@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Use the scriptpath module in order to standardize the adding of
bitbake and meta/lib path to sys.path.
(From OE-Core rev: 8aba1fd023ce3c6767bf42b9faf9ec14fd7c4d02)
Signed-off-by: Chang Rebecca Swee Fun <rebecca.swee.fun.chang@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
On pre 4.15 host kernels, an APIC window emulation bug can cause qemu
to hang. On 64 bit we can use the x2apic, for 32 bit, we just have to
disable the other timer sources and rely on kvm-clock.
[YOCTO #12301]
(From OE-Core rev: 82e67b82ea8e12aa0b7b9db1d84fec0436dec71b)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
In case of 'new_rootfs' the psuedo directory is not copied. Thus
PSEUDO_LOCALSTATEDIR should still point to the dsa
'native_sysroot'/../pseudo. Otherwise PSEUDO_LOCALSTATEDIR points to a not
existing director ('new_rootfs'/../pseudo) and UID and GUID attributes are not
applied to files of the image.
(From OE-Core rev: 19642e2d6e015072e4a413f4f57aee65df757cb9)
Signed-off-by: Adrian Fiergolski <adrian.fiergolski@cern.ch>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
First, allow for wic to be given a filesystem UUID to be used when
creating a filesystem. When not provided, wic will generate the UUID to
be used. Next, when --use-uuid is passed, we update the fstab to mount
things via UUID (and if not found, then use PARTUUID) as UUID is more
portable.
(From OE-Core rev: 9256b8799495634ee8aee5d16ff71bd6e6e25ed4)
Signed-off-by: Tom Rini <trini@konsulko.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
First, we support squashfs as root, so mention that. Second, the btrfs
rootfs creation function had a copy/paste of the previous function
comment, remove the irrelevant line.
(From OE-Core rev: 7cdd4034b3e6ff4e13d491dfba24906afe495e2d)
Signed-off-by: Tom Rini <trini@konsulko.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The SquashFS filesystem does not support UUIDs so make this combination
be an error.
(From OE-Core rev: 2fbdcf4e59c835af0f4041bc34243decb42321ef)
Signed-off-by: Tom Rini <trini@konsulko.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Specifically, 'devtool upgrade' will now do these things:
1) determine if any of the license checksums need updating; if so,
write the new checksums into the LIC_FILES_CHKSUM value in the recipe
that is written to the workspace;
2) print a notice to the standard output:
NOTE: New recipe is /home/ak/development/poky/build/workspace/recipes/puzzles/puzzles_git.bb
NOTE: License checksums have been updated in the new recipe; please refer to it for the difference between the old and the new license texts.
3) and the cool part: devtool will create a diff of the old and new licenses,
and write the diff into the workspace recipe as a comment, like this:
======
FIXME: the LIC_FILES_CHKSUM values have been updated by 'devtool upgrade'.
The following is the difference between the old and the new license text.
Please update the LICENSE value if needed, and summarize the changes in
the commit message via 'License-checksum-change:' tag.
(example: 'License-checksum-change: copyright years updated.')
The changes:
--- LICENCE
+++ LICENCE
@@ -1,8 +1,9 @@
This software is copyright (c) 2004-2014 Simon Tatham.
Portions copyright Richard Boulton, James Harvey, Mike Pinna, Jonas
-Klker, Dariusz Olszewski, Michael Schierl, Lambros Lambrou, Bernd
-Schmidt, Steffen Bauer, Lennard Sprong and Rogier Goossens.
+Kölker, Dariusz Olszewski, Michael Schierl, Lambros Lambrou, Bernd
+Schmidt, Steffen Bauer, Lennard Sprong, Rogier Goossens and Michael
+Quevillon.
Permission is hereby granted, free of charge, to any person
obtaining a copy of this software and associated documentation files
======
(From OE-Core rev: ccb37f9e81eb78ed0eb2a238d7c3e196db9b2f72)
Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Specifically, 'devtool upgrade' will use the latest upstream release if available
or latest commit if upstream never makes releases.
(From OE-Core rev: 45b4242b105ad36e94ae15a96d588a58b917b8e8)
Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This command queries the upstream server for what the latest release is and prints
the output; it is a much neater way to find out these things than fumbling with distrodata,
'bitbake -c checkpkg' and awkward to read csv output in a file.
Examples:
python3 (tarballs):
NOTE: Current version: 3.5.3
NOTE: Latest version: 3.6.3
rpm (git):
NOTE: Current version: 4.13.90
NOTE: Latest version: 4.14.0
NOTE: Latest version's commit: da3720f62e57648fb1dc2a632744d38866139971
puzzles (git without version tags):
NOTE: Latest commit: ee8ea9b9785964694cb2b3ad77c3fb2460f49510
(From OE-Core rev: e8f5b5cc25ce7a9882f21473cefc47edcebf77d4)
Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If you specify 'tag=' for a git URL and passed to recipetool create, you
will get into Bitbake expansion error shown below:
----- snip -----
$ devtool add --version 2.4.2 mbedtls "git://github.com/ARMmbed/mbedtls;tag=mbedtls-2.4.2"
...
bb.data_smart.ExpansionError: Failure expanding variable SRCPV, expression was ${@bb.fetch2.get_srcrev(d)} which triggered exception FetchError: Fetcher failure: Conflicting revisions (abeccb9dbd7e19ae91ac50e1edd3803111c5f9b6 from SRCREV and mbedtls-2.4.2 from the url) found, please specify one valid value
----- snip -----
Assuming the tag is valid, we should get the tag commit hash and
drop the usage of 'tag=' from SRC_URI. By using a commit hash
corresponding to the tag will prevent bitbake from accessing
remote repository in order to expand SRCPV.
(From OE-Core rev: 53f8effa3eb07dc7035ff9933e7918318f242579)
Signed-off-by: Chang Rebecca Swee Fun <rebecca.swee.fun.chang@intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The generators create python-*-manifest.inc files with
lines over 2500 characters long which breaks sending
patches via git send-email (because of smtp limitation).
This patchset formats all the long lines into multiple lines.
(From OE-Core rev: 3a1900a5691466a04b24907067f43117b318ca7e)
Signed-off-by: Tim Orling <timothy.t.orling@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The '--label' argument should work for '--source rawcopy' as it does for
'--source rootfs', so add a method in RawCopyPlugin to update the label
on the temporary filesystem images.
(From OE-Core rev: 303d6ca5ae986acd2e633b0dc5e386ee7771f8ab)
Signed-off-by: Martin Hundebøll <mnhu@prevas.dk>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Update the runqemu script to allow the user to specify a device tree
to boot when calling runqemu.
This involves creating a seperate check_dtb() function incase the user
has specified 'none' for the kernel but still wants a device tree.
(From OE-Core rev: 867ac1370b294bfd1ee31f94abb63688f77081a1)
Signed-off-by: Alistair Francis <alistair.francis@xilinx.com>
Reviewed-by: Ben Levinsky <ben.levinsky@xilinx.com>
Cc: Ben Levinsky <ben.levinsky@xilinx.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Update the runqemu script to allow the user to specify a Kernel to boot
when calling runqemu.
(From OE-Core rev: eaf2793a98cb27d82561da0f8993f2b4b304ecc2)
Signed-off-by: Alistair Francis <alistair.francis@xilinx.com>
Cc: Ben Levinsky <ben.levinsky@xilinx.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Removed the -m option since this script now searches through all
recipes in the configuration. Also removed dead code, which includes
the functions recipe_bbvars() and collect_bbvars().
(From OE-Core rev: dac6515fcd23ea9cde5308c1d08a7a928efbb4d6)
Signed-off-by: Amanda Brindle <amanda.r.brindle@intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This makes debug easier.
(From OE-Core rev: a453639e19fb2a9f9fb63fddd0b3ee26c0116d91)
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Similarly to handling "../", handle "." to resovle to the qemuconf
file's current directory.
(From OE-Core rev: 33418ed064fe9cff5b4803f09135a81d9170c189)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If a variable starts with "../", its likely its a path and we want to
set it to an absolute path relative to the qemuconf file.
This means we don't have to use bitbake as often to figure out variables.
(From OE-Core rev: dfc7940900d798aa47716288338107e1d46a3972)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The regexp in the script misses some tap devices, e.g. we see output like:
runqemu - INFO - Acquiring lockfile /tmp/qemu-tap-locks/tap25.lock failed: [Errno 11] Resource temporarily unavailable
runqemu - INFO - Acquiring lockfile /tmp/qemu-tap-locks/tap26.lock failed: [Errno 11] Resource temporarily unavailable
runqemu - INFO - Acquiring lockfile /tmp/qemu-tap-locks/tap27.lock failed: [Errno 11] Resource temporarily unavailable
runqemu - INFO - Acquiring lockfile /tmp/qemu-tap-locks/tap28.lock failed: [Errno 11] Resource temporarily unavailable
runqemu - INFO - Acquiring lockfile /tmp/qemu-tap-locks/tap40.lock failed: [Errno 11] Resource temporarily unavailable
runqemu - INFO - Acquiring lockfile /tmp/qemu-tap-locks/tap41.lock failed: [Errno 11] Resource temporarily unavailable
What happened to tap29 to tap39?
The issue is was we were missing devices with '0' in the number,
like "10:" and so on in the output from "ip link".
(From OE-Core rev: 6447697a48e3b693ee38806bc2ba07c2a65c2bc8)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If a setup dict in a python setup.py file pulled in the contents of
another dict (e.g. **otherdict), then we got an error when mapping
the keys because the key is None in that case. Skip those keys to avoid
the error (we pick up the values directly in any case).
A quick reproducer for this issue:
recipetool create https://files.pythonhosted.org/packages/source/p/pyqtgraph/pyqtgraph-0.10.0.tar.gz
(From OE-Core rev: ae62a9953e219df5147ed4a5ae3f4163d51cff28)
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>
If you have a recipe that uses overrides to conditionally extend
SRC_URI to add additional patches, then you will often need to update
those patches if you're making other changes to the source tree (for
example if you're upgrading the underlying source). Make this possible
with devtool by creating devtool-override-* branches for each override
that conditionally appends/prepends SRC_URI, and have devtool
update-recipe / finish check each branch out in turn and update the
corresponding patches.
A current example of a recipe that does this is the quota recipe - it
applies an additional patch if musl is the selected C library (i.e.
libc-musl is in OVERRIDES).
Note that use of this functionality does require some care - in
particular, updates to patches that appear on the main branch (named
"devtool" by default) should be made there and not only on one of the
specific devtool-override-* branches that are created for each override.
The recommended procedure is to make the changes you want to make to the
main branch first, then check out and rebase each devtool-override-*
branch, testing each one by activating the corresponding configuration,
and then finally run devtool finish.
Fixes [YOCTO #11516].
(From OE-Core rev: aa87603d1ffd695027847f4df75c0406cf4e14d8)
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>
If you're not sure what changes devtool finish is going to make, or
you're not sure you're finished with your modifications, it is useful to
be able to see what devtool finish is going to do beforehand, so add
a -N/--dry-run option to make that possible.
(It's also very useful for debugging devtool finish itself.)
(From OE-Core rev: 05f2d5d2ce00c53825ccea5cd9c2262f9d27a638)
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>
If a file is going to be effectively removed from the destination by
devtool finish, we should report that rather than just reporting that
we're removing files from the workspace. This is a little tricky because
the way we actually operate when finishing is to:
(1) remove all original files (as recorded by devtool upgrade, if that
was used)
(2) as part of updating the recipe file, remove the files from next to
the new recipe (i.e. in the workspace for an upgrade, real recipe
otherwise) corresponding to commits not in the git tree
(3) copy over remaining files from the workspace to the destination
To report the files removed with respect to what was originally there,
we need to swap steps 1 and 2 so we can see what no longer exists after
the deletion, and suppress the reporting currently done in step 2 -
however, we still want to report removal in step 2 for the non-upgrade
case, so the latter is conditional.
(From OE-Core rev: db1d663507509cac9d97d7c96ac8590478767ba2)
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>
If the files that the devtool-source class is supposed to create in the
source tree aren't found in the temporary directory then we know that
the class hasn't worked properly - say that explicitly.
(From OE-Core rev: 4621152509c037532b133e5e6d5b73bda7ddb602)
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>
* Only log one warning message instead of one per line
* Be a bit more verbose
* "if list" is more pythonic than "if len(list)"
(From OE-Core rev: 2d11e9e6e73648c1cb514c0c10111c7886acae78)
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>
If the directory where the source code extracts to changes (for
example, when upgrading iucode-tool from 1.5 to 2.1.1, the subdirectory
in the tarball changed from "iucode_tool-${PV}" to "iucode-tool-${PV}")
then handle this automatically. Also handle when it changes to match the
default S value (i.e. "${WORKDIR}/${BP}") in which case we just drop
setting S in the recipe.
Fixes [YOCTO #10939].
(From OE-Core rev: d29881a652bf03627d257a1eac5f02ec17315b8b)
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>
Give the user a little more insight into what's being done.
(From OE-Core rev: 9cf2089bd22b9fc4eb0eec8d4924e44519412dad)
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>
github archive URLs are not guaranteed to be stable [1] and thus we
should show a warning if a user specifies one to recipetool create (or
devtool add).
[1] http://lists.openembedded.org/pipermail/openembedded-core/2017-September/142519.html
(From OE-Core rev: 7e84a777aa924a237b4e604120ebf8a4b3ba53b2)
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>
I noticed that using bitbake-layers add-layer followed by a devtool
command resulted in bitbake re-parsing all of the recipes, which is
annoying. Upon closer inspection I could see that devtool was moving the
workspace layer path to the end of BBLAYERS if it happened to be
somewhere in the middle - there's no need for it to be doing this. This
occurred because we were passing the current workspace path to remove
and the "new" path to add even if the path is not being changed, and I
think earlier versions of bb.utils.edit_bblayers_conf() didn't move the
existing entry under these circumstances as it clearly does now. Fix it
so we only pass the path to be removed if we're actually changing the
path.
(From OE-Core rev: 284426dbad91a3c52eaf7da5c58fe8a2c2dfb826)
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>
This looks like some debug printing that was left in by accident.
(From OE-Core rev: b0bfa1b1f4377270af9e7f19949cc1781a4e3b9d)
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>
devtool upgrade did not properly handle setting SRC_URI checksums for
recipes that use named SRC_URI entries and also use those names in the
SRC_URI checksums. A further complication was where the name contained
an expression that changed with the version e.g. ${PV} (probably quite
rare, but the dnsmasq recipe in meta-networking is currently one such
recipe.) All of these are now handled properly.
Additionally, drop the _get_checksums() function that wasn't being
called from anywhere in the code.
Note that this now turns nowrap_vars in recipeutils.py to be a list of
regexes, hence things such as [ and ] need to be appropriately escaped.
(From OE-Core rev: c914a5e1ad6d96e316746222e5d42f2ba9110060)
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>
devtool finish will check if the destination layer is part of
bblayers.conf so that we avoid the user getting confused about the
recipe vanishing from their configuration if it isn't. devtool finish
also accepts a path underneath a layer so that you have a bit
more control over where it ends up. However if you used a path
underneath a layer then it wasn't converting this to the base of the
layer before checking it against BBLAYERS, thus the warning was being
shown erroneously in that case.
(From OE-Core rev: ab1b8d55e551fea3e8656aab7a786d1bfec62d0f)
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>
If the git repository for a recipe in the workspace has uncommitted
changes in it then it's possible that the user has forgotten to commit
something, so check and exit if there are any. Provide a -f/--force
option to continue in the case where the uncommitted changes aren't
needed.
Separately, if the repository is in the middle of a rebase or git am /
apply then error out (without the opportunity to force) since the user
really needs to sort this out before finishing.
(From OE-Core rev: bfebd18982c0c82ef2da63ec8f22175c93b2e308)
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>
If S points to a subdirectory of the source rather than the "base" of
the source tree then print that rather than the subdirectory path when
telling the user they need to remove the source tree, since that is the
directory that they will need to remove.
(From OE-Core rev: 9e8808099046478e98c6cf1903dc6787d69132fc)
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>
After some reconsideration I think it's a bit annoying for users to be
forced to use an option to work with recipes where the file isn't in the
workspace, so let's just have these commands check the workspace first
for the recipe, and if it isn't there then load the cache and get it
that way.
(From OE-Core rev: 46683c61069a386658676a79d797062404bf1140)
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>
* Show a warning in devtool upgrade if the version is less than the
current version suggesting that the user may need to bump PE in the
recipe
* Show a warning in devtool add and devtool upgrade if the version looks
like a pre-release version suggesting using a version number that
won't mess up the progression when you come to upgrade to the final
release version.
(From OE-Core rev: 92c4d9be9ed365c449ea1ac5a18ddb15e4a36b2d)
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>
If S points to a subdirectory of the source rather than the "base" of
the source tree then we weren't handling the oe-local-files directory
properly - it got extracted to the base of the tree but devtool
update-recipe and devtool finish assumed it would be under S which would
be the subdirectory, thus it would be missing and devtool would assume
the files had been deleted and remove them from the recipe. Record the
base of the source tree in the bbappend and read it into the in-memory
workspace so we can use that to find out where oe-local-files should be
found.
(From OE-Core rev: 30d2ea67b2c4727e23d06a35745b1afa64b130cc)
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>
When devtool upgrade is upgrading to a new version where the source is
fetched as an archive (e.g. a tarball), we create a single commit in the
git repository that is the upgrade from the old version to the new. We
do this by extracting the old source, committing it, deleting all files,
copying in the new files, running git add on each new/changed/deleted
file, and then committing the result. When a lot of files have changed
in an upgrade (such as QEMU 2.8.1.1 -> 2.10.0) the penultimate step of
running git add it can take quite a long time; in order to reduce this
and show some feedback to the user, run git add with batches of 100
files at once and also show a progress bar. In a local test with the
aforementioned QEMU upgrade it took the time down from over 7 minutes
down to about 13 seconds.
Fixes [YOCTO #11948].
(From OE-Core rev: 8b184f6c874b60324ee107af53853687173d3434)
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>
With versions of git older than 2.0, "git add" on a deleted file (i.e.
in this case a file that was removed between versions) will not add the
delete to be committed by default, with the result that the rebase of
patches on top of the new branch will fail. We need to use the -A
option in order to force that for older git versions.
(From OE-Core rev: c7f4c9f050c11c0de7fcf5badcc19a8fbc6428cf)
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>
It appears that when fixing the signature unlocking in OE-Core commit
4e9a0be32fc30fb87d65da7cd1a4015c99533aff I swapped the parameters here
and did not test it within the eSDK (it does nothing outside of the
eSDK) resulting in a TypeError when devtool upgrade was used in the
eSDK. Swap the parameters around to the correct ordering.
Fixes [YOCTO #12285].
(From OE-Core rev: 05e2c4ada7083f40866846a21fe76c852f1dfefe)
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>
If the source tree happens to contain a kernel module as an example, a
test or under a "contrib" directory then we shouldn't be picking it up
and making the determination that the entire thing is a kernel module.
An example that triggered this is zstd, which ships a kernel module
under contrib/linux-kernel:
https://github.com/facebook/zstd
(From OE-Core rev: c2b3154158d4bb0855daa56477393341139d4cf9)
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>
We shouldn't be passing a relative path to the plugins if that's what's
been specified on the recipetool command line.
(From OE-Core rev: 949067384c5166058ebc76f931cc492dad1db645)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Add images as separate MIME objects instead of directly embedding images
in the html (as base64 encoded pngs). This makes the emails better
suited for certain email servers/clients.
(From OE-Core rev: 6b61126c386a0a7334cdf475d349b830c436ed82)
Signed-off-by: Markus Lehtonen <markus.lehtonen@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
With systemd, the mounting of the swap partition is handled via systemd
and will mount it, regardless of if PARTUUID is parsed or not. systemd
has a runtime dependency on util-linux-mount so PARTUUID for regular
mount points will be handled correctly. Make all partitions that we add
to the image make use of UUIDs for maximum portability.
(From OE-Core rev: 497467262d501b94061338b4ce826c6f2f9b97b4)
Signed-off-by: Tom Rini <trini@konsulko.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When we have been told to use the UUID we should also update the fstab
to make use of PARTUUID instead of hard-coding the device in question.
This will make the resulting image much more portable.
(From OE-Core rev: e7443e7cf876d9bbe326033ac5eee0b98ce5d37f)
Signed-off-by: Tom Rini <trini@konsulko.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Use tinfoil to collect all variable names globally and in each recipe.
No longer show the count of variables if they are undocumented.
Fixes [YOCTO #2086]
(From OE-Core rev: b947de583964020b488cb1c382877624e96d4319)
Signed-off-by: Amanda Brindle <amanda.r.brindle@intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The WIC's 'part' can now give a name for GPT partition in WKS file.
It's similar to '--label', but is naming partintions instead file systems.
It's required by some bootloaders to partitions have specified names.
(From OE-Core rev: 9b60e3466ed7cff0cea10815851eb1304002eb52)
Signed-off-by: Artur Mądrzak <artur@madrzak.eu>
Signed-off-by: Nicolas Dechesne <nicolas.dechesne@linaro.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
vm_drive variable is malformed when the drive type is an ide device.
(From OE-Core rev: 88d7b17871fe8340ab7fd5c901d3a535ae098c3e)
Signed-off-by: Thomas Perrot <thomas.perrot@tupi.fr>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
With the removal of yocto-bsp and yocto-kernel there are no longer any users
of this library, therefore delete it.
(From meta-yocto rev: 0d44e59bfaa95162cf2133df1d08f6419314bb8e)
Signed-off-by: Joshua Lock <joshua.g.lock@intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
yocto-kernel is not actively maintained and requires active feature
development to make it a useful and compelling tool.
(From meta-yocto rev: fae757e972c7df9adba4b012784c0b161e54eb82)
Signed-off-by: Joshua Lock <joshua.g.lock@intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The bitake-layers tool in bitbake is much more featurful, widely used and
better maintained.
(From meta-yocto rev: 803f6256fde4a7d1d4ef1f365b6f10252e99674e)
Signed-off-by: Joshua Lock <joshua.g.lock@intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The yocto-bsp tool is not actively maintained and requires active
feature development to make it a useful and compelling tool.
(From meta-yocto rev: f659eefcb0914acabe453991711b3a64a87ef9c1)
Signed-off-by: Joshua Lock <joshua.g.lock@intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
mtools already provides a suite of msdos utilities, switch to this
one also. This could allow for future changes to reduce wic's
dependecies.
(From OE-Core rev: 13851100b81ce901069ef167d6b9b0faedb3f466)
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>
This fixes the issue that if you don't have mtools installed on the host
thus causing host contamination, that the correct binaries would be selected
from the native sysroot.
[YOCTO #12173]
(From OE-Core rev: dca43c557449d3765fec9f8d159d5c9e4ea8b0cb)
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>
The intent of the env setup scripts is to set BBPATH to point at the
build directory. This means if the user changes directory, bitbake can
still find the original build directory. The default bblayers.conf files
reset BBPATH to the correct components so this is safe and restores the
behaviour the script was intended to have.
[YOCTO #12163]
(From OE-Core rev: 82eeb934997c9eaa6443079dfb649a89872a222c)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If SRCREV contains a variable reference, any devtool command that
would try to update it would fail. E.g., if SRCREV = "R${PV}", then
devtool finish without having committed any changes would fail with:
oe.patch.CmdError: Command Error: 'sh -c 'git format-patch R${PV} -o
/tmp/oepatchb_doareb -- .'' exited with 0 Output:
fatal: bad revision 'R'
(From OE-Core rev: 094499c819722ad698ccb64ec65dd439b211c31c)
Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Some fields are multiline values which have been escaped, so add an option to
unescape the \n and \t.
(From OE-Core rev: 4165ec0057c6bbb24de681572034262351d9b34f)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Create an option to wic doesn't change fstab file, the final
fstab file will be same that in rootfs and wic doesn't update
file, e.g adding a new mount point.
Users can control the fstab file content in base-files recipe.
This is useful if you want to only create an partition but not
add fstab mount point or add new mount point using label e.g:
LABEL=recovery /recovery auto defaults 0 1
(From OE-Core rev: 00420ec42140c1b752132bda190dede85756d157)
Signed-off-by: Fabio Berton <fabio.berton@ossystems.com.br>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Search made with the following regex: getVar ?\((.*), True\).
(From OE-Core rev: b848c3cb495905605283c57c79f2ed8ca17758db)
Signed-off-by: Ming Liu <liu.ming50@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
It can be useful to have multiple partitions with '--source bootimg-partition'
but different content.
E.g. for TI AM335x, one boot partition can contain an first stage
bootloader ("MLO"), while the real bootloader and kernel plus devicetree
are in another one.
Patch allows to specify multiple IMAGE_BOOT_FILES with optional "_label-XXX"
or "_uuid-XXX" overrides.
E.g. with this patch, a .wks file with
| part --source bootimg-partition ... --label=mlo --active
| part --source bootimg-partition ... --label=boot0
| part --source bootimg-partition ... --label=boot1
and a recipe with
| IMAGE_BOOT_FILES_label-mlo = "\
| MLO-${MACHINE}.img;MLO \
| "
|
| IMAGE_BOOT_FILES_label-boot0 = "\
| u-boot-${MACHINE}.img;u-boot.img \
| zImage \
| "
|
| IMAGE_BOOT_FILES_label-boot1 = "${IMAGE_BOOT_FILES_label-boot0}"
|
| WICVARS += " \
| IMAGE_BOOT_FILES_label-mlo \
| IMAGE_BOOT_FILES_label-boot0 \
| IMAGE_BOOT_FILES_label-boot1 \
| "
is possible. It will create one partition with the MLO and two redundant
ones with the uboot + kernel.
(From OE-Core rev: 8c1dec627e9735260516fe8f0b2bfdb0ee70172b)
Signed-off-by: Enrico Scholz <enrico.scholz@ensc.de>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
"Yocto Project Compatible" [1] is a programme which requires you meet
specific criteria including going through an application process - it is
not sufficient simply to run the script we have created here and have it
produce no warnings/errors. To avoid people being confused by the fact
that this script uses the term "compatible" or variations thereof,
substitute usage of that word with "check" instead. The functionality of
the script is unchanged.
[1] https://www.yoctoproject.org/ecosystem/yocto-project-branding-program
(From OE-Core rev: 2a6126a115f10750ea89f95629d3699ad41c5665)
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>
If buildstats are available (for a certain measurement), show recipe
version changes between the two builds that are being compared. The
information shown includes new and dropped recipes as well as changes in
recipe version, revision or epoch.
[YOCTO #11382]
(From OE-Core rev: 46eb839b51bb1466a9feeb09c9c437d6d45576cc)
Signed-off-by: Markus Lehtonen <markus.lehtonen@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
More refactoring of buildstats-diff script. Move recipe version
comparison functionality to scripts/lib/buildstats.py. This patch also
compasses some wording changes, i.e. changing 'package' to 'recipe'.
[YOCTO #11382]
(From OE-Core rev: 2f8942d6830258fcbe1925f12ba1516def32d132)
Signed-off-by: Markus Lehtonen <markus.lehtonen@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Utilize buildstats, if available, and show a summary of the resource
usage of bitbake tasks in the html report. The details provided are:
- total number of tasks
- top 5 resource-hungry tasks (cputime)
- top 5 increase in resource usage (cputime)
- top 5 decrease in resource usage (cputime)
[YOCTO #11381]
(From OE-Core rev: ddd9443cb2432af2c15b358bfda708393fa3c417)
Signed-off-by: Markus Lehtonen <markus.lehtonen@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Move over code from buildstats-diff to new scripts/lib/buildstats.py
module in order to share code related to buildstats processing. Also,
refactor the code, introducing new classes to make the code readable,
maintainable and easier to debug.
[YOCTO #11381]
(From OE-Core rev: 8a2cd9afc95919737d8e75234e78bbc52e1494a1)
Signed-off-by: Markus Lehtonen <markus.lehtonen@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Fix some problems in the html syntax of the generated report:
- prevent empty rows in the summary table
- add one missing column in the results table
(From OE-Core rev: 10883bb49ad2f5309883fd352cf320b2e1648615)
Signed-off-by: Markus Lehtonen <markus.lehtonen@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Some leftover from an early prototype.
(From OE-Core rev: a28284fc1bbaa18162f65eee0ae2e94d28091b2f)
Signed-off-by: Markus Lehtonen <markus.lehtonen@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Makes it possible to list test results for certain host only, instead of
always listing all results from all hosts.
(From OE-Core rev: 3c07f1f05440234243c570ebfb42dcda2f455a3d)
Signed-off-by: Markus Lehtonen <markus.lehtonen@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Don't crash if 'left' revision is older than the range of commits
specified with '--history-length'. In this case the 'left' revision
takes precedence.
(From OE-Core rev: cbeb1fb27329f8eba4d779d22fcad56f0fb03947)
Signed-off-by: Markus Lehtonen <markus.lehtonen@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Making the code a bit more readable.
(From OE-Core rev: 25351c7cac167b1a3e8b531e2cdf708192c6fa1f)
Signed-off-by: Markus Lehtonen <markus.lehtonen@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Fix a misbehavior when some of the buildstats are missing.
(From OE-Core rev: 2930515acb5cfdcd335a76ae36fd9f7189207aa3)
Signed-off-by: Markus Lehtonen <markus.lehtonen@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Alongside reworking the way devtool extracts source, we now need to
ensure that within the extensible SDK where task signatures are locked,
the signatures of the tasks for the recipes being worked on get unlocked
at the right time or otherwise we'll now get taskhash mismatches when
running devtool modify on a recipe that was included in the eSDK such as
the kernel (due to a separate bug). The existing mechanism for
auto-unlocking recipes was a little weak and was happening too late, so
I've reimplemented it so that:
(a) it gets triggered immediately when the recipe/append is created
(b) we avoid writing to the unlocked signatures file unnecessarily
(since it's a global configuration file) and
(c) within the eSDK configuration we whitelist SIGGEN_UNLOCKED_RECIPES
to avoid unnecessary reparses every time we perform one of the
devtool operations that does need to change this list.
Fixes [YOCTO #11883] (not the underlying cause, but this manifestation
of the issue).
(From OE-Core rev: 4e9a0be32fc30fb87d65da7cd1a4015c99533aff)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Since it was first implemented, devtool's source extraction (as used by
the devtool modify, extract and upgrade subcommands) ignored other recipe
dependencies - so for example if you ran devtool modify on a recipe that
fetches from svn or is compressed using xz then it would fail if those
dependencies hadn't been built first. Now that we can execute tasks in
the normal way (i.e. tinfoil.build_targets()) then we can rework it to
use that. This is slightly tricky in that the source extraction needs to
insert some logic in between tasks; luckily we can use a helper class
that conditionally adds prefuncs to make that possible.
Some side-effects / aspects of this change worth noting:
* Operations are a little slower because we have to go through the task
dependency graph generation and other startup processing. There's not
really any way to avoid this though.
* devtool extract didn't used to require a workspace, now it does
because it needs to create a temporary bbappend for the recipe. (As
with other commands the workspace be created on the fly if it doesn't
already exist.)
* I want any existing sysroot files and stamps to be left alone during
extraction since we are running the tasks off to the side, and
especially devtool extract should be able to be used without touching
these. However, this was hampered by the automatic removal process in
sstate.bbclass triggered by bb.event.ReachableStamps when the task
signatures change, thus I had to introduce a way to disable this
removal on a per-recipe basis (we still want it to function for any
dependencies that we aren't working on). To implement this I elected
to use a file written to tmp/sstate-control which gets deleted
automatically after reading so that there's less chance of stale files
affecting future sessions. I could have used a variable but this would
have needed to be whitelisted and I'd have to have poked its value in
using the setVariable command.
Fixes [YOCTO #11198].
(From OE-Core rev: 830dbd66992cbb9e731b48d56fddf8f220349666)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
'-' is valid and common in bitbake variables (e.g. 'FOO_pn-bar'). Accept
it and other characters when reading the .env file.
Also, allow variables to be empty.
(From OE-Core rev: e688ac8e92d2bc451d8b2d437596f630bedccd2c)
(From OE-Core rev: 2a69250abf61e51f633033ddb672e8f459191899)
Signed-off-by: Enrico Scholz <enrico.scholz@ensc.de>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
A recipe added with "devtool add" requires to be able to take precedence on recipes
previously defined with PREFERRED_PROVIDER.
By adding the parameter "--provides" to "devtool add" it is possible to specify
an element to be provided by the recipe. A devtool recipe can override a previous
PREFERRED_PROVIDER using the layer configuration file in the workspace.
E.g.
devtool add my-libgl git@git://my-libgl-repository --provides virtual/libgl
[YOCTO #10415]
(From OE-Core rev: adeea2fe6895898a5e6006e798898f0f5dabd890)
Signed-off-by: Juan M Cruz Alcaraz <juan.m.cruz.alcaraz@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If user.name or user.email haven't been set then git rebase can't really
work properly. Check that the user has set these and error out if not.
(Elsewhere we are relying on OE's git patch functionality which forces
a dummy OE value - that's OK there as it's completely under OE's control
and therefore it's OK for a dummy OE user to be the committer, but here
the rebase may require intervention so it's reasonable to have the
user's actual name and email on the operation.)
Fixes [YOCTO #11947].
(From OE-Core rev: 129a3be07e272013be2db17552c13b4d8cc2cf6e)
(From OE-Core rev: 802829f1c38d8c5eee11ba1d9ddd37cf02597f6e)
Signed-off-by: paul <paul@peggleto-mobl.ger.corp.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Optparse is deprecated since version 2.7 and won't be developed further.
Argparse should be used instead as it provides better tools for parsing
and handling arguments.
[YOCTO #9635]
(From OE-Core rev: e67b40c01fd98048035ca18595d87ae1be050ab4)
Signed-off-by: Daniela Plascencia <daniela.plascencia@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Modified wic code to run bmaptool using native Python3
from wic-tools native sysroot.
[YOCTO #11891]
(From OE-Core rev: 7fca44e03130c0860cc5df2093902773f426c774)
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>
Added ext* partitions to the description of 'wic ls',
'wic cp' and 'wic rm' commands.
(From OE-Core rev: fcff05d666e55a017f11851aa4aad6c3ba9d4ff0)
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>
Implemented removing files or directories from the ext
partition using debugfs tool.
(From OE-Core rev: be530b7c7beae6f9fc95eed245cb37066d56581e)
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>
Implemented copying files to the ext partition
using debugfs tool.
(From OE-Core rev: 1a2bc70e6f85f414e7af48489e24c09ff335486d)
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>
Implemented listing directory contents for ext file
system using debugfs tool.
(From OE-Core rev: b591ba6f4d684aef3d7666bbdc678954e3255df5)
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>
When all of the requested layers have unsatisfied dependencies, an error
can occur. Check for the condition to avoid the traceback:
Traceback (most recent call last):
File "../scripts/yocto-compat-layer.py", line 203, in <module>
ret = main()
File "../scripts/yocto-compat-layer.py", line 194, in main
if not results[layer_name].wasSuccessful():
AttributeError: 'NoneType' object has no attribute 'wasSuccessful'
(From OE-Core rev: 32c9b3d99a0c27f6736696082b9da812a8464bf8)
Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Sorted entries are easier to read.
(From OE-Core rev: d0a123ec564f6d36977e472f8bc63f9c050ee616)
Signed-off-by: Ola x Nilsson <olani@axis.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This allows the yocto-bsp script to pick the 4.12 kernel version when
creating a custom BSP.
[YOCTO #11995]
(From meta-yocto rev: 897c6121404055c4dcb2d9f43f1214d8c99480ea)
Signed-off-by: Leonardo Sandoval <leonardo.sandoval.gonzalez@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
recipetool create (and hence devtool add) and devtool upgrade use
fetch_url() which creates a dummy recipe in order to fetch source.
Previously the random part of the name was using uppercase characters,
and this triggers a QA warning after OE-Core commit
4713f8b2c4f2c74239d284adcf1e59e61aa66576, so use lowercase instead as I
really should have in the first place.
(From OE-Core rev: b48c48b00e82491d1c69e4d89a79c6242361abec)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Since OE-Core revision 9a47a6690052ef943c0d4760630ee630fb012153 the
mechanism we were using to suppress the warnings about
NPM_LOCKDOWN and NPM_SHRINKWRAP not being set on the first fetch of the
source is no longer available since we are using the normal fetch/unpack
tasks to do the job. Use the newly added noverify parameter to suppress
the warnings again.
(From OE-Core rev: cb083b6f5f6e909b7c85548bcb1a92ca34d0c18a)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If you're fetching from an SCM other than git (for example subversion or
mercurial) then we need to use a different prefix for the SRCPV in PV
instead of +git.
(From OE-Core rev: ad1200c8729f21b325d347649f9dd5e5598de93e)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The branch and tag handling code that was recently added in OE-Core revs
ecca596b75cfda2f798a0bdde75f4f774e23a95b and
3afdcbdc9a3e65bc925ec61717784ffec67d529d is specific to git, so only
apply it when we're fetching from a git URL.
(From OE-Core rev: 5d4bfe6cf788ce971a2e9419bc13492153023681)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
At the moment when fetching source from a git repository you have to
know that you can specify the revision and branch in the URL with
';rev=' and ';branch=' respectively, and you can also get thrown off by
the shell splitting on the ; character if you forget to surround the URL
in quotes. Add explicit -S/--srcrev and -B/--srcbranch options
(consistent with devtool upgrade) to make this easier for the user to
discover and use. (The rev and branch URL parameters will continue to
work, however.)
(From OE-Core rev: 2d86cac853d6daa496c0315a5cb0662ebf1165b0)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
OE-Core commit 5a16b3c804c5eca331a1c08a7ce31a54909af105 attempted to use
the same function to get the path to a recipe as the new "find-recipe"
command it implemented, except that cannot work because (a) it didn't
return anything and (b) event if it had tried, a command function can
only return an exit code and we don't want that for find-recipe if it
succeeded. Split out a separate reusable function for both commands.
(From OE-Core rev: d5191840212adbf480961ba6fc68e1ab17e5a77a)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If we're upgrading a recipe that appends additional patches for, say,
class-native, and we're just upgrading the target variant, then when we
copied the recipe into the workspace we skipped copying the additional patches
for the native variant. This caused warnings because the workspace
recipe is preferred. Look at SRC_URI for all variants when copying files
to work around this.
More work is needed to make it easier to work with recipes that use
BBCLASSEXTEND where you need to build more than one variant at once, but
this at least fixes the immediate ugliness.
(From OE-Core rev: 56bf5e93358187e31160d7893f57906bb3dc7ad7)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If your BBLAYERS has non-absolute paths in it (e.g.
"${COREBASE}/../something") then none of the paths matched in
copy_recipe_files() with the result that no files got copied and you
ended up with an error later on because the recipe file couldn't be
found at the destination. Fix this as well as adding an explicit check
to see if no files got copied - error out earlier if so.
Fixes [YOCTO #10981].
(From OE-Core rev: 3861486ad06f90c8644ebab119bbc5ddb9e693ca)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Patches that we identify as having been "deleted" (i.e. patches in
SRC_URI that no longer appear in the git tree) need to be dropped even
if we're updating in srcrev mode. This fixes the case where HEAD of the
git tree is valid upstream (i.e. no extra commits), but there are
patches left over in the recipe, e.g. when we do devtool upgrade and
then all of the commits rebased on top of the new branch get skipped.
Fixes [YOCTO #11972].
(From OE-Core rev: 350f83dc1e317aeb93539f13966caca6d894f569)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Errors like:
runqemu - ERROR - Acquiring lockfile /tmp/qemu-tap-locks/tap0.lock failed: [Errno 11] Resource temporarily unavailable
are not really fatal errors. Change these to info messages instead
so people look later in the log for the real errors.
(From OE-Core rev: fac12de72bda1e864e71538be07d6c6f6e987498)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
New devtool deploy-target option --strip which enables deploying
stripped binaries, saving some space on target.
* Copies the files of ${D} into a new directory and strips them in place
* Used oe.package.strip_execs for stripping directory
* Added devtool.conf option "strip" for changing default behavior
Config example:
[Deploy]
strip = true
[YOCTO #11227]
(From OE-Core rev: 7f10c5118793da6ded59ae6e60e796152dbd7ca3)
Signed-off-by: Tobias Hagelborn <tobiasha@axis.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Got rid of lazy evaluation of self.partitions property.
It's not needed because partitions of the source image should
be always read.
(From OE-Core rev: 1186fd8fd4a4789dc7c60feb86cc9fdd03fee7b3)
Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This command writes image to the media or another file with
the possibility to expand partitions to fill free target space.
[YOCTO #11278]
(From OE-Core rev: ac5fc0d691aad66ac01a5cde34c331c928e9e25a)
Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Added sfdisk, e2fsck, mkswap, resize2fs, mkdosfs to the
list of used tools in Disk class. They're going to be used
in 'wic write' implementation.
Added dependency to util-linux to wic-tools to ensure that
sfdisk and mkswap are available from wic-tools native sysroot.
(From OE-Core rev: 1add68e4d6150e3038609d8ce7e3cff28fe8fbb8)
Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This parameter specifies list of supported filesystems.
So far only 'fat' is supported, but 'wic write' is going
to support at least 'fat', 'ext' and 'swap'.
(From OE-Core rev: 7cffcdcfdf4f8934d212740a6d7cf136911ebdac)
Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Converted partition number to int in order to use
it as an index in the list of partitions.
(From OE-Core rev: f901f23eb05cd6b86a49ef1b6ec7efaf72f6d685)
Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Got partition type and sector sizes from the output
of 'parted print'. This info may be used in the implementation
of 'wic write' command.
(From OE-Core rev: 5c0926d8efa468177b7cb43a5f06b35058255644)
Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
So far every used tool have to have separate property and
private attribute in the Disk class. This is too verbose,
considering that there will be much more tools used.
Reimplemented getting tools paths using custom __getattr__
method. This is much more compact and readable.
(From OE-Core rev: d1a831a9870bc31e936eb480485b28f1ffc13080)
Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
OE-Core commit 1df60b09f7a60427795ec828c9c7180e4e52f98c caused a
regression in npm handling since it still expected to be able to get the
results of the license handling, but this no longer happens until after
the npm plugin is called. Thus, call the license handling function
ourselves here (which will record this as having been handled so it
doesn't get done again later).
(From OE-Core rev: 3e408aadaea85b6f192b34d37d508cbaf3cd7164)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
With "import oe" in create_npm.py you get "AttributeError: module 'oe'
has no attribute 'package'" when it tries to call
oe.package.npm_split_package_dirs().
(From OE-Core rev: 1261900aeac725e5712e0180600753a9d4c67e60)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The IDE driver in the kernel is fragile and in 4.12 is causing backtraces.
To unblock 4.12 kernel merging use the virtio CD driver instead to mount
iso images which should be faster and more stable.
(From OE-Core rev: f59e729f98ef9b506b0cfdc415567e03ec87f2a9)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This allows the end users to be able to override the entire notes
showing on the shell console. For instance, Our company uses a
external conf-notes.txt, and we run bitbake with some extra variables,
looks like: F=xxx D=xxx M=xxx bitbake <target>, so we want to show
exactly these texts on the shell console, that's why we need this
change.
(From OE-Core rev: 80bc8282df58dfeaae8f2f71ed2617d718e29f8b)
Signed-off-by: Ming Liu <peter.x.liu@external.atlascopco.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We were being a bit prescriptive in setting LICENSE and
LIC_FILES_CHKSUM. We can't always trust what's in the metadata
accompanying some source which plugins will almost always be pulling
from, however we do want to allow plugins to set the LICENSE and
LIC_FILES_CHKSUM values. Merge what we find in our license file scan
with what the plugin sends back.
Additionally, plugins can now add a "license" item to the handled list
in order to inhibit the normal LICENSE / LIC_FILES_CHKSUM handling if
they have already taken care of it completely.
Thanks to Mark Horn <mark.d.horn@intel.com> for prompting, testing and
fixing this patch.
(From OE-Core rev: 1df60b09f7a60427795ec828c9c7180e4e52f98c)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Previously if we were able to auto-determine the name from the URL, that
took precedence over any name that might be set in extravalues by a
plugin. Some plugins might be able to get a better idea of the name and
thus we should move defaulting of the name further down after the
plugins have had a chance to set it.
(From OE-Core rev: 3bb979c13463705c4db6c59034661c4cd8100756)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Takes a tar archive created by 'devtool export' and imports (untars) it
into the workspace. Currently the whole tar archive is imported, there
is no way to limit what is imported.
https://bugzilla.yoctoproject.org/show_bug.cgi?id=10510
[YOCTO #10510]
(From OE-Core rev: 2de8ba89ef10fefcc97246dfeb4b8d1e48ee8232)
Signed-off-by: Leonardo Sandoval <leonardo.sandoval.gonzalez@linux.intel.com>
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
In case the proposed md5sum to be appended to the .devtool_md5 file
is already present, do not append it.
(From OE-Core rev: f958c5cba3b0d24ca696b2b707857009c9a7b5b8)
Signed-off-by: Leonardo Sandoval <leonardo.sandoval.gonzalez@linux.intel.com>
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
By default, exports the whole workspace (all recipes) including the source code.
User can also limit what is exported with --included/--excluded flags. As
a result of this operation, a tar archive containing only workspace metadata
and its corresponding source code is created, which can be properly imported
with 'devtool import'.
https://bugzilla.yoctoproject.org/show_bug.cgi?id=10510
[YOCTO #10510]
(From OE-Core rev: f9bc3b5101b554a72298266519dbdd1497f262a6)
Signed-off-by: Leonardo Sandoval <leonardo.sandoval.gonzalez@linux.intel.com>
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When devtool upgrade is run on a recipe with revision specified
that is not on master branch, and branch isn't set by --srcbranch or -B,
then we should get the correct branch and append the branch to the URL.
If the revision was found on multiple branches, we will display error
to inform user to provide a correct branch and exit.
[YOCTO #11484]
(From OE-Core rev: 29ced7387a92aed17b7fe93b1654790a981734c1)
Signed-off-by: Chang Rebecca Swee Fun <rebecca.swee.fun.chang@intel.com>
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
During recipe creation, it seems that the automation for replacing
${PV} at the SRCURI for tag, (e.g mbed-tls-${PV}) is causing some
issue due to PV assuming it's a git source. A fix is implemented in
this patch to resolve this issue.
(From OE-Core rev: 9d3ec76c1b7dd75d904f5ff47297de0fb65b21c2)
Signed-off-by: Stanley Phoong <stanley.cheong.kwan.phoong@intel.com>
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If a git URL is passed to recipetool create with a tag=, recipetool
should handle it assuming that the tag is valid.
[YOCTO #11393]
(From OE-Core rev: 3afdcbdc9a3e65bc925ec61717784ffec67d529d)
Signed-off-by: Stanley Phoong <stanley.cheong.kwan.phoong@intel.com>
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This change is to improve the buildability of the recipe created by
recipetool and devtool.
When recipetool create is run on a git URL and a revision specified
that is not on master, and "branch=" isn't already in the URL, then
we should get the correct branch and append the branch to the URL.
If the revision was found on multiple branches and 'master' is not
in the list, we will display error to inform user to provide a
correct branch and exit.
[YOCTO #11389]
(From OE-Core rev: ecca596b75cfda2f798a0bdde75f4f774e23a95b)
Signed-off-by: Chang Rebecca Swee Fun <rebecca.swee.fun.chang@intel.com>
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When creating new recipes, we are almost certainly fetching a new
source rather that something that has already been fetched. I have
disable PREMIRRORS and MIRRORS settings in the recipe that created
by devtool while leaving an option for users to enable them manually
if needed. Since devtool already has this options, we need to ensure
that recipetool is able to handle the options passed from devtool.
(From OE-Core rev: 091cee2bdc2378a3425a4ef8558d03e6f9c021ff)
Signed-off-by: Chang Rebecca Swee Fun <rebecca.swee.fun.chang@intel.com>
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We have two variables here, srcuri and fetchuri. srcuri is what
eventually ends up in the recipe, whereas fetchuri is what we actually
pass to the fetcher when we fetch the source within recipetool -
sometimes these need to be different particularly for an upcoming patch
to handle automatically setting the branch parameter. In OE-Core
revision 9a47a6690052ef943c0d4760630ee630fb012153 I erroneously changed
the call to scriptutils.fetch_url() to pass srcuri instead of fetchuri -
this likely didn't have any ill effect, but change it back to passing
fetchuri to match the original intent.
(From OE-Core rev: b66b73bcf5ee7e4488970576fdc31dfa25b35f5e)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The author's initial intent was to use a git hook to automatically call
update-server-info, but the wrong hook type was chosen (post-update). A
post-commit one will do the job, hence allowing to drop the explicit call to
update-server-info.
(From OE-Core rev: 0a8ae997c782794b6ef32654cb245b496ab1de8e)
Signed-off-by: Andrea Galbusera <gizero@gmail.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Commit 4657bc9d165e51981e034e73e7b92552e873eef7 replaced the git pull logic with
the git fetch + git reset --hard combo, but resetting to HEAD does not really
pull in new commits from remote... Replace with resetting to the upstream branch
instead.
(From OE-Core rev: 0dcdb146f59a184419bffd4f24cdf8343a43c0ea)
Signed-off-by: Andrea Galbusera <gizero@gmail.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* If an error is logged while executing a task, we need to ensure we
exit instead of assuming everything went OK.
* If we receive CookerExit, the server is shutting down and we need to
stop waiting for events and probably exit (knotty does this). This
will occur if an exception or bb.fatal() happens during an event
handler.
This fixes a couple of issues highlighted when using devtool upgrade or
modify on a non-supported recipe with intel-iot-refkit together with
bitbake master, but I'd be very surprised if it were hard to reproduce
in other scenarios.
(From OE-Core rev: 65e644368fc9c294af96906528ee0cf30305e0a6)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Although 'test' is listed in the python module list
(https://docs.python.org/3/py-modindex.html) it is meant only to be
used 'internally' by folks developing python itself. Per the
documentation:
Note The test package is meant for internal use by Python only. It
is documented for the benefit of the core developers of Python. Any
use of this package outside of Python’s standard library is
discouraged as code mentioned here can change or be removed without
notice between releases of Python.
Per the above it is best not to include this module to discourage
folks who might not head the above warnings. Additionally this module
is one of the largest py modules going, by dropping this unneeded
module from the 'modules' package we can reduce overall image size,
something which is important for many embedded deployments.
The generator scripts as well as the manifests have thus been modified
accordingly, providing a generic mechanism to exclude modules from the
'all modules' package.
(From OE-Core rev: a5bb13a5d7d7a668ca61da6b17884e3b05b95355)
Signed-off-by: Mark Asselstine <mark.asselstine@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This should reduce the chance of generating 0xffffffff as the disk
system identifier.
(From OE-Core rev: 5619e72facbc9228d3cf8f844f198e03b536ac8c)
Signed-off-by: Jonathan Liu <net147@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The most portable way to specifiy a root device in a disk image that we
create is to use PARTUUID rather than /dev/sda2. As background, both
GPT and MBR tables provide valid UUID values for each partition and the
Linux Kernel contains the logic to parse this value. With this change
we can now boot the default disk images when used as any valid block
device that the included kernel uses. This for example means that
VirtualBox can be used to run vmdk without changes as it uses IDE for
the virtual disk controller.
Cc: Matt Porter <mporter@konsulko.com>
(From OE-Core rev: 8a58e9bb3e76a9962f1d14a8bdd3f7de675c3492)
Signed-off-by: Tom Rini <trini@konsulko.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The vmdk/vdi/qcow2 IMAGE_FSTYPEs predate wic. As such, they provide
some similar underlying functionality in order to produce a "disk" image
that in turn can be converted into different formats that various
hypervisor types work with. They do not however provide the ability for
other disk image types to be converted into these same output types.
Furthermore, they are less flexible than what wic does provide. This
drops the old style vmdk/vdi/qcow2 types and re-introduces them under
the CONVERSION_CMD framework. The equivalent of vmdk is now wic.vmdk
and so forth for the other types.
(From OE-Core rev: 929ba563f1bc7195c4981b8e139c432b2cc388ea)
Signed-off-by: Tom Rini <trini@konsulko.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Zero may be interpreted as no MBR signature present and another
partitioning program might install a new MBR signature.
(From OE-Core rev: f53b5555d6eaa171bc5882cfee807cf62576862d)
Signed-off-by: Jonathan Liu <net147@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
wic avoided adding /boot to fstab for no reason.
This exception was hardcoded in the wic code.
There is no need for this as mountpoint in .wks file is an optional
field. It can be used only if user wants to have partitions
automatically mounted on system boot.
[YOCTO #11662]
(From OE-Core rev: 2376b05512ddb8c4ec3aaf1df11071f536a76bd9)
Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Used unique suffix (line number from .wks file) for the
copied rootfs directory to avoid possible conflicts.
(From OE-Core rev: 01efc234a8caab67ed3138ab2de9bbd82ce97b44)
Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
wic gets rootfs paths from partition object property
'rootfs_dir' and shows them in final report.
rootfs plugin sets this property to the temporary path,
which causes temporary paths appearing in the report.
Changed the code to prevent storing temporary rootfs path
in part.rootfs_dir. This should fix the report.
(From OE-Core rev: 28d2d7d6f79df08431187c7debaab2a3fa516671)
Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Using relative paths can cause copyhardlinktree API to fail as
it changes current directory when working. Converted all paths
to absolute paths using os.path.realpath.
(From OE-Core rev: a1c83cebe986e211dfc31be5cbd748f53fc298df)
Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
wic updates /etc/fstab on root partition if there are
valid mount points in .wks
When wic runs from bitbake this can cause incorrect results
or even breakage of other tasks working with the same rootfs
directory in parallel with do_image_wic.
Implemented copying rootfs directory to a temporary location
using copyhardlinktree before updating fstab to avoid conflicts with
other tasks working with the same rootfs directory.
(From OE-Core rev: 92e1c7d47e695eb4ce1a863cd0f6c49dca1c2339)
Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This plugin will be removed starting 2.5 development in favour
of using 'bitbake-layers create-layer' script/plugin, offering a single
script to manage layers.
(From meta-yocto rev: 76dd79e345d8edb22fc7aefd31f2a1f150916718)
Signed-off-by: Leonardo Sandoval <leonardo.sandoval.gonzalez@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Multi-users may run qemu on the same host, all of them should be able to
create or remove lock in lockdir, so set lockdir's mode to 0o777.
Note, os.mkdir()'s mode is default to 0o777, but the current umask value is
first masked out, so use os.chmod() to set it.
(From OE-Core rev: 4a5d21dbdc88982c2c90e660811b84983eaebeb7)
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Error out ealier if the combos is invalid, e.g.:
$ runqemu tmp/deploy/images/qemux86/bzImage-qemux86.bin tmp/deploy/images/qemux86/core-image-minimal-qemux86.wic
This will fail at kernel panic, no we check and error out early. We can
add other checkings in the future.
[YOCTO #11286]
(From OE-Core rev: 8c6f253dfb4899324e91dd5d082190909e2bd25d)
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Handle them as nfs, so that cmd like the following can be boot:
$ runqemu tmp/deploy/images/qemux86/core-image-minimal-qemux86.tar.bz2
[YOCTO #11286]
(From OE-Core rev: 552093d1f60ca335d95bcfc9d6070ec551ebe6c0)
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If qbconfload (.qemuboot.conf is found) is present, we can get
DEPLOY_DIR_IMAGE from it rather than "bitbake -e".
(From OE-Core rev: 89e97033a8a27a695567c321ed0ebf17f23f8d9b)
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
And move some debug info into logger.debug(), this can make it easy to
read key messages like errors or warnings.
I checked meta/lib/oeqa/ they don't depend on these messages. And I have
run "oe-selftest -a", it doesn't break anything.
[YOCTO #10474]
(From OE-Core rev: e696425e7627edada128b40304fddc84d8d56ba7)
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Updated help contents with the description of new
wks option --mkfs-extraopts
(From OE-Core rev: 69c95f74013d0d8b199abc38ba0d6f3ff952eed3)
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>
This option specifies extra options to pass to mkfs.<fstype> utilities.
[YOCTO #11709]
(From OE-Core rev: 67b7c67edba305fbd31967baa10d27c2e603ec77)
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>
Since we have provide an option to manually enable PREMIRRORS and MIRRORS
in recipetool, we need to make sure devtool is having the same options
as devtool uses recipetool in creating new recipes.
(From OE-Core rev: 198bddeb928a318c3ad168bcb4f83b5cd9a604fb)
Signed-off-by: Chang Rebecca Swee Fun <rebecca.swee.fun.chang@intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
devtool find-recipe will prints out the path to the recipe
in a workspace.
This subcommand can also help to find recipe outside of
current workspace using "-a" or "--any-recipe" option.
This enhancement helps developer to get the recipe path
when working with devtool.
[YOCTO #11434]
(From OE-Core rev: 5a16b3c804c5eca331a1c08a7ce31a54909af105)
Signed-off-by: Chang Rebecca Swee Fun <rebecca.swee.fun.chang@intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
logger was not defined in scriptutils.py based on the
observation in python traceback.
Traceback (most recent call last):
File "/workdir/poky/scripts/devtool", line 351, in <module>
ret = main()
File "/workdir/poky/scripts/devtool", line 338, in main
ret = args.func(args, config, basepath, workspace)
File "/workdir/poky/scripts/lib/devtool/utilcmds.py", line 55, in
edit_recipe
return scriptutils.run_editor(find_recipe(args, config, basepath,
workspace))
File "/workdir/poky/scripts/lib/scriptutils.py", line 141, in
run_editor
logger.error("Execution of '%s' failed: %s" % (editor, exc))
NameError: name 'logger' is not defined
We pass in logger as parameter to run_editor() from where it has
been called (devtool/utilcmds.py and recipetool/newappend.py),
which both modules already has logger setup.
(From OE-Core rev: 21f04b61973dd9029f0e6bff5445e31cd762bf32)
Signed-off-by: Chang Rebecca Swee Fun <rebecca.swee.fun.chang@intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
devtool edit-recipe now has ugly tracebacks if executed without an
editor available. This happens in the build containers whenever no
text editor is available.
subprocess.check_call will run text editing command with recipe path
provided. It will wait for command to complete. If the return code
was zero then return, otherwise raise CalledProcessError exception.
This enhancement will suppress the traceback by catching the exception
and prompt the error messages in a proper manner shown below:
pokyuser@59c99c507238:/workdir/docker-dbg$ devtool edit-recipe ifupdown
/bin/sh: 1: vi: not found
ERROR: Execution of 'vi' failed: Command 'vi
"/workdir/docker-dbg/workspace/recipes/ifupdown/ifupdown_0.8.16.bb"'
returned non-zero exit status 127
[YOCTO #11434]
(From OE-Core rev: c536ccfd162fc8871838fa229012c562e3f8e0d9)
Signed-off-by: Chang Rebecca Swee Fun <rebecca.swee.fun.chang@intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Total number of partitions should be taken into account when calculating
real partition number for msdos partition table. The number can be
different for the 4th partition: it can be 4 if there are 4 partitions in
the table and 5 if there are more than 4 partitions in the table. In the
latter case number 4 is occupied by extended partition.
[YOCTO #11790]
(From OE-Core rev: 5689139b3cd862e2df49f6b21171f513e8a46c60)
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>
Sometimes only expect positive values from cmdline so it's better
to filter at parsing cmdline step instead of validate later.
(From OE-Core rev: 3ef5b518febd047bf90a0955fa2b9fb78ba6dde5)
Signed-off-by: Aníbal Limón <anibal.limon@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This avoids test failures like:
======================================================================
ERROR [0.946s]: test_recipetool_load_plugin (recipetool.RecipetoolTests)
INFO - ----------------------------------------------------------------------
INFO - Traceback (most recent call last):
File "/media/build1/poky/meta/lib/oeqa/core/decorator/__init__.py", line 32, in wrapped_f
return func(*args, **kwargs)
File "/media/build1/poky/meta/lib/oeqa/selftest/cases/recipetool.py", line 514, in test_recipetool_load_plugin
with open(srcfile) as fh:
FileNotFoundError: [Errno 2] No such file or directory: 'NOTE: Starting bitbake server...\n/media/build1/poky/meta-selftest/lib/recipetool/bbpath.py'
INFO - ----------------------------------------------------------------------
which comes from:
$ recipetool --quiet pluginfile
NOTE: Starting bitbake server...
/media/build1/poky/meta-selftest/lib/recipetool/bbpath.py
since there is corruption in the output despite the --quiet option. Setting
the logging up before calling tinfoil.prepare() resolves this.
(From OE-Core rev: e124eb73e6a66abbf43dffd82b834e906163614b)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This avoids test failures like:
INFO - ======================================================================
INFO - FAIL [1.755s]: test_devtool_layer_plugins (devtool.DevtoolTests)
INFO - ----------------------------------------------------------------------
INFO - Traceback (most recent call last):
File "/media/build1/poky/meta/lib/oeqa/core/decorator/__init__.py", line 32, in wrapped_f
return func(*args, **kwargs)
File "/media/build1/poky/meta/lib/oeqa/selftest/cases/devtool.py", line 1354, in test_devtool_layer_plugins
self.assertEqual(result.output, s[::-1])
AssertionError: "NOTE: Starting bitbake server...\noY senu[36 chars]rciM" != "oY senuZ s'enoynA morF tiforP oN edaM tfosorciM"
- NOTE: Starting bitbake server...
oY senuZ s'enoynA morF tiforP oN edaM tfosorciM
INFO - ----------------------------------------------------------------------
since there is corruption in the output. Setting the logging up before
calling tinfoil.prepare() resolves this.
(From OE-Core rev: 3c479fb17ae4d3e7e5f0889af0f68257ef66475c)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This avoids test failures like:
INFO - ======================================================================
INFO - FAIL [1.046s]: test_find_path (pkgdata.OePkgdataUtilTests)
INFO - ----------------------------------------------------------------------
INFO - Traceback (most recent call last):
File "/media/build1/poky/meta/lib/oeqa/core/decorator/__init__.py", line 32, in wrapped_f
return func(*args, **kwargs)
File "/media/build1/poky/meta/lib/oeqa/selftest/cases/pkgdata.py", line 50, in test_find_path
self.assertEqual(result.output, 'zlib: /lib/libz.so.1')
AssertionError: 'NOTE: Starting bitbake server...\nzlib: /lib/libz.so.1' != 'zlib: /lib/libz.so.1'
- NOTE: Starting bitbake server...
zlib: /lib/libz.so.1
INFO - ----------------------------------------------------------------------
since there is corruption in the output. Setting the logging up before
calling tinfoil.prepare() resolves this.
(From OE-Core rev: 39c1bf1feccc8dca57160a1e3cd8a50e8c30ef02)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Across devtool and recipetool we had an ugly set of code for ensuring
that we can call an npm binary, and much of that ugliness was a result
of not being able to run build tasks when tinfoil was active - if
recipetool found that npm was required and we didn't know beforehand
(e.g. we're fetching from a plain git repository as opposed to an npm://
URL where it's obvious) then it had to exit and return a special result
code, so that devtool knew it needed to build nodejs-native and then
call recipetool again. Now that we are using real build tasks to fetch
and unpack, we can drop most of this and move the code to the one place
where it's still needed (i.e. create_npm where we potentially have to
deal with node.js code in a plain source repository).
(From OE-Core rev: 8450de16ddb02d863204b411a94c6d84e0f88817)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Now that we have the ability to run the tasks in a more standard context
through tinfoil, change recipetool's fetching code to use that to fetch
files using it. This has the major advantage that any dependencies of
do_fetch and do_unpack (e.g. for subversion or npm) will be handled
automatically. This also has the beneficial side-effect of fixing a
recent regression that prevented this fetch operation from working with
memory resident bitbake.
Also fix devtool's usage of fetch_uri() at the same time so that we can
completely replace it.
Fixes [YOCTO #11710].
(From OE-Core rev: 9a47a6690052ef943c0d4760630ee630fb012153)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When dealing with package files (.rpm, .ipk etc.) we need to unpack them
ourselves to get the metadata, which is thrown away when the fetcher
unpacks them. However, since we've already fetched the file once, I'm
not sure as to why I thought I needed to fetch it again - we can just
get the local path and then unpack it directly.
(From OE-Core rev: be45e9b17e9dbc8c2594d3a939be377ab0720a7c)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If you pointed recipetool at a URL that should be a tarball e.g.
https://tls.mbed.org/download/start/mbedtls-2.4.2-apache.tgz but instead
it returns an HTML page, we try to unpack it, gzip complains but the
operation doesn't seem to fail - instead we just get back an empty
source tree. Change the checks to account for this - if the source tree
is empty, check if the downloaded file in DL_DIR looks like an HTML file
and error accordingly if it is. If it's not, error out anyway because
no source was unpacked and it should have been (otherwise we just
blindly set up EXTERNALSRC for this which is pointless).
Fixes an aspect of [YOCTO #11407].
(From OE-Core rev: 8496113b63d5a5d1f99056610c0fdb972a6200d4)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When extracting linux-yocto kernel source, we don't need to dance around
shutting down and starting up tinfoil anymore, we can just execute the
tasks as needed when needed using tinfoil's new build_targets()
function. This allows us to tidy up the code structure a bit.
(From OE-Core rev: 5c7f5031023fb74b5f2f26d6b3c829981f2f54d2)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
With the new server structure we no longer need this separate
environment init script. Just set BB_SERVER_TIMEOUT to be greater
than zero and bitbake will remain in memory and the UI will auto-reconnect
to it.
Also clean out the old shutdown code from oe-init-build-env which
also doesn't make sense now.
(From OE-Core rev: a17724d687f9c04dc21f2f369da2b492f7119ba0)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
recipetool seems to be mangling and stripping out the parameters for git
URI. This will fix this issue as well as resolve the conflict of
protocol parameter added by user. If a user adds their own protocol as
an argument, it'll be honored.
[YOCTO #11390]
[YOCTO #11391]
(From OE-Core rev: 0cd2fc8ca278ebaa76de95545eef26a07b350c8e)
Signed-off-by: Stanley Cheong Kwan, Phoong <stanley.cheong.kwan.phoong@intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
isoimage-isohybrid plugin tries to build grub-efi in its working
directory if it can't find efi binary. Wic should avoid doing anything
in working directories of other recipes. It should use artifacts from
the image deployment directory instead.
(From OE-Core rev: 9a1709278de877085a8d92f6361624e279a603bf)
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>
isoimage-isohybrid plugin uses result of glob call to
get path to initrd image. When glob returns empty list
the plugin crashes with IndexError.
Checking if result of glob call is not empty should fix
the breakage.
(From OE-Core rev: ad02f253f08a3da3fa5c86ae4f6ba7f94b070578)
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>
When wic can't find native sysroot it tries to build wic-tools
However, it's not possible when wic is run from bitbake.
Moreover, it's not even feasible anymore as wic-tools should be
used only when wic is run manually.
Checked if wic is run manually before building wic-tools.
(From OE-Core rev: 522ac21831944b06fbcc372ac61762576d792c22)
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>
Removed isodir subrdirectory instead of removing temporary
working directory as working directory can contain copy of
rootfs partition and shouldn't be removed by any plugin.
(From OE-Core rev: fc12ce9d1b92cc0104cf456af1e3d5f146b9219d)
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>
At the moment, when building images with IMAGE_FSTYPES=wic one ends up
depending on wic-tools and thus syslinux and grub-efi even when not
using those at all. Ideally, building an image with wic should only
build the tools and components really needed.
The problem is that "wic-tools" is needed also for the manual
invocations of wic, in which case everything that might be needed has to
be built in advance.
Replaced dependency on wic-tools with dependency to a much shorter set
of tools that wic uses almost for any image: 'parted', 'gptfdisk',
'dosfstools' and 'mtools'.
[YOCTO #11552]
(From OE-Core rev: 33ca15b94dbe7204c556c4b5526edd529f6d85f4)
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>
Used check_output instead of Popen as it raises CalledProcessError
exception when command exits with non-zero exit code.
Catched the exception to produce user-friendly output.
[YOCTO #11719]
(From OE-Core rev: dac68d2323b0b630c019ce4d5256ed567eaf00da)
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>
Introduced custom RunQemuException that script raises on known
errors. This exception is handled in one place and prints
error output without printing Python traceback. This shoud make
error output less scary for the end user.
Handling of unknown errors has not been changed - both error and
traceback will be printed.
Reimplemented OEPathError exception code to handle it similarly
to RunQemuException.
Moved exception handling code into main() to keep it in one place.
[YOCTO #11719]
(From OE-Core rev: a779a382b66e7b43ac53286758b4370dc14b193b)
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>
Missing user feature description file
when select linux-yocto-custom in script/yocto-bsp
and causes failure in script/yocto-kernel feature add.
[YOCTO #11585]
(From meta-yocto rev: 9939e7eacf8a205fb0b10de8a6cc065a8048b103)
Signed-off-by: Choong YinThong <yin.thong.choong@intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
By specifying the -e <var> option one or multiple times, extra
variables available in the pkgdata can be displayed, e.,g,
`oe-pkgdata-util package-info -e SUMMARY -e LICENSE ...`. The extra
variables displayed are quoted since some of them may contain
whitespace.
(From OE-Core rev: 6f054fcf08f6d5aeb6b5ade74ac5cc61a99fb8fe)
Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This moves the main content of test_signature into a helper
function. It can be reused by arbitrary tests that need to do
a before/after signature comparison. Long-term this might even
be useful in oeqa itself.
(From OE-Core rev: ecc9a1f9ceec9996aeb2c602846d51277de0b4a5)
Signed-off-by: Patrick Ohly <patrick.ohly@intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
It may be useful to append a suffix denoting the file format. For
example, README.rst is rendered differently when viewed on Github, and
also helps editors to switch to a mode more suitable for the format.
The tests uses a file pattern to find the README file(s) and treats
the one with the shortest name as the main one which must not be
empty.
(From OE-Core rev: 501b5b7f338396a4a115355b8a78ae5b03f67d9a)
Signed-off-by: Patrick Ohly <patrick.ohly@intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
"test_signatures" ignores wold build breakage for the sake of
reporting differences also when a world build is broken. Therefore we
need a dedicated test that a world build at least theoretically can
proceed without obvious parse time problems (dependencies, parse
errors, dangling .bbappends, etc.).
This is similar to the BSP test_machine_world. The difference is
that test_world doesn't change the MACHINE.
(From OE-Core rev: 1ca35d8571a92c7f8f80c909ca38666da82eb929)
Signed-off-by: Patrick Ohly <patrick.ohly@intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Software layers were previously allowed to change signatures, but
that's not desired for those layers either. The rule that a layer
which is "Yocto Compatible 2.0" must not change signatures unless
explicitly requested holds for all kinds of layers.
However, as this is something that software layers might not be able
to do right away, testing for signature changes in software layers can
be disabled. It's on by default, as that was Richard's
recommendation. Whether that should change needs further discussion as
part of finalizing "Yocto Compatible 2.0".
As it might still change, the tool now has both a with/without
parameter so that users of the tool can choose the desired behavior
without being affected by future changes to the default.
(From OE-Core rev: e7fe215f50a1b75771f33fffdda529a95c026d3f)
Signed-off-by: Patrick Ohly <patrick.ohly@intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The "test_signatures" test ignored a broken world build when getting
signatures, but the code which then tried to analyze a difference
found by the test didn't, which prevented printing the difference.
(From OE-Core rev: e8416554dfc9d4196543279a4845f6c0671f3e5c)
Signed-off-by: Patrick Ohly <patrick.ohly@intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
add_layer_dependencies() might get called more than once, or one of
the layer dependencies might already be present. The function should
not add layers again because doing so can cause warnings like:
WARNING: Duplicate inclusion for .../meta-openembedded/meta-oe/conf/distro/include/meta_oe_security_flags.inc in .../meta-openembedded/meta-oe/conf/layer.conf
(From OE-Core rev: 4afb7c3c505a4d21906f07f88c966b794a968cbc)
Signed-off-by: Patrick Ohly <patrick.ohly@intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
mkefidsk currently writes a startup.nsh with embedded control characters.
This happens because \b etc are control sequences to the shell echo
command when using dash. The resulting startup.nsh causes the bootup
to fail, and the user is dropped into the EFI shell to manually run
startup.nsh.
Patch originally provided by Troy D. Hanson <troy.hanson@jhuapl.edu>
[YOCTO #9665]
(From OE-Core rev: 008d6cb5bb4969f53a228893c502be8c9420ecb0)
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This script analyses the patches we apply and can sanity check or output
statistics.
(From OE-Core rev: de7914954571ea8e717f56b6d6df13157b0973bc)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Some "=" are missing in the regexp, which leads it match multiple results
if the variables have overrides, for instance:
...
SSTATE_DIR="xxxx"
SSTATE_DIR_qemux86="yyyy"
...
it will match both of them without "=".
(From OE-Core rev: 10cb4331caee4b960a6f9ad20023a4a4b69b684e)
Signed-off-by: Ming Liu <peter.x.liu@external.atlascopco.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
A "=" is missing in the regexp, which leads it match multiple results
if STAGING_DIR_NATIVE has overrides, for instance:
...
STAGING_DIR_NATIVE="xxxx"
STAGING_DIR_NATIVE_qemux86="yyyy"
...
it will match both of them without "=".
(From OE-Core rev: fb9cf84b1d537e2b8c26cd78f6ac27c55a7e79fc)
Signed-off-by: Ming Liu <peter.x.liu@external.atlascopco.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The following commit has removed rpc ports from runqemu-export-rootfs, so
runqemu should also remove them, otherwise "runqemu nfs" doesn't work. And use
abspath for nfsroot, otherwise it doesn't work when it is a relative path.
commit 6bb9860ef7
Author: Cody P Schafer <dev@codyps.com>
Date: Tue Jun 6 18:30:49 2017 -0400
runqemu-export-rootfs: don't change RPC ports
[YOCTO #11687]
(From OE-Core rev: d7c5c9344de6974997c39097a7767ec338c3cca3)
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Moved remaining API to misc.py.
Removed runner.py.
Now misc.py is ready to be moved to the scripts/lib/wic and
utils directory can be removed.
(From OE-Core rev: 327e340a29d330f24117e24d0649fa156017208f)
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>
Wic updates fstab if mount points are specified in .wks.
After partition images are created the original fstab is restored.
However, if exception is raised when partition image being prepared
wic doesn't restore original fstab. This can cause duplication of
added lines in fstab when 'wic create' runs next time.
Wrapping call of 'prepare' method and restoring original fstab
even if exception occurs should fix this.
[YOCTO #11633]
(From OE-Core rev: 29f7735030d383f9614bdb148b52a47c79f05eea)
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>
Moved misc.py from wic/utils/ to wic/
Removed wic/utils directory
(From OE-Core rev: df906f3caa0721756f5ed48fa657e62e05ae2aa3)
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>
The script run patchtest on local branch commits, printing results into
stdout. This script is useful to test patches before sending to the
mailing list.
Examples:
$ git checkout master-next-1.9
Branch master-next-1.9 set up to track remote branch master-next-1.9 from origin.
Switched to a new branch 'master-next-1.9'
$ ~/scripts/contrib/patchtest.sh
166e70e: Robert Yang: Thu Apr 2 12:01:37 2015 +0100: patch: fix CVE-2015-1196: FAIL
Issue Missing or incorrectly formatted CVE tag in commit message [test_cve_presence_in_commit_message]
Suggested fix Include a "CVE-xxxx-xxxx" tag in the commit message
Issue Missing or incorrectly formatted CVE tag in included patch file [test_cve_tag_format]
Suggested fix Correct or include the CVE tag on cve patch with format: "CVE: CVE-YYYY-XXXX"
eaa4536: Robert Yang: Thu Apr 2 12:01:37 2015 +0100: wget: 1.16.1 -> 1.16.2: OK
3c29ce3: Robert Yang: Thu Apr 2 12:01:38 2015 +0100: git: 2.3.0 -> 2.3.1: OK
85491f6: Khem Raj: Thu Apr 2 12:01:38 2015 +0100: gdb: Upgrade 7.8.1 -> 7.9: OK
f701142: Robert Yang: Thu Apr 2 12:01:38 2015 +0100: binutils: upgrade to 2.25: OK
385d0b1: Khem Raj: Thu Apr 2 12:01:39 2015 +0100: binutils: Fix ICE in gold: OK
[YOCTO #10720]
(From OE-Core rev: 4ba1334ab7c9b32502a4f8b3e656fb4f8242ccdd)
Signed-off-by: Leonardo Sandoval <leonardo.sandoval.gonzalez@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Implemented -e/--exclude-path command line option to
exclude paths from buildhistory-diff output.
[YOCTO #11459]
(From OE-Core rev: 86393230e0ce33bf7d6d69d3019113e704081d30)
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>
* the /usr/lib/python3.5/_compression.py file is possibly incorrectly included
in python3-misc. This runtime dependency is needed in order to use e.g. gzip.py in runtime:
>>> import tarfile, zlib, gzip
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/usr/lib/python3.5/gzip.py", line 12, in <module>
import _compression
ImportError: No module named '_compression'
* at least python3-tests and lzma and bz2 still in python3-misc are using this as well:
$ grep -R import.*_compression tmp-glibc/work/aarch64-oe-linux/python3/3.5.2-r1.0/packages-split/
tmp-glibc/work/aarch64-oe-linux/python3/3.5.2-r1.0/packages-split/python3-compression/usr/lib/python3.5/gzip.py:import _compression
tmp-glibc/work/aarch64-oe-linux/python3/3.5.2-r1.0/packages-split/python3-misc/usr/lib/python3.5/lzma.py:import _compression
tmp-glibc/work/aarch64-oe-linux/python3/3.5.2-r1.0/packages-split/python3-misc/usr/lib/python3.5/bz2.py:import _compression
tmp-glibc/work/aarch64-oe-linux/python3/3.5.2-r1.0/packages-split/python3-tests/usr/lib/python3.5/test/test_bz2.py:import _compression
tmp-glibc/work/aarch64-oe-linux/python3/3.5.2-r1.0/packages-split/python3-tests/usr/lib/python3.5/test/test_lzma.py:import _compression
and python3-tests are using it as well, so add new runtime dependency
on python3-compression
(From OE-Core rev: 987363c3c720b3764f4d64976d7455f6b0bae99c)
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
runqemu uses stty to change terminal settings to give users
better control to qemu. However, stty does not work when
runqemu is run directly or indirectly via oe-selftest in
a Docker container (presumably some problems with Docker's
pseudo-tty implementation).
The error reported is:
stty: 'standard input': Inappropriate ioctl for device
As runqemu recently moved to subprocess.check_call() for
stty calls we now get thrown an error and all runqemu
runs fail.
sys.stdin.isatty() does proper job in detecting if the stty
calls can work so we use that check before running the stty
subprocess operations.
(From OE-Core rev: 06742ed59092530aedf03f65c3c9542c24ff7ac3)
Signed-off-by: Mikko Ylinen <mikko.ylinen@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Remove user-specific descrition files and config fragments from main machine
description file otherwise double patch/config inclusion may happen. These
files/fragments are already included on the SRC_URI (see poky commit 2db8f3),
so no need to reference these inside machine.scc files.
[YOCTO #11586]
(From meta-yocto rev: 86ab7ab6688f250bb5777371d2cbc28c770847d4)
Signed-off-by: Leonardo Sandoval <leonardo.sandoval.gonzalez@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Added support for removing directories using mdeltree
utility to Disk.del method
[YOCTO #11283]
(From OE-Core rev: a5fc61d8f290d370f4bc51d4e2a67a5580edb1b1)
Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Added implementation of Disk.del method and wic_r
function that removes files from the vfat partition
using mdel utility.
[YOCTO #11283]
(From OE-Core rev: 4abf2d2643c58322d96d63d5f3ffaf52d62c6792)
Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Added empty 'wic rm' command that does nothing.
The functionality will be added by the next commits.
[YOCTO #11283]
(From OE-Core rev: f8e42c13609c482359fbdb225fb16a45101ae9ae)
Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Added wic_rm_help and wic_rm_usage variables to help.py.
These variables contain help content that will be used in
'wic rm help' and 'wic rm --help' output.
(From OE-Core rev: b6894538b2a426762a07c0e7b014a04f4e00266d)
Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Added implementation of Disk.copy method and wic_cp
function that copies files/directories to the vfat partition
of the partitioned image.
[YOCTO #11283]
(From OE-Core rev: 416e4599960987f0ce31b3f16f3c6af0bf633a26)
Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This method copies partition image into the wic image.
It will be used in 'wic cp' and 'wic rm' subcommands
to copy changed partition back into wic image.
(From OE-Core rev: 7a7e6635e2e2ddfff2bca58c860634b7a199b0df)
Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Fixed calculation of the dst file size using skip, seek and
length parameters. Current code does it incorrectly which
causes sparse_copy API to create unnecessary big output files.
(From OE-Core rev: e6d709a6382e4b913612f597e66ad07b0e351d5f)
Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If lenght parameter is provided to sparse_copy call
it's mandatory to check if the output file is fully
written after reading unmapped block from input file.
If it's not done then sparse_copy can write more data
than specified length.
(From OE-Core rev: 289b1767182982dfb6912e64481150697ba93e4d)
Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Renamed parameter offset->skip to match names of dd
parameters.
Changed affected sparse_copy calls.
Added explanation of the parameters to docstring.
(From OE-Core rev: 08e2f4e59816c5757686255b267b08cbc46fbd95)
Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Added property that points to the mcopy executable.
(From OE-Core rev: 05badb6427442388b9bea04c8b184a2ce92362ec)
Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Added generic helper to use in property methods to
access commands in a lazy manner.
(From OE-Core rev: 4c1ded3ddbd04ad1640620ec1348831692a93dbe)
Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Added empty 'wic cp' command that does nothing.
The functionality will be added by the next commits.
[YOCTO #11283]
(From OE-Core rev: f0dcf39d52185430422cb0c94c7fe99c12764acd)
Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Added wic_cp_help and wic_cp_usage variables to
help.py. These variables contain help content that
will be used in 'wic cp help' and 'wic cp --help'
output.
[YOCTO #11283]
(From OE-Core rev: f3f0dadada1e297f2b54fa320bb817da7f755c1f)
Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Add parser for 'wic cp' subcommand and a custom argument type.
(From OE-Core rev: df5152c834ef58036b41ad51b19eda6abecd9543)
Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Added empty 'wic ls' command that does nothing.
The functionality will be added by the next commits.
(From OE-Core rev: ba4613469cc2c3d3433be2e2f520f4fff6b3b333)
Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Added wic_ls_help and wic_ls_usage variables to
help.py. These variables contain help content that
will be used in 'wic ls help' and 'wic ls --help'
output.
(From OE-Core rev: 5152f993777550e5e8a420db4d1f3c4370cd1d33)
Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
