Stephano Cetola [Mon, 3 Oct 2016 23:32:45 +0000 (16:32 -0700)]
utils.bbclass: add function to check for git config user
If attempting to patch a git repo without a proper git config setup,
an error will occur saying user.name/user.email are needed by git
am/apply. After some code was removed from kernel-yocto, it was
simple enough to reproduce this error by creating a kernel patch and
using a container to build.
This patch abstracts out functionality that existed in buildhistory
for use in other classes. It also adds a call to this functionality
to the kernel-yocto class.
Michael Wood [Thu, 6 Oct 2016 00:08:54 +0000 (17:08 -0700)]
bitbake: toaster: Update tests to reflect front end changes
- Browser test we changed the project heading access to use the class name
- Update toastergui unit test for additional gotoUrl property
- On faster browsers we had a race for layer details inputs being
visible
Michael Wood [Thu, 6 Oct 2016 00:08:52 +0000 (17:08 -0700)]
bitbake: toaster: importlayer Fix layer dependencies button state toggle
Fix regression introduced by switching typeahead library. Make sure we
enable and disable the add button based on whether the selection event
has fired or not.
Michael Wood [Thu, 6 Oct 2016 00:08:50 +0000 (17:08 -0700)]
bitbake: toaster: buildinfohelper: Use correct way to get message from LogMessage
Use the correct method to get a message value from the LogMessage object
rather than constructing it ourselves which is not recommended. This
causes an exception when the msg contains a '%' such as when there are
wildcards in file names (something2.%.bbappends)
Michael Wood [Thu, 6 Oct 2016 00:08:49 +0000 (17:08 -0700)]
bitbake: toaster: api / project Cancel any in progress builds before project delete
Before we finally delete any project make sure we send the cancel command to
any in-progress builds. This ensures that an inaccessible build doesn't block
up the system and that we don't get errors after deletion.
Scott Rifenbark [Tue, 4 Oct 2016 16:58:44 +0000 (09:58 -0700)]
bitbake: bitbake-user-manual: Added new section on BB-style functions
Fixes [YOCTO #10364]
Added a new section titled "Bitbake-Style Python Functions
Versus Python Functions". This section describes differences
for the user between the two types of functions.
Also, cleaned up a consistency problem with the terms
"BitBake style" and "BitBake-style". I used the latter
throughout the manual.
Scott Rifenbark [Wed, 21 Sep 2016 22:30:14 +0000 (15:30 -0700)]
bitbake: bitbake-user-manual: Added examples for using overrides with functions.
Fixes [YOCTO #10296]
This adds some bits clarifying you can append and prepend to
functions. Added a bit to the introduction paragraph of the
"Appending and Prepending (Override Style Syntax)" section to
note that you can do this. Referenced some new examples.
In the "Shell Functions" section I added an example. In the
"BitBake Style Python Functions" section I also added an example.
bavery [Thu, 6 Oct 2016 00:43:06 +0000 (17:43 -0700)]
uninative: users can override download site
The default download site for the uninative tarball is
http://downloads.yoctoproject.org/releases/uninative/<version>. There
are scenarios in which the user may need to force the download to be
somewhere else. This patch allows the UNINATIVE_URL to be set in the
local.conf.
Stephano Cetola [Wed, 5 Oct 2016 17:07:17 +0000 (10:07 -0700)]
devtool: modify command fails to ignore source files
With recent changes to recipeutils, the list of local files returned
by get_recipe_local_files could possibly include source files. This
only happens when the recipe contains a SRC_URI using subdir= to put
files in the source tree. These files should be ignored when
populating the list of local files for oe-local-files directory.
package_manager.py: Allow multiple regexps in PACKAGE_EXCLUDE_COMPLEMENTARY
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_manager.py: Allow a leading - in PACKAGE_EXCLUDE_COMPLEMENTARY
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 ...]
Markus Lehtonen [Wed, 5 Oct 2016 13:29:49 +0000 (16:29 +0300)]
oeqa.buildperf: measure apparent size instead of real disk usage
This change aligns disk usage measurements of the eSDK test with the old
build-perf-test.sh script. And thus, also makes the results between the
old and the new script comparable.
bavery [Mon, 3 Oct 2016 23:56:26 +0000 (16:56 -0700)]
bitbake: toaster: add Font Awesome license
Font Awesome fonts are bundled with the Toaster UI and are released
under the SIL Open Font License 1.1. This patch adds that information
to the LICENSE file.
bitbake: bb.build: in _exec_task, catch errors from TaskStarted
We don't always want a traceback when an exception is raised by the
TaskStarted event handler. Silently return if we get a SystemExit or
HandledException, and print the error and return for FuncFailed.
This is done via a separate try/catch block, to avoid firing TaskFailed if all
the TaskStarted event handlers didn't complete, otherwise the bitbake UIs get
unhappy.
Joshua Lock [Tue, 4 Oct 2016 10:03:55 +0000 (11:03 +0100)]
bitbake: event: prevent unclosed file warning in print_ui_queue
Use logger.addHandler(), rather than assigning an array of Handlers
to the loggers handlers property directly, to avoid a warning from
Python 3 about unclosed files:
$ bitbake
Nothing to do. Use 'bitbake world' to build everything, or run 'bitbake --help' for usage information.
WARNING: /home/joshuagl/Projects/poky/bitbake/lib/bb/event.py:143: ResourceWarning: unclosed file <_io.TextIOWrapper name='/home/joshuagl/Projects/poky/build/tmp/log/cooker/qemux86/20161004094928.log' mode='a' encoding='UTF-8'>
logger.handlers = [stdout]
Jussi Kukkonen [Tue, 4 Oct 2016 13:16:42 +0000 (16:16 +0300)]
gtk+3: Backport treeview focus fix
Treeview did not grab focus properly on mouse click, leading to e.g.
multifile selection with click/shift-click not working in the
filechooser. Backport a fix.
Bruce Ashfield [Wed, 5 Oct 2016 03:03:48 +0000 (23:03 -0400)]
linux-yocto/4.8: fix BUG_ON() in workingset_node_shadows_dec() triggers
Paul Gotmaker pointed out that a last minute merge to the 4.8 kernel
has the potential to hard hang a kernel when VM debugging is enabled:
https://lkml.org/lkml/2016/10/4/1
He also pointed out the fix for it in commit 21f54dda
[Using BUG_ON() as an assert() is _never_ acceptable].
While that fix will loop through -stable into 4.8.1, that will
likely be too late for our release. So I've cherry picked the
change to make it available.
Richard Purdie [Wed, 5 Oct 2016 07:55:11 +0000 (08:55 +0100)]
pigz: Update SRC_URI
Upstream have released a new tarball and removed the old one. Revert to
the Yocto Project source mirror instead, preserving the upstream version
check.
This patch brings the last bit from meta-mentor for the perf
to build successfully with minnowmax BSP. The meta-mentor
commit for the same is:
http://git.yoctoproject.org/cgit/cgit.cgi/meta-mentor/commit/meta-mentor-staging?id=a8db95c0d4081cf96915e0c3c4063a44f55e21cc
The previous fix:
http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/meta/recipes-kernel/perf?id=ef942d6025e1a339642b10ec1e29055f4ee6bd46
was incomplete and was not submitted upstream. And due to that this change is required.
When built on minnowmax ( machine name: intel-corei7-64),
an error is noticed during the do_compile:
/home/sujith/codebench-linux-install-2015.12-133-i686-pc-linux-gnu/codebench/bin/i686-pc-linux-gnu-ld:
Relocatable linking with relocations from format elf64-x86-64
(/home/sujith/MEL/dogwood/build-minnowmax/tmp/work/intel_corei7_64-mel-linux/perf/1.0-r9/perf-1.0/fd/array.o)
to format elf32-i386 (/home/sujith/MEL/dogwood/build-minnowmax/tmp/work/intel_corei7_64-mel-linux/perf/1.0-r9/perf-1.0/fd/libapi-in.o)
is not supported
The following patch comes from the realization that at least ARM code
for atomics is quite broken and nobody has cared for a decade.
A quick dive shows that only snd_atomic_{read,write}_{begin,end}
appear to be used widely. These are implemented using wmb/rmb.
Only other use of atomic functions is in pcm_meter.c.
The #SND_PCM_TYPE_METER plugin type appears rarely, if ever, used.
I presume these days anyone who wants a meter/scope will do in pulseaudio
layer instead of alsa.
It would seem better fit to have pcm_meter in alsa-plugins instead
of alsa-lib, but I guess that would be an ABI break...
So instead, I'm proposing here
1. Removal of all hand-crafted atomics from iatomic.h apart from barriers,
which are used in snd_atomic_{read,write}_{begin,end}.
2. Using __sync_synchronize as the default fallback for barriers. This
has been available since gcc 4.1, so it shouldn't be a problem.
3. Defining the few atomics used by pcm_meter.c withing pcm_meter.c
itself, using gcc atomic builtins[1].
4. Since gcc atomic builtins are available only since gcc 4.7, add a check for
that in gcc configure.in, and don't build pcm meter plugin if using
older gcc.
The last point has the impact, that if there actually is someone who 1)
uses the meter plugin 2) wants to upgrade to 2014 alsa-lib 3) but
does not want to use a 2012+ gcc - that someone will be inconvenienced.
Finally remove the unneeded configure check for cpu type. We can
trust the gcc to set right flags for us.
Signed-off-by: Andreas Müller <schnitzeltony@googlemail.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
devtool: deploy-target: Avoid unnecessary dependency on awk on the target
Relying on that awk is installed on the target just to extract the
fourth column (i.e., the free volume size) from `df -P` is an
unnecessary dependency for devtool deploy-target. As it is already
using sed to mangle the output from `df -P`, this can easily be
modified to only extract the free volume size.
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>
parselogs.py: Add disabling eDP error to x86_common whitelist
The NUC6 firmware tells the kernel to try and initialize an embedded
DisplayPort it does not have, causing this warning. Its harmless, so
just whitelist it.
Signed-off-by: California Sullivan <california.l.sullivan@intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
AnÃbal Limón [Tue, 4 Oct 2016 16:45:53 +0000 (11:45 -0500)]
classes/sstate.bbclass: Enable thread lock when checkstatus
The checkstatus function fires an event to notify bitbake UI about
the progress of the task, this function is implemented using ThreadPool
and is causing event lose when multiple threads tries to fire an event
(writes over socket/fd).
Jussi Kukkonen [Tue, 4 Oct 2016 07:17:27 +0000 (10:17 +0300)]
xf86-video-intel: Upgrade to recent git
Upgrade from the latest snapshot to a recent git revision.
Without this xvideo does not work on skylake: Backporting the
specific fixes turned out to be too complex.
Remove patches that are in upstream already, rebase
disable-x11-dri3.patch.
Jussi Kukkonen [Tue, 4 Oct 2016 11:27:26 +0000 (14:27 +0300)]
matchbox-panel-2: Fix small systray icon drawing
Add patch to pack systray icons so that their drawing area is the
size they expect (otherwise GtkStatusIcon based systray items can
end up drawing "tiled", looking like 1.5 icons instead of a single
icon).
Jussi Kukkonen [Tue, 4 Oct 2016 11:27:25 +0000 (14:27 +0300)]
Revert "connman-gnome: StatusIcon adapts to size changes"
The aim of the original commit was to make connman-gnome load the icons
at the exact size of the systray. There are two problems with this:
* There are not enough icon sizes provided to make the scaling
look good at most sizes (including current panel size)
* Both connman-gnome and mb-panel have bugs in the icon size update
code and using scaling to exact size makes these much more visible
(See bug 9995 for example).
The problems the original commit tried to fix can be worked around
with better packing in matchbox-panel-2.
Paul Eggleton [Tue, 4 Oct 2016 09:31:16 +0000 (22:31 +1300)]
devtool: add: build nodejs-native if npm is needed and not available
If the user runs devtool add on an npm:// URL (or source tree that uses
node.js), and npm is not available, just build nodejs-native instead of
telling the user they need to do it; if that fails because there isn't
any such recipe (which would be the default, since it's not in OE-Core)
then produce a slightly more readable error message hinting at what the
user needs to do.
Note that this forces the use of nodejs-native rather than npm on the
host - this makes sense for two reasons: (1) we need it to be compatible
with nodejs for the target, and (2) we have to have a recipe for that
anyway, so allowing you to avoid having a recipe for the native version
isn't really beneficial.
There's a bit of a hack in here in order to allow this - for node.js
sources that aren't fetched via npm we don't know that they are that
until we've fetched and unpacked them, by which time we're inside
recipetool and have an active tinfoil instance that will prevent bitbake
being run. To avoid this being an issue, we allow recipetool to get to
the point where we know we need npm and then exit with a specific exit
code, at which point devtool can try to build it and then if that
succeeds, it will re-execute recipetool. This is definitely not ideal,
but it can't really be refactored and done properly until we do the
tinfoil2 refactoring; in the mean time though we still want to be
helpful to the user.
Paul Eggleton [Tue, 4 Oct 2016 09:31:15 +0000 (22:31 +1300)]
devtool: add: display a warning for deprecated -f/--fetch option
We want to remove the -f/--fetch option at some point (as you can now
specify a URL as a positional argument instead) so display a warning
that it's deprecated if it is used.
Andre McCurdy [Tue, 4 Oct 2016 18:51:12 +0000 (11:51 -0700)]
base-files: don't export TZ="UTC" from /etc/profile
If no /etc/localtime (or /etc/TZ for uclibc) is found, then the libc
will default to UTC, so setting UTC as a fallback default via the TZ
environment variable is redundant.
Since having the TZ environment variable set causes /etc/localtime
to be ignored, it can cause confusion if /etc/localtime is added
interactively after /etc/profile has been run.
Ross Burton [Tue, 4 Oct 2016 15:37:53 +0000 (16:37 +0100)]
systemtap: rationalise dependencies
Boost is an optional dependency but avoid build non-determinism by adding it as
DEPENDS. It is only for the shared pointer types so can be disabled explicitly
if required.
Turn sqlite into a PACKAGECONFIG.
Add a patch for the "monitor" feature to control the optional dependencies on
ncurses and json-c. Previously this was enabled for target only but enable it
everwhere now that json-c is available for native/nativesdk.
Of course all of this was predicated about systemtap needing systemtap-native to
be built, but it turns out that this dependency is due to oe-core 507bd2 which
adds systemtap-native as DEPENDS for convenience. Remove this dependency, if
the user wants systemtap-native then they can build it explicitly.
Before standard/intel/* was created in the 4.1 and 4.4 kernel trees,
some patches were merged to standard/base to add features/support for
intel platforms.
While this isn't entirely bad, there have been some compile issues
reported in some configurations. Since we don't need these commits
on standard/base, we can relocate them to make standard/base upstream
clean.
This commit removes those patches from standard/base, and restores
then to the standard/intel/* branches.
include/uapi/linux/if_pppol2tp.h: include linux/in.h and linux/in6.h
Fixes userspace compilation errors like:
error: field <E2><80><98>addr<E2><80><99> has incomplete type
struct sockaddr_in addr; /* IP address and port to send to */
^
error: field <E2><80><98>addr<E2><80><99> has incomplete type
struct sockaddr_in6 addr; /* IP address and port to send to */
Signed-off-by: Mikko Rapeli <mikko.rapeli@iki.fi> Signed-off-by: David S. Miller <davem@davemloft.net>
commit eafe92114308acf14e45c6c3d154a5dad5523d1a
Author: Mikko Rapeli <mikko.rapeli@iki.fi>
Date: Mon Aug 22 20:32:43 2016 +0200
include/uapi/linux/if_pppox.h: include linux/in.h and linux/in6.h
Fixes userspace compilation errors:
error: field <E2><80><98>addr<E2><80><99> has incomplete type
struct sockaddr_in addr; /* IP address and port to send to */
error: field <E2><80><98>addr<E2><80><99> has incomplete type
struct sockaddr_in6 addr; /* IP address and port to send to */
Signed-off-by: Mikko Rapeli <mikko.rapeli@iki.fi> Signed-off-by: David S. Miller <davem@davemloft.net>
(From OE-Core rev: 12451a412fb7b5706c1553618ee7b704234876cc)
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Ulf Magnusson [Sat, 1 Oct 2016 02:47:11 +0000 (04:47 +0200)]
cmake: Use bb.fatal() instead of raising FuncFailed
This sets a good example and avoids unnecessarily contributing to
perceived complexity and cargo culting.
Motivating quote below:
< kergoth> the *original* intent was for the function/task to error via
whatever appropriate means, bb.fatal, whatever, and
funcfailed was what you'd catch if you were calling
exec_func/exec_task. that is, it's what those functions
raise, not what metadata functions should be raising
< kergoth> it didn't end up being used that way
< kergoth> but there's really never a reason to raise it yourself
FuncFailed.__init__ takes a 'name' argument rather than a 'msg'
argument, which also shows that the original purpose got lost.
Ulf Magnusson [Sat, 1 Oct 2016 02:47:10 +0000 (04:47 +0200)]
testimage.bbclass: Use bb.fatal() instead of raising FuncFailed
This sets a good example and avoids unnecessarily contributing to
perceived complexity and cargo culting.
Motivating quote below:
< kergoth> the *original* intent was for the function/task to error via
whatever appropriate means, bb.fatal, whatever, and
funcfailed was what you'd catch if you were calling
exec_func/exec_task. that is, it's what those functions
raise, not what metadata functions should be raising
< kergoth> it didn't end up being used that way
< kergoth> but there's really never a reason to raise it yourself
FuncFailed.__init__ takes a 'name' argument rather than a 'msg'
argument, which also shows that the original purpose got lost.
Ulf Magnusson [Sat, 1 Oct 2016 02:47:09 +0000 (04:47 +0200)]
utility-tasks.bbclass: Use bb.fatal() instead of raising FuncFailed
This sets a good example and avoids unnecessarily contributing to
perceived complexity and cargo culting.
Motivating quote below:
< kergoth> the *original* intent was for the function/task to error via
whatever appropriate means, bb.fatal, whatever, and
funcfailed was what you'd catch if you were calling
exec_func/exec_task. that is, it's what those functions
raise, not what metadata functions should be raising
< kergoth> it didn't end up being used that way
< kergoth> but there's really never a reason to raise it yourself
FuncFailed.__init__ takes a 'name' argument rather than a 'msg'
argument, which also shows that the original purpose got lost.
Ulf Magnusson [Sat, 1 Oct 2016 02:47:08 +0000 (04:47 +0200)]
package.bbclass: Use bb.fatal() instead of raising FuncFailed
This sets a good example and avoids unnecessarily contributing to
perceived complexity and cargo culting.
Motivating quote below:
< kergoth> the *original* intent was for the function/task to error via
whatever appropriate means, bb.fatal, whatever, and
funcfailed was what you'd catch if you were calling
exec_func/exec_task. that is, it's what those functions
raise, not what metadata functions should be raising
< kergoth> it didn't end up being used that way
< kergoth> but there's really never a reason to raise it yourself
FuncFailed.__init__ takes a 'name' argument rather than a 'msg'
argument, which also shows that the original purpose got lost.
Ulf Magnusson [Sat, 1 Oct 2016 02:47:07 +0000 (04:47 +0200)]
libc-package.bbclass: Use bb.fatal() instead of raising FuncFailed
This sets a good example and avoids unnecessarily contributing to
perceived complexity and cargo culting.
Motivating quote below:
< kergoth> the *original* intent was for the function/task to error via
whatever appropriate means, bb.fatal, whatever, and
funcfailed was what you'd catch if you were calling
exec_func/exec_task. that is, it's what those functions
raise, not what metadata functions should be raising
< kergoth> it didn't end up being used that way
< kergoth> but there's really never a reason to raise it yourself
FuncFailed.__init__ takes a 'name' argument rather than a 'msg'
argument, which also shows that the original purpose got lost.
Ulf Magnusson [Sat, 1 Oct 2016 02:47:06 +0000 (04:47 +0200)]
testsdk.bbclass: Use bb.fatal() instead of raising FuncFailed
This sets a good example and avoids unnecessarily contributing to
perceived complexity and cargo culting.
Motivating quote below:
< kergoth> the *original* intent was for the function/task to error via
whatever appropriate means, bb.fatal, whatever, and
funcfailed was what you'd catch if you were calling
exec_func/exec_task. that is, it's what those functions
raise, not what metadata functions should be raising
< kergoth> it didn't end up being used that way
< kergoth> but there's really never a reason to raise it yourself
FuncFailed.__init__ takes a 'name' argument rather than a 'msg'
argument, which also shows that the original purpose got lost.
Ulf Magnusson [Sat, 1 Oct 2016 02:47:05 +0000 (04:47 +0200)]
chrpath.bbclass: Use bb.fatal() instead of raising FuncFailed
This sets a good example and avoids unnecessarily contributing to
perceived complexity and cargo culting.
Motivating quote below:
< kergoth> the *original* intent was for the function/task to error via
whatever appropriate means, bb.fatal, whatever, and
funcfailed was what you'd catch if you were calling
exec_func/exec_task. that is, it's what those functions
raise, not what metadata functions should be raising
< kergoth> it didn't end up being used that way
< kergoth> but there's really never a reason to raise it yourself
FuncFailed.__init__ takes a 'name' argument rather than a 'msg'
argument, which also shows that the original purpose got lost.
Ulf Magnusson [Sat, 1 Oct 2016 02:47:04 +0000 (04:47 +0200)]
sstate.bbclass: Use bb.fatal() instead of raising FuncFailed
This sets a good example and avoids unnecessarily contributing to
perceived complexity and cargo culting.
Motivating quote below:
< kergoth> the *original* intent was for the function/task to error via
whatever appropriate means, bb.fatal, whatever, and
funcfailed was what you'd catch if you were calling
exec_func/exec_task. that is, it's what those functions
raise, not what metadata functions should be raising
< kergoth> it didn't end up being used that way
< kergoth> but there's really never a reason to raise it yourself
FuncFailed.__init__ takes a 'name' argument rather than a 'msg'
argument, which also shows that the original purpose got lost.
Ulf Magnusson [Sat, 1 Oct 2016 02:47:03 +0000 (04:47 +0200)]
useradd.bbclass: Use bb.fatal() instead of raising FuncFailed
This sets a good example and avoids unnecessarily contributing to
perceived complexity and cargo culting.
Motivating quote below:
< kergoth> the *original* intent was for the function/task to error via
whatever appropriate means, bb.fatal, whatever, and
funcfailed was what you'd catch if you were calling
exec_func/exec_task. that is, it's what those functions
raise, not what metadata functions should be raising
< kergoth> it didn't end up being used that way
< kergoth> but there's really never a reason to raise it yourself
FuncFailed.__init__ takes a 'name' argument rather than a 'msg'
argument, which also shows that the original purpose got lost.
Ulf Magnusson [Sat, 1 Oct 2016 02:47:02 +0000 (04:47 +0200)]
gtk-immodules-cache.bbclass: Use bb.fatal() instead of raising FuncFailed
This sets a good example and avoids unnecessarily contributing to
perceived complexity and cargo culting.
Motivating quote below:
< kergoth> the *original* intent was for the function/task to error via
whatever appropriate means, bb.fatal, whatever, and
funcfailed was what you'd catch if you were calling
exec_func/exec_task. that is, it's what those functions
raise, not what metadata functions should be raising
< kergoth> it didn't end up being used that way
< kergoth> but there's really never a reason to raise it yourself
FuncFailed.__init__ takes a 'name' argument rather than a 'msg'
argument, which also shows that the original purpose got lost.
Ulf Magnusson [Sat, 1 Oct 2016 02:47:01 +0000 (04:47 +0200)]
systemd.bbclass: Use bb.fatal() instead of raising FuncFailed
This sets a good example and avoids unnecessarily contributing to
perceived complexity and cargo culting.
Motivating quote below:
< kergoth> the *original* intent was for the function/task to error via
whatever appropriate means, bb.fatal, whatever, and
funcfailed was what you'd catch if you were calling
exec_func/exec_task. that is, it's what those functions
raise, not what metadata functions should be raising
< kergoth> it didn't end up being used that way
< kergoth> but there's really never a reason to raise it yourself
FuncFailed.__init__ takes a 'name' argument rather than a 'msg'
argument, which also shows that the original purpose got lost.
Ulf Magnusson [Sat, 1 Oct 2016 02:47:00 +0000 (04:47 +0200)]
license.bbclass: Use bb.fatal() instead of raising FuncFailed
This sets a good example and avoids unnecessarily contributing to
perceived complexity and cargo culting.
Motivating quote below:
< kergoth> the *original* intent was for the function/task to error via
whatever appropriate means, bb.fatal, whatever, and
funcfailed was what you'd catch if you were calling
exec_func/exec_task. that is, it's what those functions
raise, not what metadata functions should be raising
< kergoth> it didn't end up being used that way
< kergoth> but there's really never a reason to raise it yourself
FuncFailed.__init__ takes a 'name' argument rather than a 'msg'
argument, which also shows that the original purpose got lost.
Ulf Magnusson [Sat, 1 Oct 2016 02:46:59 +0000 (04:46 +0200)]
update-rc.d.bbclass: Use bb.fatal() instead of raising FuncFailed
This sets a good example and avoids unnecessarily contributing to
perceived complexity and cargo culting.
Motivating quote below:
< kergoth> the *original* intent was for the function/task to error via
whatever appropriate means, bb.fatal, whatever, and
funcfailed was what you'd catch if you were calling
exec_func/exec_task. that is, it's what those functions
raise, not what metadata functions should be raising
< kergoth> it didn't end up being used that way
< kergoth> but there's really never a reason to raise it yourself
FuncFailed.__init__ takes a 'name' argument rather than a 'msg'
argument, which also shows that the original purpose got lost.
Ulf Magnusson [Sat, 1 Oct 2016 02:46:58 +0000 (04:46 +0200)]
gummiboot.bbclass: Use bb.fatal() instead of raising FuncFailed
This sets a good example and avoids unnecessarily contributing to
perceived complexity and cargo culting.
Motivating quote below:
< kergoth> the *original* intent was for the function/task to error via
whatever appropriate means, bb.fatal, whatever, and
funcfailed was what you'd catch if you were calling
exec_func/exec_task. that is, it's what those functions
raise, not what metadata functions should be raising
< kergoth> it didn't end up being used that way
< kergoth> but there's really never a reason to raise it yourself
FuncFailed.__init__ takes a 'name' argument rather than a 'msg'
argument, which also shows that the original purpose got lost.
Ulf Magnusson [Sat, 1 Oct 2016 02:46:57 +0000 (04:46 +0200)]
systemd-boot.bbclass: Use bb.fatal() instead of raising FuncFailed
This sets a good example and avoids unnecessarily contributing to
perceived complexity and cargo culting.
Motivating quote below:
< kergoth> the *original* intent was for the function/task to error via
whatever appropriate means, bb.fatal, whatever, and
funcfailed was what you'd catch if you were calling
exec_func/exec_task. that is, it's what those functions
raise, not what metadata functions should be raising
< kergoth> it didn't end up being used that way
< kergoth> but there's really never a reason to raise it yourself
FuncFailed.__init__ takes a 'name' argument rather than a 'msg'
argument, which also shows that the original purpose got lost.
Ulf Magnusson [Sat, 1 Oct 2016 02:46:56 +0000 (04:46 +0200)]
syslinux.bbclass: Use bb.fatal() instead of raising FuncFailed
This sets a good example and avoids unnecessarily contributing to
perceived complexity and cargo culting.
Motivating quote below:
< kergoth> the *original* intent was for the function/task to error via
whatever appropriate means, bb.fatal, whatever, and
funcfailed was what you'd catch if you were calling
exec_func/exec_task. that is, it's what those functions
raise, not what metadata functions should be raising
< kergoth> it didn't end up being used that way
< kergoth> but there's really never a reason to raise it yourself
FuncFailed.__init__ takes a 'name' argument rather than a 'msg'
argument, which also shows that the original purpose got lost.
Ulf Magnusson [Sat, 1 Oct 2016 02:46:55 +0000 (04:46 +0200)]
grub-efi.bbclass: Use bb.fatal() instead of raising FuncFailed
This sets a good example and avoids unnecessarily contributing to
perceived complexity and cargo culting.
Motivating quote below:
< kergoth> the *original* intent was for the function/task to error via
whatever appropriate means, bb.fatal, whatever, and
funcfailed was what you'd catch if you were calling
exec_func/exec_task. that is, it's what those functions
raise, not what metadata functions should be raising
< kergoth> it didn't end up being used that way
< kergoth> but there's really never a reason to raise it yourself
FuncFailed.__init__ takes a 'name' argument rather than a 'msg'
argument, which also shows that the original purpose got lost.
Ulf Magnusson [Sat, 1 Oct 2016 02:46:54 +0000 (04:46 +0200)]
useradd-staticids.bbclass: Use bb.fatal() instead of raising FuncFailed
This sets a good example and avoids unnecessarily contributing to
perceived complexity and cargo culting.
Motivating quote below:
< kergoth> the *original* intent was for the function/task to error via
whatever appropriate means, bb.fatal, whatever, and
funcfailed was what you'd catch if you were calling
exec_func/exec_task. that is, it's what those functions
raise, not what metadata functions should be raising
< kergoth> it didn't end up being used that way
< kergoth> but there's really never a reason to raise it yourself
FuncFailed.__init__ takes a 'name' argument rather than a 'msg'
argument, which also shows that the original purpose got lost.
Ulf Magnusson [Sat, 1 Oct 2016 02:46:53 +0000 (04:46 +0200)]
package_rpm.bbclass: Use bb.fatal() instead of raising FuncFailed
This sets a good example and avoids unnecessarily contributing to
perceived complexity and cargo culting.
Motivating quote below:
< kergoth> the *original* intent was for the function/task to error via
whatever appropriate means, bb.fatal, whatever, and
funcfailed was what you'd catch if you were calling
exec_func/exec_task. that is, it's what those functions
raise, not what metadata functions should be raising
< kergoth> it didn't end up being used that way
< kergoth> but there's really never a reason to raise it yourself
FuncFailed.__init__ takes a 'name' argument rather than a 'msg'
argument, which also shows that the original purpose got lost.
Ulf Magnusson [Sat, 1 Oct 2016 02:46:52 +0000 (04:46 +0200)]
package_deb.bbclass: Use bb.fatal() instead of raising FuncFailed
This sets a good example and avoids unnecessarily contributing to
perceived complexity and cargo culting.
Motivating quote below:
< kergoth> the *original* intent was for the function/task to error via
whatever appropriate means, bb.fatal, whatever, and
funcfailed was what you'd catch if you were calling
exec_func/exec_task. that is, it's what those functions
raise, not what metadata functions should be raising
< kergoth> it didn't end up being used that way
< kergoth> but there's really never a reason to raise it yourself
FuncFailed.__init__ takes a 'name' argument rather than a 'msg'
argument, which also shows that the original purpose got lost.
Ulf Magnusson [Sat, 1 Oct 2016 02:46:51 +0000 (04:46 +0200)]
package_ipk.bbclass: Use bb.fatal() instead of raising FuncFailed
This sets a good example and avoids unnecessarily contributing to
perceived complexity and cargo culting.
Motivating quote below:
< kergoth> the *original* intent was for the function/task to error via
whatever appropriate means, bb.fatal, whatever, and
funcfailed was what you'd catch if you were calling
exec_func/exec_task. that is, it's what those functions
raise, not what metadata functions should be raising
< kergoth> it didn't end up being used that way
< kergoth> but there's really never a reason to raise it yourself
FuncFailed.__init__ takes a 'name' argument rather than a 'msg'
argument, which also shows that the original purpose got lost.
Ulf Magnusson [Sat, 1 Oct 2016 02:46:50 +0000 (04:46 +0200)]
base.bbclass: Use bb.fatal() instead of raising FuncFailed
This sets a good example and avoids unnecessarily contributing to
perceived complexity and cargo culting.
Motivating quote below:
< kergoth> the *original* intent was for the function/task to error via
whatever appropriate means, bb.fatal, whatever, and
funcfailed was what you'd catch if you were calling
exec_func/exec_task. that is, it's what those functions
raise, not what metadata functions should be raising
< kergoth> it didn't end up being used that way
< kergoth> but there's really never a reason to raise it yourself
FuncFailed.__init__ takes a 'name' argument rather than a 'msg'
argument, which also shows that the original purpose got lost.
Ross Burton [Mon, 3 Oct 2016 14:16:32 +0000 (15:16 +0100)]
binutils: apply RPATH fixes from our libtool patches
We don't autoreconf/libtoolize binutils as it has very strict requirements, so
extend our patching of the stock libtool to include two fixes to RPATH
behaviour, as part of the solution to ensure that native binaries don't have
RPATHs pointing at the host system's /usr/lib.
This generally doesn't cause a problem but it can cause some binaries (such as
ar) to abort on startup:
./x86_64-pokysdk-linux-ar: relocation error: /usr/lib/libc.so.6: symbol
_dl_starting_up, version GLIBC_PRIVATE not defined in file ld-linux.so.2 with
link time reference
The situation here is that ar is built and as it links to the host libc/loader
has an RPATH for /usr/lib. If tmp is wiped and then binutils is installed from
sstate relocation occurs and the loader changed to the sysroot, but there
remains a RPATH for /usr/lib. This means that the sysroot loader is used with
the host libc, which can be incompatible. By telling libtool that the host
library paths are in the default search path, and ensuring that all default
search paths are not added as RPATHs by libtool, the result is a binary that
links to what it should be linking to and nothing else.
Ross Burton [Mon, 3 Oct 2016 14:16:30 +0000 (15:16 +0100)]
classes/native: set lt_cv_sys_lib_dlsearch_path_spec
This variable is used by libtool to know what paths are on the default loader
search path. As we have modified loader paths, native.bbclass can tell libtool
that both the sysroot libdir and the host library paths are searched, so no
RPATHs for those will be generated.
Ross Burton [Mon, 3 Oct 2016 14:16:29 +0000 (15:16 +0100)]
classes/cross: set lt_cv_sys_lib_dlsearch_path_spec
This variable is used by libtool to know what paths are on the default loader
search path. As we have modified loader paths, cross.bbclass can tell libtool
that both the sysroot libdir and the host library paths are searched, so no
RPATHs for those will be generated.
Ed Bartosh [Wed, 28 Sep 2016 09:29:02 +0000 (12:29 +0300)]
beaglebone.conf: produce wic images for Beaglebone
Added wic images to the list of default image types for Beaglebone
machine. Added kernel image and device tree packages to the image
to make it bootable. Added required wic dependencies.
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>
Richard Purdie [Fri, 30 Sep 2016 16:22:12 +0000 (17:22 +0100)]
bitbake: data: Fix handling of vardepvalueexclude
The value used for exclusion was always being expanded. This is actually
a bad idea since in most cases you'd want to exclude an unexpanded
value and makes it impossible to use the variable as intended.
This adjusts things so the value is not expanded and we can correctly
remove things from checksums much more easily.
Richard Purdie [Fri, 30 Sep 2016 16:43:28 +0000 (17:43 +0100)]
machine-sdk: Clear ABIEXTENSION to avoid sstate checksum mismatch issues
When switching MACHINE, nativeksdk recipes could end up being rebuilt. Clear
ABIEXTENSION to avoid this problem and ensure sstate checksum consistency.
Richard Purdie [Fri, 30 Sep 2016 16:43:27 +0000 (17:43 +0100)]
oeqa/sstatetests: Add test for multilib allarch checksums
Switching between multilib configurations should not change allarch recipe
or nativesdk checksums. Add a new sstate test for this based on the standard
allarch test.
Richard Purdie [Fri, 30 Sep 2016 16:43:26 +0000 (17:43 +0100)]
boost: Ensure native recipes have consistent checksums
When building boost-native on i686, the x86 override isn't applied
unless the target also happens to be x86. Similarly the x86_64 override
is only applied on 64 bit target machines.
Avoid various problems by removing the new problematic configure options
in the native case.
Richard Purdie [Fri, 30 Sep 2016 16:43:25 +0000 (17:43 +0100)]
gcc-cross: Stop target recipes depending on SDK_SYS
gcc-cross target recipes should not depend on SDK_SYS but started to
after recent changes. Remove the dependency to stop this (its caused
by shared code in do_install). The compiler names contain SDK_SYS
so changes would be correctly handled via other means.
Richard Purdie [Fri, 30 Sep 2016 16:43:24 +0000 (17:43 +0100)]
multilib.conf: Ensure sstate checksums don't change when using this include
When enabling multilib.conf, the world was rebuilding due to changes in the
pkg-config search path. This doesn't matter so exclude it from the checksums.
Richard Purdie [Fri, 30 Sep 2016 16:43:23 +0000 (17:43 +0100)]
allarch: Fixes to stop rebuilds when change multilibs
When changing multilibs, allarch recipes should not be rebuilding. This
adds enough variable exclusions to make this work properly. Future
regressions will be prevented with new testing.
This begins moving away from the deprecated subprocess calls in an
effort to eventually move to some more global abstraction using the run
convenience method provided in python 3.5.
projects / thirdparty / openembedded / openembedded-core-contrib.git / log
