Add a function (and test suite) to turn the ELF machine field (e_machine) into a string, so we can tell the user "x86-64" instead of 0x3E. Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The PACKAGE_EXCLUDE_COMPLEMENTARY variable can currently only contain one regular expression. This makes it hard to add to it from different configuration files and recipes. Allowing it to contain multiple, whitespace separated regular expressions should be backwards compatible as it is assumed that whitespace is not used in package names and thus is not used in any existing instances of the variable. After this change, the following three examples should be equivalent: PACKAGE_EXCLUDE_COMPLEMENTARY = "foo|bar" PACKAGE_EXCLUDE_COMPLEMENTARY = "foo bar" PACKAGE_EXCLUDE_COMPLEMENTARY = "foo" PACKAGE_EXCLUDE_COMPLEMENTARY += "bar" Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This allows a regular expression specified in PACKAGE_EXCLUDE_COMPLEMENTARY to have a leading dash. Without this, the dash was treated by oe-pkgdata-util as the beginning of a command line argument. E.g., if PACKAGE_EXCLUDE_COMPLEMENTARY = "-foo$", it resulted in an error like: ERROR: <imagename>-1.0-r0 do_populate_sdk: Could not compute complementary packages list. Command '<topdir>/scripts/oe-pkgdata-util -p <builddir>/tmp/sysroots/<machine>/pkgdata glob <workdir>/installed_pkgs.txt *-dev *-dbg -x -foo$' returned 2: ERROR: argument -x/--exclude: expected one argument usage: oe-pkgdata-util glob [-h] [-x EXCLUDE] pkglistfile glob [glob ...] Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When PATCHTOOL = "git", if we need to manually apply a patch and then commit it (i.e. when git am doesn't work) we try to extract the author / date / shortlog from the patch header. Make the following improvements to that extraction process: * If there's no explicit Subject: but the first line is followed by a blank line, isn't an Upstream-Status: or Index: marker and isn't too long, then assume it's good enough to be the shortlog. This avoids having too many patches with "Upgrade to version x.y" as the shortlog (since that is often when patches get added). * Add --follow to the command we use to find the commit that added the patch, so we mostly get the commit that added the patch rather than getting stuck on upgrade commits that last moved/renamed the patch * Populate the date from the commit that added the patch if we were able to get the author but not the date from the patch (otherwise you get today's date which is less useful). Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If you leave "From <hash>" lines in the commit message it can actually break git rebase because it tries to interpret the line in the context of the current repository, and if the hash is invalid then a rebase will blow up with: fatal: git cat-file: could not get object info or in newer git versions: error: unable to find <hash> fatal: git cat-file <hash>: bad file (I hit this when I tried to do a devtool upgrade on openssl to 1.0.2i the first time I did "git rebase --skip") Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Based on a discussion with IRC user: Ulfalizer It was suggested that removing the diagnostic list, and replacing it with a simple hint to what might be causing the problem was a better solution. Signed-off-by: Mark Hatle <mark.hatle@windriver.com> Signed-off-by: Ross Burton <ross.burton@intel.com>
Move the debug before the error (as it can take many pages.) This makes it much easier for the user to see the actual error message as it is still on the screen. Signed-off-by: Mark Hatle <mark.hatle@windriver.com> Signed-off-by: Ross Burton <ross.burton@intel.com>
* validate_pn() is supposed to protect against invalid characters, fix the function so that it actually does (unanchored regex strikes again...) * However, now that the function is enforcing the restrictions, we do still want to allow + in recipe names (e.g. "gtk+") Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Previously the following commit in oe-core move RPM metadata
from DEPLOY_DIR to WORKDIR.
-----------
commit a92c196449c516fe51786d429078bbb1213bb029
Author: Stephano Cetola <stephano.cetola@linux.intel.com>
Date: Wed Aug 10 13:03:16 2016 -0700
Allow for simultaneous do_rootfs tasks with rpm
Give each rootfs its own RPM channel to use. This puts the RPM metadata
in a private subdirectory of $WORKDIR, rather than living in DEPLOY_DIR
where other tasks may race with it.
-----------
In the modification of 'class RpmIndexer, it should not
directly set arch_dir with WORKDIR. It caused 'bitbake
package-index' could not work correctly.
Assign WORKDIR as input parameter at RpmIndexer initial time
could fix the issue.
Signed-off-by: Hongxu Jia <hongxu.jia@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Indirect paths (e.g. ${TOPDIR}/../meta-something) do generally work if
used in BBLAYERS in bblayers.conf. However, if you built an extensible
SDK with this configuration then the creation of the workspace within
the SDK using devtool in do_populate_sdk_ext failed. This is because
the copy_buildsystem code was no longer correctly recognising that the
core layer ("meta") was part of a repository (e.g. openembedded-core /
poky) that should be shipped together - because of the indirection - and
thus it was splitting out the meta directory, and a number of places in
the code assume that the meta directory is next to the scripts
directory. Use os.path.abspath() to flatten out any indirections.
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>