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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
