Sort keys of dict 'types' prior to dumping, in order to have
identical output every time. This could make it a little easier
to diff these human-readable dumps.
(From OE-Core rev: 8abbaba1931e2cb2b87aa733aa9a3e8eb359b500)
Signed-off-by: Jianxun Zhang <jianxun.zhang@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Add a warning in the doc comment for oe.path.remove() about using that
function on paths that may contain wildcards in the actual
file/directory names.
(From OE-Core rev: 18cc0965741102bccc62dfb32ed7753cdacbadc7)
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>
There were a few straggling expansion parameter removals left for
getVar/getVarFlag where the odd whitespace meant they were missed
on previous passes. There were also some plain broken ussages such
as:
d.getVar('ALTERNATIVE_TARGET', old_name, True)
path = d.getVar('PATH', d, True)
d.getVar('IMAGE_ROOTFS', 'True')
which I've corrected (they happend to work by luck).
(From OE-Core rev: 688f7a64917a5ce5cbe12f8e5da4d47e265d240f)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We've moved to python3, we don't need this compatibility code which just makes
the code less readable.
(From OE-Core rev: 425afe2484707640ac71194885fdb263e95e9950)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If createrepo isn't found then the errors later are mysterious, so explicitly
check and error out early if it isn't there.
(From OE-Core rev: e09636bbb3ea8ec58984197fd9c691bb908efe00)
(From OE-Core rev: c87361fc886432a9db584712bf3e41ecd0541960)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
BUILD_CC may reference something like ccache and expect this to come from
ccache-native, we at least have some selftests which assume this. Modify the
code to use PATH when runnig BUILD_CC to ensure the tests continue to work
as expected.
(From OE-Core rev: f3e753372baac43d0921186340cf260df056de20)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
getVarFlag() now defaults to expanding by default, thus remove the
True option from getVarFlag() calls with a regex search and
replace.
Search made with the following regex:
getVarFlag ?\(( ?[^,()]*, ?[^,()]*), True\)
(From OE-Core rev: 2dea9e490a98377010b3d4118d054814c317a735)
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>
getVar() now defaults to expanding by default, thus remove the True
option from getVar() calls with a regex search and replace.
Search made with the following regex: getVar ?\(( ?[^,()]*), True\)
(From OE-Core rev: 7c552996597faaee2fbee185b250c0ee30ea3b5f)
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 script detects directory renaming if two different
directories with the same set of files are added and removed.
[YOCTO #10691]
(From OE-Core rev: 944db779a9f45cbeeebc976c00da37a517eea237)
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>
Some c++ libraries fail to build if uninative is built
with gcc 5.x and host gcc version is either 4.8 or 4.9.
The issue should be solved by making separate uninative sstate
directory structure sstate-cache/universal-<gcc version> for host gcc
versions 4.8 and 4.9. This causes rebuilds of uninative if host gcc
is either 4.8 or 4.9 and it doesn't match gcc version used to build
uninative.
[YOCTO #10441]
(From OE-Core rev: d36f41e5658bbbb6080ee833027879c119edf3e0)
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>
These tests don't get ran often (as demonstrated by the fact that some were not
ported to Python 3), so move them to oeqa/selftest so they get executed
frequently and can be extended easily.
[ YOCTO #7376 ]
(From OE-Core rev: 2001979ad41e6fdd5a37b0f90a96708f39c9df07)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This was intended to be used with tinfoil, but tinfoil now has its own
parse_recipe() method to do this which works properly in the memres
case.
(From OE-Core rev: cdfc6173cb06ca374b7d927442a0fdde8373ba48)
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>
Move patch_path(), src_patches() and should_apply() to oe.patch, making
them easier to call from elsewhere (particularly across the
UI/server boundary).
(From OE-Core rev: 2724511e18810cc8082c1b028e3b7c8a8b5def56)
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 now have a function in cooker itself that can do this lookup;
additionally, the rewritten tinfoil's cooker adapter has its own
implementation that can work remotely, so if we use it then this
function can work in that scenario as well.
(From OE-Core rev: 0a6a4be99c1e4ef3c0da53d63f18ad579545d6a8)
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 printed a warning through bb.warn() / bbwarn or an error through
bb.error() / bberror, this was also being picked up by our log_check
mechanism that was designed to pick up warnings and errors printed by
other programs used during do_rootfs. This meant you saw not only the
warning or error itself, you saw it a second time through log_check,
which is a bit ugly. Use the just-added BB_TASK_LOGGER to access the
logger and add a handler that we can use to find out if any warning or
error we find in the logs is one we should ignore as it has already been
printed.
Fixes [YOCTO #8223].
(From OE-Core rev: fb37304d27857df3c53c0867e81fbc8899b48089)
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 were calling _log_check() in the RPM-specific rootfs class as well as
in the base class; this is unnecessary and resulted in any errors/warnings
generated during the actual package installation time triggering two warnings
instead of one. Drop the call from RpmRootfs._create() to fix this.
(From OE-Core rev: 541c56d755ba0354297673e857628026ad9e4df2)
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 using subprocess call and check_output, it is better to use arrays
rather than strings when possible to avoid whitespace and quoting
problems.
[ YOCTO #9342 ]
(From OE-Core rev: b12cec9a5ef14ecb02be7feec65508cf5d65c795)
Signed-off-by: Stephano Cetola <stephano.cetola@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Based on run() in bitbake/lib/bb/process.py, ExecutionError() expects strings
not bytes. Passing bytes results in a "TypeError: Can't convert 'bytes' object
to str implicitly" exception.
Fixes Bug 10729
(From OE-Core rev: 063b63d4d324c23322ac1b6b7c7928e725d7b968)
Signed-off-by: Martin Vuille <jpmv27@yahoo.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Some rolling release distros, such as Arch Linux, don't include a
VERSION_ID field in their os-release file.
Change release_dict_osr() to better handle this optional field
being absent.
Further improve the resilience of the release_dict_*() methods by
always returning a dict and using dict.get() in distro_identifier()
to supply a default, empty string, value when then key is missing.
(From OE-Core rev: e36066dcc3b56cac1c695370ea178b566c0ebfd6)
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>
When attempting to run devshell, if no terminal is available, the
error being thrown was not very specific. This adds a list of
commands that failed, informing the user of what they can install to
fix the error.
[ YOCTO #10472]
(From OE-Core rev: c077f4aab2fc956408d4ad45c4e2e2ea6e480624)
Signed-off-by: Stephano Cetola <stephano.cetola@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
By default, have get_recipe_local_files() not return any archive
files. This prevents a local tarball from being erroneously removed
from SRC_URI if you run "devtool modify" on a recipe followed by
"devtool update-recipe". It doesn't actually help you to directly
update the contents of such tarballs, but at least now it won't break
the recipe.
(From OE-Core rev: e9c418d4704c1bed4c5880e176e5288485f4f5a6)
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 is possible to use gzip or bzip2 to compress patches and still refer
to them in compressed form in the SRC_URI value within a recipe. If you
run "devtool modify" on such a recipe, make changes to the commit for
the patch and then run devtool update-recipe, we need to correctly
associate the commit back to the compressed patch file and re-compress
the patch, neither of which we were doing previously.
Additionally, add an oe-selftest test to ensure this doesn't regress in
future.
Fixes [YOCTO #8278].
(From OE-Core rev: e47d21624dfec6f71742b837e91da553f18a28c5)
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 patch applied by a recipe has no header and we turn the recipe's
source into a git tree (when PATCHTOOL = "git" or when using devtool
extract / modify / upgrade), the commit message ends up consisting only
of the original filename marker ("%% original patch: filename.patch").
When we come to do turn the commits back into a set of patches in
extractPatches(), this first line ends up in the "Subject: " part of
the file, but we were ignoring it because the line didn't start with the
marker text. The end result was we weren't able to get the original
patch name. Strip off any "Subject [PATCH x/y]" part before looking for
the marker text to fix.
This caused "devtool modify openssl" followed by "devtool update-recipe
openssl" (without any changes in-between) to remove version-script.patch
because that patch has no header and we weren't able to determine the
original filename.
(From OE-Core rev: d9971f5dc8eb7de551fd6f5e058fd24770ef5d78)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The debian policy manual and MaintainerScripts wiki page states that the
postinst script is supposed to be called with the `configure` argument
at first install, likewise the preinst script is supposed to be called
with the `install` argument on first install.
https://www.debian.org/doc/debian-policy/ch-maintainerscripts.htmlhttps://wiki.debian.org/MaintainerScripts
(From OE-Core rev: 3d9c3aae54589794ce3484fa1b21d1af2bd32661)
Signed-off-by: Linus Wallgren <linus.wallgren@scypho.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The LSB Distributor ID and os-release NAME differ for most of the
distributions tested by the Yocto Project (CentOS, Debian, Fedora,
openSUSE and Ubuntu) however for all but openSUSE the os-release ID
matches the LSB Distributor ID when both are lowered before
comparison.
Therefore, in order to improve the consistency of identification of
a distribution, switch to using the os-release ID and converting
the ID value to lowercase.
Table showing comparison of LSB Distributor ID to os-release fields NAME
and ID for current Yocto Project supported host distributions:
Distribution | Version | Distributor ID | NAME | ID |
-------------------------------------------------------------------------
CentOS | 7 | CentOS | CentOS Linux | centos |
Debian | 8 | Debian | Debian GNU/Linux | debian |
Fedora | 23 | Fedora | Fedora | fedora |
Fedora | 24 | Fedora | Fedora | fedora |
openSUSE | 13.2 | openSUSE project | openSUSE | opensuse |
openSUSE | 42.1 | SUSE LINUX | openSUSE Leap | opensuse |
Ubuntu | 14.04 | Ubuntu | Ubuntu | ubuntu |
Ubuntu | 16.04 | Ubuntu | Ubuntu | ubuntu |
[YOCTO #10591]
(From OE-Core rev: 8689e5618d45c2119134ea64754430c06a93ea09)
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>
os-release(5) is an increasingly standard source of operating system
identification and more likely to be present on modern OS deployments, i.e.
many container variants of common distros include os-release and not the
lsb_release tool.
Therefore we should favour parsing /etc/os-release in distro_identifier(),
try lsb_release when that fails and finally fall back on various distro
specific sources of OS identification.
(From OE-Core rev: fc4eddecddec68d03a985086fa32db40ad0c7bfc)
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>
Rather than have the distro_identifier method look for different keys in
the dict depending on the source ensure that each function for retrieving
release data uses the same key names in the returned dict.
(From OE-Core rev: 2ddd6ddaf0c5ba14ae83347eba877ac9ef179c76)
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 ELF parser was assuming that the segment tables are in the first 4kb of the
binary. Whilst this generally appears to be the case, there have been instances
where the segment table is elsewhere (offset 2MB, in this sample I have). Solve
this problem by mmap()ing the file instead.
Also clean up the code a little whilst chasing the problem.
(From OE-Core rev: a66660aa5bb709547ce0b65a4563e4217c3c3d9f)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
There's no need to import glob inside copyhardlinktree() as it's
already imported for the entire path module.
(From OE-Core rev: 42dc4695da136a15bebb7525b1da5c2722b10a28)
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>
Instead of checking against a file that represents a distribution that hasn't
existed for years, fetch package names for Clear Linux instead.
[ YOCTO #10601 ]
(From OE-Core rev: 006c4db0974c42ff0f6950dd24e61c008f801679)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This library suffered as part of the Python 2 to Python 3 migration and stopped
working entirely.
Fix all the migration problems such as files being treated as strings but opened
in binary mode, insufficient use of with on files, and so on.
Rewrite large amounts to be Pythonic instead of C-in-Python.
Update OpenSuse and Fedora URLs.
Fedora now splits the archive alphabetically so handle that.
[ YOCTO #10562 ]
(From OE-Core rev: 58de12eaaac9c60bb8fc84a3a965ef86d2a39ae0)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If you use devtool update-recipe with the --append option, and a "local"
(in oe-local-files) has been modified we copy it into the specified
destination layer. With the way the devtool update-recipe code works now
the source is always a temp directory, and printing paths from within
that is just confusing, so if the path starts with the temp directory
then just print the file name alone.
(From OE-Core rev: 61475f0267d40c618ebf36023d0b6414a25975cb)
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>
Do not use --force-depends when trying to remove all dependent packages,
as it removes only the selected package and not the dependent packages.
(From OE-Core rev: a82e8725902086dab785a0b14305927dae1e4e8d)
Signed-off-by: Samuli Piippo <samuli.piippo@qt.io>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When there is a relative symlink in the layer, for example:
symA -> ../out/of/layer/file
symA will be invalid fater copied, it would be invalid from build time
if it points to a relative path, and would be invalid after extracted
the sdk if it points to a absolute py. Dereference symlink when copy
will fix the problem.
Use tar rather than shutil.copytree() to copy is because:
1) shutil.copytree(symlinks=Fasle) has bugs when dereference symlinks:
https://bugs.python.org/issue21697
And Ubunutu 1404 doesn't upgrade python3 to fix the problem.
2) shutil.copytree(symlinks=False) raises errors when there is a invalid
symlink, and tar just prints a warning, tar is preferred here since
the real world is unpredicatable
3) tar is faster than shutil.copytree() as said by oe.path.copytree()
So use tar to copy.
(From OE-Core rev: f4d70bb0882eec4fb46cd942f2796fad57c72982)
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>
Konsole has dropped support for the nofork flag. It has been replaced with the seperate flag.
(From OE-Core rev: f0b193b63d4c468c3aa58e15ef5a991e04b9b9a2)
Signed-off-by: Michael Davis <michael.davis@essvote.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
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.
(From OE-Core rev: 72336003741fb16a7ecdd6b753eae56310413ff7)
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"
(From OE-Core rev: a5f7e98a94e96d40b1276c85249619aa8d7be847)
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 ...]
(From OE-Core rev: ac4ca41d3a27356d46c0c39053e74d3519b24c44)
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).
(From OE-Core rev: 896cfb10ec166a677cbb3b4f8643719cabeb7663)
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")
(From OE-Core rev: 19a6b18ac23cb2d7bb89203f774b2bee7f0cb03c)
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.
(From OE-Core rev: ca78313665b23bd7fee85f034acfe1eb1009bd65)
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>
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.
(From OE-Core rev: d643fb2a9cb5bd0d8b0105e9d44b989a49ffa963)
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>
* 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+")
(From OE-Core rev: c5d5a1baf98a11676537fb5e9f8ec4409e30c1fd)
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.
(From OE-Core rev: 3c8c8501d0a19b566a94a9e06afe40642b444958)
Signed-off-by: Hongxu Jia <hongxu.jia@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
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.
(From OE-Core rev: 7c0788cd2390fd0e1ec84bc9dbebcb67daee429f)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(From OE-Core rev: 79fe476be233015c1c90e9c3fb4572267b5551d1)
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>
It's rare but there are recipes that have individual files (as opposed
to archives) in SRC_URI using subdir= to put them under the source tree,
the examples in OE-Core being bzip2 and openssl. This broke devtool
update-recipe (and devtool finish) because the file wasn't unpacked into
the oe-local-files directory and thus when it came time to update the
recipe, the file was assumed to have been deleted by the user and thus
the file was erroneously removed. Add logic to handle these properly so
that this doesn't happen.
(We still have another potential problem in that these files become part
of the initial commit from upstream, which could be confusing because
they didn't come from there - but that's a separate issue and not one
that is trivially solved.)
(From OE-Core rev: 9069fef5dad5a873c8a8f720f7bcbc7625556309)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When extracting patches from a git repository with PATCHTOOL = "git" we
cannot assume that all patches will be UTF-8 formatted, so as with other
places in this module, try latin-1 if utf-8 fails.
This fixes UnicodeDecodeError running devtool update-recipe or devtool
finish on the openssl recipe.
(From OE-Core rev: 579e4d54a212d04cfece2c9fc0635d7ac1644058)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The change to preserve extended attributes in copytree() and
copyhardlinktree() (e591d69103a40ec4f76d1132a6039d9cb1555103)
resulted in an incorrect cp invocation in copyhardlinktree() when
the source directory contained hidden files.
This was because the passed src was modified in place but some code
paths expected it to remain unmodified from the passed value.
Resolve the issue by constructing a new source string, rather than
modifying the passed in string.
(From OE-Core rev: 2b9fdd8448c2c29418d1c3fca9fe1789466f09b4)
Signed-off-by: Joshua Lock <joshua.g.lock@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Changed deployment directory from DEPLOY_DIR_IMAGE to
IMGDEPLOYDIR to make sstate machinery to do final deployment and
generate manifest.
Renamed variable deploy_dir to deploy_dir_image in selftest code
to avoid confusion with DEPLOYDIR variable.
Updated the code of rootfs.py:Rootfs class to use IMGDEPLOYDIR variable
as it's now used as a new deployment destination.
(From OE-Core rev: 6d969bacc718e21a5246d4da9bf9639dcae29b02)
Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When using PATCHTOOL = "git", the user of the system is not really the
committer - it's the build system itself. Thus, specify "dummy" values
for username and email instead of using the user's configured values.
Various parts of the devtool code that need to make commits have also
been updated to use the same logic.
This allows PATCHTOOL = "git" and devtool to be used on systems where
git user.name / user.email has not been set (on versions of git where
it doesn't default a value under this circumstance).
If you want to return to the old behaviour where the externally
configured user name / email are used, set the following in your
local.conf:
PATCH_GIT_USER_NAME = ""
PATCH_GIT_USER_EMAIL = ""
Fixes [YOCTO #8703].
(From OE-Core rev: 765a9017eaf77ea3204fb10afb8181629680bd82)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Pass appropriate options to tar invocations in copytree() and
copyhardlinktree() to ensure that any extended attributes on the files
are preserved during the copy.
We have to drop the use cpio in "Copy-pass" mode in copyhardlinktree()
because cpio doesn't support extended attributes on files. Instead we
revert back to using cp with different patterns depending on whether
or not the directory contains dot files.
(From OE-Core rev: e591d69103a40ec4f76d1132a6039d9cb1555103)
Signed-off-by: Joshua Lock <joshua.g.lock@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Current functionality allows for the removal of certain packages
based on the read-only image feature. This patch extends this
functionality by adding the FORCE_RO_REMOVE variable, which will
remove these packages regardless of any image features.
[ YOCTO #9491 ]
(From OE-Core rev: cfb869ffd4c37c3cc8e6b3eb732c1a7b7cfc3cb0)
Signed-off-by: Stephano Cetola <stephano.cetola@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
LICENSE should be a superset of all LICENSE_<pkg> values. That is,
LICENSE should contain all licenses and LICENSE_<pkg> can be used to
"filter" this on a per-package basis. LICENSE_<pkg> shouldn't contain
anything that isn't specified in LICENSE.
This patch implements simple checking of LICENSE_<pkg> values. It does
do not do advanced parsing/matching of license expressions, but,
checks that all licenses mentioned in LICENSE_<pkg> are also specified in
LICENSE. A warning is printed if problems are found.
(From OE-Core rev: 0f4163a12ea431d0ba6265880ee1e557333d3211)
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>
Unfortunately to implenent multiconfig support in bitbake some APIs
had to change. This updates code in OE to match the changes in bitbake.
Its mostly periperhal changes around devtool/recipetool
[Will need a bitbake version requirement bump which I'll make when merging]
(From OE-Core rev: 041212fa37bb83acac5ce4ceb9b7b77ad172c5c3)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When we don't have uninative enabled there's more merging to be done in
the default configuration (SDK_EXT_TYPE = "full" which by default means
SDK_INCLUDE_TOOLCHAIN = "1") and there are likely files that already
exist in the sstate feed we're assembling, so we need to take care to
merge the directory contents rather than just moving the directories
over. Additionally we now only run this if uninative genuinely isn't
enabled (i.e. NATIVELSBSTRING is different to the fixed value of
"universal".)
In the process of fixing this I discovered an unusual behaviour in
os.rename() - when we're merging these feeds we're dealing with
hard-linked sstate artifacts, and whilst os.rename() is supposed to
silently overwrite an existing destination (permissions allowing), if
you have the source and destination as hardlinks to the same file then
the os.rename() call will just silently fail. As a result the code now
just checks if the destination exists and deletes the source if so
(since we know it will be the same file, we don't need to check in this
case.)
(From OE-Core rev: 2b5b920c6b4f4d5c243192aa75beff402fd704d3)
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 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.
This allows us to reduce the time that the rpm.lock is held to only the
time needed to hardlink the RPMs, allowing the majority of the rootfs
operation to run in parallel.
Also, this fixes the smart tests by generating an index for all packages
at the time of the test, rather than using the one provided by the
rootfs process.
Original credit for the enhancement should go to Steven Walter
stevenrwalter@gmail.com.
(From OE-Core rev: a92c196449c516fe51786d429078bbb1213bb029)
Signed-off-by: Stephano Cetola <stephano.cetola@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Monitoring the process started by gnome-terminal was
spinning in a busy-loop. Insert some sleeping so that
we don't eat all the cpu.
(From OE-Core rev: 314937429d700204f296cfd1c0c5f215a2e5b939)
Signed-off-by: Jacob Kroon <jacob.kroon@gmail.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If you supplied an empty file to patch_recipe() (or an empty list to
patch_recipe_lines()) then the result was IndexError because the code
checking to see if it needed to add an extra line of padding didn't
check to see if there were in fact any lines before trying to access the
last line.
Fixes [YOCTO #9972].
(From OE-Core rev: 92a73e870478ddb2a2d137e3fff28828809bec2e)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Use the new oe-check-sstate to filter the sstate artifacts shipped with
the extensible SDK by effectively running bitbake within the produced
eSDK and and getting it to tell us which tasks it will restore from
sstate. This has several benefits:
1) We drop the *-initial artifacts from the minimal + toolchain eSDK.
This still leaves us with a reasonably large SDK for this
configuration, however it does pave the way for future reductions
since we are actually filtering by what will be expected to be there
on install rather than hoping that whatever cuts we make will match.
2) We verify bitbake's basic operation within the eSDK, i.e. that
we haven't messed up the configuration
3) We verify that the sstate artifacts we expect to be present are
present (at least in the sstate cache for the build producing the
eSDK). Outside deletion of sstate artifacts has been a problem up to
now, and this should at least catch that earlier i.e. during the
build rather than when someone tries to install the eSDK.
This does add a couple of minutes to the do_populate_sdk_ext time, but
it seems like the most appropriate way to handle this.
Should mostly address [YOCTO #9083] and [YOCTO #9626].
(From OE-Core rev: 4b7b48fcb9b39fccf8222650c2608325df2a4507)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If we're to completely replace the standard SDK with the extensible SDK,
we need to be able to provide the standard toolchain on install without
doing anything other than installing it, so that you can install the SDK
and then point your IDE at it. This is particularly applicable to the
minimal SDK which normally installs nothing by default.
NOTE: enabling this option currently adds ~280MB to the size of the
minimal eSDK installer. If we need to reduce this further we would have
to look at adjusting the dependencies and/or the sstate_depvalid()
function in sstate.bbclass which eliminates dependencies, or look at
reducing the size of the artifacts themselves.
Implements [YOCTO #9751].
(From OE-Core rev: ed0d8ed72370df694f720cc13897493478dc1de9)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
tar's --no-recursion flag only applies to files mentioned after the
flag, which made it a no-op in this invocation of tar, because it was at
the end of the command line.
This is simple to verify with GNU tar 1.29:
| $ mkdir foo
| $ mkdir foo/dir
| $ touch foo/dir/file
| $ tar -cf - foo --no-recursion | tar t
| foo/
| foo/dir/
| foo/dir/file
| $ tar -cf - --no-recursion foo | tar t
| foo/
Modify the code so that it actually does what the comment says by moving
the flag in front of the --files-from argument.
(From OE-Core rev: d45f5e71fef5ffbd4408f69c5c179dc71a3eb452)
Signed-off-by: Clemens Lang <clemens.lang@bmw-carit.de>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
oe.utils.getstatusoutput() is a wrapper for subprocess.getstatusoutput() which
uses Universal Newlines, so the output is a str() not bytes().
(From OE-Core rev: ce24d4c3632b71939ad198268a900ee823a89b27)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
It is possible in an attempt only install, that everything listed is not
available to be installed. This will have the effect of clearing the
package list. However, we only check for an empty package list at
the beginning of the function. We need to also check before running the
install, otherwise we can fail due to 'error: no package(s) given".
(From OE-Core rev: 9ae6a2830dacb3c335754a6da91bd5cc30546b31)
Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
Signed-off-by: Mingli Yu <mingli.yu@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When using PR service the buildhistory-diff output contains a lot of
PKGR changes: In practice the mass of PKGR updates hide other important
changes as they often account for 80% of all changes.
Skipped incremental and decremental changes of PKGR versions to reduce
amount of the script output. All changes are still included in the
output if script is run with -a/--report-all command line option.
[YOCTO #9755]
(From OE-Core rev: a343788b11f6c4f92ae8d2035fe8cb54f922227e)
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 task runs all functions in IMAGE_QA_COMMANDS after the image
construction has completed in order to validate the resulting image.
Image sanity checks should either be Python functions which raise
bb.build.FuncFailed on failure or shell functions with return a
non-zero exit code.
Python functions may instead raise an oe.utils.ImageQAFailed
Exception which takes an extra argument, a description of the
failure.
python image_check_python_ok () {
if True:
raise bb.build.FuncFailed('This check always fails')
else:
bb.note("Nothing to see here")
}
image_check_shell_ok () {
if true
exit 1
else
exit 0
fi
}
[YOCTO #9448]
(From OE-Core rev: c9bef2ecf1a30159d11781184829f41844a58c13)
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>
Add a subcommand which will "finish" the work on a recipe. This is
effectively the same as update-recipe followed by reset, except that the
destination layer is required and it will do the right thing depending
on the situation - if the recipe file itself is in the workspace (e.g.
as a result of devtool add), the recipe file and any associated files
will be moved to the destination layer; or if the destination layer is
the one containing the original recipe, the recipe will be overwritten;
otherwise a bbappend will be created to apply the changes. In all cases
the layer path can be loosely specified - it could be a layer name, or
a partial path into a recipe. In the case of upgrades, devtool finish
will also take care of deleting the old recipe.
This avoids the user having to figure out the correct actions when
they're done - they just do "devtool finish recipename layername" and
it saves their work and then removes the recipe from the workspace.
Addresses [YOCTO #8594].
(From OE-Core rev: fa550fcb9333d59b28fc0e4aebde888831410f5c)
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 provides us with the information we need to remove the original
version recipe and associated files when running "devtool finish" after
"devtool upgrade".
(From OE-Core rev: 92eb42c347af919cd9f8739515fdf806c12b5ba8)
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>
* Allow the function to be called with the base layer path (in which
case it will just return the same path)
* Ensure that the function doesn't recurse indefinitely if it's called
on a file that's not inside a layer
* Correct the doc comment for accuracy
(From OE-Core rev: 912026d85c2f535be2f60c45979162ea25c7f356)
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>
During a parallel build it's possible for unrelated shlib files to be removed if
the recipe they came from is about to be rebuilt. They can't be involved in the
dependency chains as otherwise they wouldn't be removed, so just silently handle
files disappearing.
[ YOCTO #8555 ]
(From OE-Core rev: 1e355da3fda742c78d99ddd2ee5caa9df52f92e1)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
With Python 3, the encoding of a file is significant; several recipes in
OE-Core have patches which are not fully utf-8 decodable e.g. man,
lrzsz, and gstreamer1.0-libav, leading to errors when using devtool's
modify, upgrade or extract subcommands on these recipes. To work around
this, try reading the patch file as utf-8 first and if that fails try
latin-1 before giving up.
(From OE-Core rev: 7f4d7a6f51569954e204f110827a8ce256bcdc68)
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 the new pid monitoring code we have for recent versions of
gnome-terminal we can just drop the --disable-factory code now since
the other solution handles this case as well.
(From OE-Core rev: ed4957c444a2982c19e2f1f96d9afb2a992c1daf)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Currently gnome-terminal just returns straight away, opening a terminal in a new
separate process we have no insight into. For patch resolution, this leads to
spawning many different terminal windows, for pydevshell, it just flashes a window
up and then closes.
We need to block until the command completes but gnome-terminal gives us no way
to do this. We therefore write the pid to a file using a "phonehome" wrapper
script, then monitor the pid until it exits.
[YOCTO #7254]
(also fixing do_devpyshell)
(From OE-Core rev: 76e8ab47c936674b8bb9bf1c48de53b30f5bf74a)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This was a copy-and-paste of subprocess.check_output() from when we supported
Python <2.7, so simply delete it and use subprocess.check_output() instead.
(From OE-Core rev: b1f2d9ed8d4dc89c9e669f43f546463ccc2a76b9)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If we're building the extensible SDK we don't need to see the "Writing
locked sigs" message; it's only necessary when the user explicitly runs
bitbake -S none <target>.
(From OE-Core rev: 440a351ee13920045c9d3e51882908f7b3f01d35)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Use the new task progress functionality to report progress during
do_rootfs. This is a little coarse and ideally we would have some
progress within the installation section, but it's better than
nothing.
(From OE-Core rev: 370f08d434480c1790950e40db8f7687da78cb14)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
In RpmPM:insert_feeds_uris, the paths are kept in sets, which are unordered,
but they are later used to set the priority for the Smart channels, so
unexpected results could occur. Change the sets to lists and use the same
code as in create_configs() to add items to the list, rather than the set
operators.
[YOCTO #9717]
(From OE-Core rev: ce4137f4bb955207fede0c4ef338835d9a461f59)
Signed-off-by: Bill Randle <william.c.randle@intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Specify tmpdir for opkg via '-t' option so that opkg does not use
the default 'TMPDIR' which usually is '/tmp' on build host.
This would solve race problems like below.
sh: /tmp/opkg-rOG6Tl/opkg-intercept-iPoEp5/depmod: Permission denied
(From OE-Core rev: 5665e284b7e7ee071201664dc50a3412bd4ac8cd)
Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Order is not preserved in dict() and this code depends on the order of
these lists of package architectures used when multilibs are enabled.
This caused 'random' breakage where sometimes the correct order was present
and sometimes it wasn't.
Use collections.OrderedDict() to avoid this problem.
Kudos to Bill Randle and Alejandro Hernandez who did most of the work debugging
this, I simply took the problem they identified and wrote a patch to fix it.
This unblocks the M1 build but this code needs auditing as there are clearly
other ordering issues (e.g. the set() usage).
[YOCTO #9717]
(From OE-Core rev: 61a33582dfc964d612d20d34734a787d873e312c)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
create_socket: Use urllib because urllib2 is now urllib in python3
and proxies as argument are deprecated so export them in the environ
instead.
get_links_from_url: Change usage of sgmllib for parsing HTML because
is deprecated in python 3, use instead bs4 that is already imported
in the bitbake tree.
[YOCTO #9744]
(From OE-Core rev: ee26ecf58277560459dd01992bb3f486f92c1531)
Signed-off-by: Aníbal Limón <anibal.limon@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
On python 3, bytes variable types must be decoded if these are intended to be
used as strings, otherwise we get the following error exception:
TypeError: Type str doesn't support the buffer API
(From OE-Core rev: b950539c911b7945d652b05616164828e711ac7f)
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>
Adds decoding needed by some commands output later used as
strings.
[YOCTO #9702]
(From OE-Core rev: 0440b5ace411c61f802376d4e1c9eac93e72d65f)
Signed-off-by: Mariano Lopez <mariano.lopez@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
string.rstrip() doesn't exist in Python 3, so use the .rstrip method on the
object itself instead.
(From OE-Core rev: 554719e3f65e468f89a96d4869766d3ff7a8012e)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The read method of the data_stream File object now returns bytes,
not a str, so we must decode it.
(From OE-Core rev: cfae302c4996c49a8754497ea9f13f8331d6975d)
Signed-off-by: Joshua Lock <joshua.g.lock@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The bytes type variables are threat different as strings variables in python3,
so convert bytes to strings. This was found when using the
script buildhistory-diff, where the interpreter was yielding this error
TypeError: Type str doesn't support the buffer API
(From OE-Core rev: 3064d36186b47954eb94095217f7bb37e3fce651)
Signed-off-by: Leonardo Sandoval <leonardo.sandoval.gonzalez@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This patch contains all the other misc pieces of the transition to
python3 which didn't make sense to be broken into individual patches.
(From OE-Core rev: fcd6b38bab8517d83e1ed48eef1bca9a9a190f57)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Moved call of decode('utf-8') as close as possible to
call of subprocess API to avoid calling it in a lot of
other places.
Decoded binary data to utf-8 where appropriate to fix devtool
and recipetool tests in python 3 environment.
(From OE-Core rev: 30d02e2aa2d42fdf76271234b2dc9f37bc46b250)
Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
xrange() no longer exists in python 3, use range()
(From OE-Core rev: d022b4335100612d6596cc4c4956cb98ed5873cc)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Iterators now return views, not lists in python3. Where we need
lists, handle this explicitly.
(From OE-Core rev: caebd862bac7eed725e0f0321bf50793671b5312)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
python3 standardises its use of iteration operations. Update
the code to match the for python3 requires.
(From OE-Core rev: 2476bdcbef591e951d11d57d53f1315848758571)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
In python3, strings are unicode by default. We need to encode/decode
from command pipelines and other places where we interface with the
real world using the correct locales. This patch updates various
call sites to use the correct encoding/decodings.
(From OE-Core rev: bb4685af1bffe17b3aa92a6d21398f38a44ea874)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The syntax for octal values changed in python3, adapt to it.
(From OE-Core rev: 737a095fcde773a36e0fee1f27b74aaa88062386)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Add some more variables in appropriate places in recipe_progression such
that the patch_recipe_* functions are able to insert variables in the
right place within a recipe.
(From OE-Core rev: c33ba6cc5d14b1da96f6d906836c50e0346dcf06)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This function was assuming that what you wanted was that output lines
had trailing newline characters. If you're just outputting each line
verbatim to a text file then that's fine, but sometimes you start with
the assumption that the lines don't have trailing newlines; thus we
shouldn't allow for the possibility that the caller doesn't want them
and add a parameter to control it.
(From OE-Core rev: fb2bb509ff5c7bd71b41a1dcba3b1bff1d18cf5d)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Split out a function from patch_recipe_file() that takes just the lines
as input so we can edit recipe lines in memory. This will be used within
recipetool to ensure we insert new values in the right place.
(From OE-Core rev: d780642f950fb3a9699f466a405a2710d870dd08)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Having the package path with all the other package info allows to
reuse more code and have this information outside the package manager,
without additional processing.
[YOCTO #8536]
(From OE-Core rev: 343f762792cbfccffaf3aa901289f9bb0f8cef3d)
Signed-off-by: Mariano Lopez <mariano.lopez@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Update older exception syntax to modern one required by python 3.
Compatible with python 2.7.
(From OE-Core rev: d13f0ac614f1d1e2ef2c8ddc71cbfcf76a8dc3f2)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Jianxun Zhang
Paul Eggleton
Richard Purdie
Ross Burton
Joshua Lock
Ed Bartosh
Stephano Cetola
Martin Vuille
Linus Wallgren
Samuli Piippo
Robert Yang
Davis, Michael
Peter Kjellerstedt
Mark Hatle
Hongxu Jia
Joshua Lock
Markus Lehtonen
Jacob Kroon
Clemens Lang
Bill Randle
Chen Qi
Aníbal Limón
Leonardo Sandoval
Mariano Lopez
Jussi Kukkonen