The imp python module is the forerunner of importlib. Include imp in
the importlib subpackage instead of the misc subpackage so that it can
be depended on without bringing in a bunch of unrelated, unused modules.
(Slightly modified backport of afd9de380d
by George McCollister <george.mccollister@gmail.com>)
[YOCTO#11134]
(From OE-Core rev: 65f6010346c08bf90f381a2d834dd9908ba2100c)
Signed-off-by: Juro Bystricky <juro.bystricky@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Add missing dependency on nativesdk-python3-importlib so the imp Python
module is installed.
Before this patch, running gdb from the sdk would give the following
error:
Python Exception <class 'ImportError'> No module named 'imp':
(From OE-Core rev: ad00a31fbe93e073a2d83616efcd08c5a7ef37c9)
(From OE-Core rev: d6e7dc5cbf1cc09c8882a717cd4dd34d10ec7fa3)
Signed-off-by: George McCollister <george.mccollister@gmail.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If an SSL/TLS server or client is running on a 32-bit host, and a
specific cipher is being used, then a truncated packet can cause that
server or client to perform an out-of-bounds read, usually resulting
in a crash.
Backported from:
8e204996292198b3a55d
* CVE: CVE-2017-3731
Upstream-status: Backport
(From OE-Core rev: 1fe1cb3e6e03b4f7f0d30b2b67edc8809a18fe70)
Signed-off-by: Alexandru Moise <alexandru.moise@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When using an alternative as an initscript, the ordering between
update-rc.d and update-alternatives tasks during prerm and postinst
tasks must always be the following in order to work:
* prerm:
- stop daemon
- remove alternative
* postinst:
- add alternative
- start daemon
This patchset adds comments to the scripts generated by both classes and
organize the generated sections based on those comments.
[YOCTO #10433]
(From OE-Core rev: b0c70bef015f1b2a30556a5db5e255592d5bf316)
Signed-off-by: David Vincent <freesilicon@gmail.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
(cherry picked from commit aa87b1a4dcc14e4dfe719b6c55045c5662bc59c2)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
During normal bitbake execution, the environment is cleaned of variables
not on a whitelist while starting up cooker, and then restored
afterwards. Prior to the tinfoil2 rework in master we were taking a
number of shortcuts within tinfoil and one of those was not doing this
environment cleaning. However, prior to OE-Core rev
3d39ca5c91dbb62fb43199f916bd390cd6212e3d we didn't have any code (as far
as I'm aware) that was affected by this shortcut, hence why this wasn't
an issue up to now.
The result is the following error when attempting to run "devtool build"
in the eSDK, as CCACHE_PATH is allowed through from the eSDK's
environment setup script:
----------- snip -----------
ccache: error: Could not find compiler "gcc" in PATH
...
subprocess.CalledProcessError: Command 'gcc --version' returned
non-zero exit status 1
----------- snip -----------
We can fix this by simply doing the environment filtering while we are
starting up cooker, thus the environment when uninative.bbclass comes to
do the gcc version check it is not affected by CCACHE_PATH or other
variables in the external environment that should be filtered out.
For clarity, this patch is only applicable to the bitbake 1.32 branch
as used for the OE-Core morty branch - master uses the reworked
tinfoil2 and doesn't need this fix.
Fixes [YOCTO #10961].
(Bitbake rev: a240f5ff71092cb209c44a071cd6fa07756ccfa0)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
I noiced builds where tasks seemed to be taking a surprisingly long time.
When I looked at the output of top/pstree, these tasks were no longer
running despite being listed in knotty. Some were in D/Z state waiting for
their exit code to be collected, others were simply not present at all.
strace showed communication problems between the worker and cooker, each
was trying to write to the other and nearly deadlocking. Eventually, timeouts
would allow them to echange 64kb of data but this was only happening every
few seconds.
Whilst this particularly affected builds on machines with large numbers
of cores (and hence highly parallal task execution) and in cases where
I had a lot of debug enabled, this situation is clearly bad in general.
This patch introduces a thread to the worker which is used to write data
back to cooker. This means that the deadlock can't occur and data flows
much more freely and effectively.
(Bitbake rev: f48befe1163147b02a9926ee38af0f7258a477e0)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Fixes [YOCTO #10889]
Missing this package. Speculation is that this package was
part of the Python 2.7 stuff but not Python 3. So, adding it
clears the issue up.
(From yocto-docs rev: fc6bfab923f18a8ec91e29fed2404690d0afeb5d)
Signed-off-by: Scott Rifenbark <srifenbark@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Fixes following error in configure:
FATAL ERROR: msgfmt does not seem to be installed.
attr cannot be built without a working gettext installation.
(From OE-Core rev: 85e087d9b323ad87c59900f01aad751c9c7a9e3a)
Signed-off-by: Denys Dmytriyenko <denys@ti.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
(From OE-Core rev: d044fad8a0ac5d57deb88b25106f3a39cb7c1636)
Signed-off-by: Denys Dmytriyenko <denys@ti.com>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The use of awk -F "." in do_install/do_deploy to strip filename extension
was deprecated long time ago in 72980d5bb465f0640ed451d1ebb9c5d2a210ad0c.
Make a similar change in postinst/postrm to properly use basename command.
Otherwise DTB files that contain dots in the name result in broken symlinks
that point to non-existent truncated files.
(From OE-Core rev: ed0f9cf63cb1226f9d92377e13ef63e36a95d29d)
Signed-off-by: Denys Dmytriyenko <denys@ti.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
(From OE-Core rev: 40c2addf0f0ee16b1c1334cf00f1490ffeaac475)
Signed-off-by: Denys Dmytriyenko <denys@ti.com>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
With enabled SSTATE_MIRRORS sstate code expects mirrors to
contain entries for all tasks, which is not the case for ext
installer as it uses reduced sstate cache.
Added do_package tasks to BB_SETSCENE_ENFORCE_WHITELIST to prevent
installer failing with ERROR: Sstate artifact unavailable
[YOCTO #10832]
(From OE-Core rev: 2ed46ada4b8e496493835e84b36f7e9c367f59d2)
(From OE-Core rev: eb2fc2cd9081a4533ed30fe81c9f491b06cc5ae1)
Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Mapped uninative sstate directories to make ext SDK installer to
use them when it's run on systems with gcc version different from
gcc version used to build installer.
[YOCTO #10832]
(From OE-Core rev: fb945c0fd2e66d70461e6cf2e602020eeabe32f7)
Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Upstream have removed the file from zlib.net as a new version has
been released, switch to fetching from the official sourceforge
mirror.
[YOCTO #10879]
(From OE-Core rev: bb99e4a620efd59556539c156cd98ea23aae74c8)
(From OE-Core rev: b7599330f1d629384e16a5fbeffc1a65c1555667)
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>
* poky.ent - changed variables appropriately for 2.2.1
* <manual> - updated the manual revision tables to have a new
2.2.1 entry indicating a "January 2017" release
* mega-manual.sed - Updated the "2.2" string to "2.2.1" so
links will work.
(From yocto-docs rev: 20eeccff9fdad25f7b21aa6326999deb3d58abc4)
Signed-off-by: Scott Rifenbark <srifenbark@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Fixes [YOCTO #7096]
Applied a couple review comments to the section to clarify where
to set key variables. Also fixed an incorrect variable name used
to specify the *.cpio file.
(From yocto-docs rev: 1ef9bb89057be46878a70c558268b5ace43967f8)
Signed-off-by: Scott Rifenbark <srifenbark@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Fixes [YOCTO #10763]
The final example in the section describing how to create
the base recipe using receipetool create was wrong. I updated
it to use the -d option in addition to the -o opetion. I also
changed the description to match appropriately.
(From yocto-docs rev: 749970f4394af3855751c776689b7002232f2d13)
Signed-off-by: Scott Rifenbark <srifenbark@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Fixes [YOCTO #7096]
We did not document how to create an initramfs image to be included
with a kernel build. Various variables sort of inferred the
knowledge. I created a new section in the "Common Tasks" section
of the dev-manual that describes how to create an initramfs image.
Also, I updated the kernel.bbclass reference section to point back
to the new "how-to" section.
Finally, I also created a bunch of cross-reference links from various
related variables back to the new "how-to" section.
(From yocto-docs rev: a14e550494641c46ac2518632cbf251e07d459fd)
Signed-off-by: Scott Rifenbark <srifenbark@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This term was incorrect and I have replaced it with the
term "partitioned."
(From yocto-docs rev: af1bf889bf862b1bc861de72888a82e25997ab71)
Signed-off-by: Scott Rifenbark <srifenbark@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
new information on how wic works
(From yocto-docs rev: c5bfbba2bc810eb1ff8825b66aa1397cfeed8ce1)
Signed-off-by: Scott Rifenbark <srifenbark@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This new variable points to the location of the wics kickstart
file.
(From yocto-docs rev: 6d9a7220ed41c8a512eccbad0ae170072d40fc6f)
Signed-off-by: Scott Rifenbark <srifenbark@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Fixes [YOCTO #10714]
Apparently there is some issues with GTK3 libraries for the Mars
Eclipse version. The note provides a workaround that requires
editing the eclipse.ini file.
(From yocto-docs rev: 89ace71c6d9d3a9db84bb9bb2b2abe4779a516f6)
Signed-off-by: Scott Rifenbark <srifenbark@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This fixes an error such as:
Exception: File "/master/poky/meta-yocto-bsp/lib/oeqa/controllers/edgeroutertarget.py", line 47
self.image_fstype = self.get_image_fstype(d)
TabError: inconsistent use of tabs and spaces in indentation
(From meta-yocto rev: 5ff5dc2767dfef93c314e7465a52ca2dce553604)
(From meta-yocto rev: d1c50ea67f53b5fa2618b460efe4cc879d7cee0c)
Signed-off-by: Juro Bystricky <juro.bystricky@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
People are struggling with multiconfig as the point the conf file
is injected into the data store is not what people expect. We can't
really use a post config since that is too late and we can't really
use a pre config file since that is too early. In OE terms, we need
something right around the local.conf point so it behaves in a similar
way.
A way to handle this is to set the new variable BB_CURRENT_MC to be the
currently selected multiconfig, then the metadata itself can choose
when to inject the approriate configuration.
(Bitbake rev: 1469828fa747da0aaaa3e964954ff17f2b3180fa)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Fakeroot workers usually have dependencies that need to be ready before they
can be started. Starting them as a block therefore doesn't work as the
dependencies may or may not have been built. Therefore start the multiconfig
fakeworkers individually upon demand.
[YOCTO #10344]
(Bitbake rev: ac5ea74152b011256209c8b5664216f290b123e8)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
In multiconfig, mutliple tasks can execute which share the same stamp file. These
must not execute in parallel, the idea is the first should execute, the subsequent
ones should see a valid stamp and get skipped.
The normal task execution code has stamps code to handle this, this adds similar
code to the setscene execute() function to handle the issue there too.
(Bitbake rev: df8408a6b54fc908d4de81529b34477b8924d181)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
setscene was being entirelu skipped for multiconfig variants as the tasks
were simply not being spotted. If the default config was also being built
it masked the problem. When this was fixed by using taskfn instead of fn
in lookups against dataCache, several other instances of this problem were
highlighted.
This goes through and corrects the setscene code to correclty use taskfn
instead of fn in the appropriate places meaning setscene tasks for multiconfig
now work correctly.
(Bitbake rev: a5d81eefe9106f2080001b7313e2b15ab21ea55b)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Tasknames can now start with "multiconfig:" which broke the virtual: comparison code and
lead to unpredictable checksums with nativesdk recipes. This adds in handling for
the new additional prefix which unbreaks nativesdk builds when using multiconfig.
(Bitbake rev: 0ca6b8438624d892ee7ef3b42df0024604b64567)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Currently the UI shows X is building, possibly multiple times but doesn't
say which of the multilibs that might be. This adds a prefix to the task
name so the mulitconfig being built can be identified.
(Bitbake rev: dfb775c67a96a79f3b85104870c0ade46ef2a9ea)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The location of the fakeroot command and the various environmental values need
to be taken from the right multiconfig datastore, not the shared one. This
patch ensures the right one is used for cases like a split TMPDIR.
[YOCTO #10344]
(Bitbake rev: c241f16670cada2cdf45ecddb4961e16edb83486)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If many files change and the inotify queue overflows, rather than print
a traceback, invalidate the caches and warn the user.
[YOCTO #10676]
(Bitbake rev: 058f8517c041b80e8b591ad7d34a68281b2d03fc)
(Bitbake rev: 4fafb6c6d261de78dd1bc3824a1389d191b70321)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The processing of the "do_" prefix to tasks is currently inconsistent
and has resulted in "bitbake world -g" being broken as task prefixes
don't get handled correctly.
Make the "do_" task prefix handling consistent through various codepaths.
[YOCTO #10651]
(Bitbake rev: 3d7186353e804c9410096c408bc337a98c8b33fe)
(Bitbake rev: 100439e715841ecfd6460d59cd51c831184b328d)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
nativesdk-libgcc doesn't need a symlink into the target space and if we do this
sstate installation of the recipe can fail depending on whether it races with
the cross-canadian toolchains.
(From OE-Core rev: b2c1e1fe4221862e0dbf5d08960f0d0228e47c72)
(From OE-Core rev: 62012e81c6f7aaad5d9c5e8bec2e2417433572e3)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
People are strugling with multiconfig as the up front inclusion of the
configuration file doesn't do what people expect. The only way to meet
user expectations is to include the file immediately after local.conf.
We add BB_CURRENT_MC to bitbake so that the metadata can determine when
to include the extra configuration.
(From OE-Core rev: a6a3894fb2cb2097d2404b8b8cb2b85df595cfa9)
(From OE-Core rev: 378ba0c92172ed7850ec1b0eb2971afb0dae427b)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This means that a user can change TMPDIR in a multiconfig situation
and still only have one path to the uninative setup. Without this change
its not possile to make such a setup work.
(From OE-Core rev: 779422c5458f5f643b3a4a0dedaa4d9ad709367a)
(From OE-Core rev: f50547fb9d70a8ae079380c25e697da3d2c2b181)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
