| Age | Commit message (Collapse) | Author |
|---|
|
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].
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
|
|
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.)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
|
|
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.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
|
|
find_layerdir() should really return absolute paths, so make it do so.
This fixes devtool finish not deleting files it should do after devtool
upgrade if the specified path is relative, since the devtool finish code
was assuming that find_layerdir() was returning an absolute path.
Fixes [YOCTO #12318].
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
|
|
If a value was split over multiple lines (e.g. as SRC_URI usually is)
then we were inserting the value as one item in the lines list with
newlines between each line. There's nothing wrong with this if you're
writing the list out to a file, but if you want to generate a patch (as
patch_recipe_file() will do if the patch parameter is set to True) then
the diff output looks a bit odd. Split the value before adding it to the
lines list to resolve this.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
|
|
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.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
|
|
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].
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
|
|
* Only log one warning message instead of one per line
* Be a bit more verbose
* "if list" is more pythonic than "if len(list)"
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
|
|
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].
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
|
|
Give the user a little more insight into what's being done.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
|
|
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
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
|
|
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.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
|
|
This looks like some debug printing that was left in by accident.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
|
|
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.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
|
|
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.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
|
|
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.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
|
|
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.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
|
|
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.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
|
|
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.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
|
|
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].
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
|
|
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.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
|
|
* 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.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
|
|
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
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
|
|
If a matching recipe is not found then return Null instead of raising
KeyError because we were blindly using None as a key for pkg_fn.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
|
|
|
|
We shouldn't be passing a relative path to the plugins if that's what's
been specified on the recipetool command line.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
|
|
|
|
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
|
|
Fixes [YOCTO #9974] and [YOCTO #11011].
|
|
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
|
|
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
|
|
Currently if you run bitbake in an invalid directory, the user experience
is poor:
birbake/lib/bb/main.py", line 427, in setup_bitbake
topdir, lock = lockBitbake()
File "./bitbake/lib/bb/main.py", line 494, in lockBitbake
lockfile = topdir + "/bitbake.lock"
TypeError: unsupported operand type(s) for +: 'NoneType' and 'str'
This ensures we exit straight away with a better error message.
[YOCTO #12163]
(Bitbake rev: 562f9ee674a8b392437096422b9cceab9c3cba2e)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
In Python 3.6, glob.glob() was reimplemented to use os.scandir() (which
itself appeared in Python 3.5), thus our monkey patching of os.listdir()
here was no longer effective. The end result was not only that bitbake
wouldn't notice added recipes or bbappends with BB_SERVER_TIMEOUT set
when being run with Python 3.6 (the shipped Python version on Fedora 26
and some other distribution versions), it also broke devtool modify,
devtool upgrade and devtool extract since they rely on the ability to
create a bbappend on the fly and have bitbake pick it up.
To fix it, do the same monkey patching for os.scandir(), which needs to
be conditional upon that actually existing since we have to support
Python 3.4 that doesn't have it. Long term we should probably look for a
better way to handle this that doesn't involve monkey patching Python
library code.
Fixes [YOCTO #12185].
(Bitbake rev: d02e90db32e7ee341c2ba3be79b0627d8796bdd6)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
(Bitbake rev: 2a686d87a991089ad4e1fc12522d5c93919a221f)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
(Bitbake rev: 83834a58b6c1ec866967c03494b9a7f4d5f1177e)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Fixed wording on how the OpenEmbedded build system dynamically
generates do_image_* tasks as needed during image generation.
(From yocto-docs rev: 9df98d77a446cd5d27c4e87418117a904b1f4231)
Signed-off-by: Scott Rifenbark <srifenbark@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
The yocto-layers script is being deprecated in the 2.4 YP release
and the preferred script is now bitbake-layers. In particular, the
section that talks about creating a general layer was using
yocto-layers create. I have replaced it with bitbake-layers
create-layer command.
The bsp-guide and kernel-dev manual had links that used (in the
case of kernel-dev) and referenced yocto-layers. I had to change
these to reflect using bitbake-layers create-layers.
(From yocto-docs rev: 73ec4d0c8c2c093b7c9df86038d132f0da975273)
Signed-off-by: Scott Rifenbark <srifenbark@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
(From yocto-docs rev: e0302faa6e7c4ef17c57489e6e6f11b73d8e9b94)
Signed-off-by: Kristi Rifenbark <kristi.rifenbark@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Made the title page notes consistent across the manual set.
Made the author group information consistent as well. It is better
that authorship is seen as a third party and not tied to Intel
Corporation.
(From yocto-docs rev: 32cec087e384e1d92e3e84bbae5c6560a0af3136)
Signed-off-by: Scott Rifenbark <srifenbark@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
(From yocto-docs rev: a7238f165cd6cde6c33d9981577039f8511f5fe3)
Signed-off-by: Scott Rifenbark <srifenbark@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
(From yocto-docs rev: 60167c15c08ddaa211c4a1151e6b1a0b00763cc0)
Signed-off-by: Scott Rifenbark <srifenbark@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Added information about how the build system dynamically creates
do_image_* tasks (e.g. do_image_ext4[depends]) when creating the
image. This is functionality that replaced IMAGE_DEPENDS_type.
(From yocto-docs rev: c977df506585aad1ade99c390bacc04b54eb0e48)
Signed-off-by: Scott Rifenbark <srifenbark@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
(From yocto-docs rev: 7f54c31b91c7ec719f507a1b67a99c1b329619f7)
Signed-off-by: Scott Rifenbark <srifenbark@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
(From yocto-docs rev: fdfa837b5d453d2721e92b01dda25e3b0a517913)
Signed-off-by: Scott Rifenbark <srifenbark@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
The title of the sdk-manual changed. Many links were updated to
render to the correct book title.
(From yocto-docs rev: 821e29c6c031ae2516fb0e79d0ec3936a5bd624c)
Signed-off-by: Scott Rifenbark <srifenbark@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
The name of the sdk-manual changed and I had to update some external
links and references into the manual.
(From yocto-docs rev: fba92910fd91d1ca49bc6915820effb189f1852e)
Signed-off-by: Scott Rifenbark <srifenbark@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
The name of the SDK manual changed and there was one link to the
manual that needed fixed.
(From yocto-docs rev: 800d5106a25ce4e87b0468ec3ab03dd8a49f3082)
Signed-off-by: Scott Rifenbark <srifenbark@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Change the name of the manual to "Yocto Project Application
Development and the Extensible Software Development Kit (eSDK)".
The "sdk-title.png" file was updated and all title information
was updated.
(From yocto-docs rev: 502a49a9e4f5e80efe16507391bc9d9618efefbd)
Signed-off-by: Scott Rifenbark <srifenbark@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
SDK manual title changes so the links into that manual needed updating.
(From yocto-docs rev: e59d1cb22d46b00e9413deb5c7a70a14be880dc1)
Signed-off-by: Scott Rifenbark <srifenbark@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
This also affected a link in the dev-manual and some setup stuff
in the mega-manual and sdk-manual.xml file due to a new chapter
being introduced.
This section on the Eclipse stuff is big enough to warrant its
own chapter. I decided to pull it into a separate chapter of its
own.
(From yocto-docs rev: a4b2b605902f09bb200facfabb0a7c355fbf4c87)
Signed-off-by: Scott Rifenbark <srifenbark@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
Paul Eggleton
Richard Purdie
Khem Raj
Scott Rifenbark
Kristi Rifenbark