When booting a system with the rootfs being of cpio* type the networking
setup should still work the same as for all other root filesystem types.
This change removes the clearing of the NETWORK_CMD variable allowing
for the slirp/tap setup to be provided to QEMU.
(From OE-Core rev: 7d01a9c80de0cdbac3831301dd996c7b61754c74)
Signed-off-by: Nathan Rossi <nathan@nathanrossi.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Not all QEMU machines (outside of those available in OE-Core) are
capable of using the virtio-rng-pci device due to various machine models
not having a pci/virtio bus. This makes it such that the use of the
'-device virtio-rng-pci' flag to QEMU is machine specific.
This patch removes the general addition of the flag to all runqemu
targets and adds the flag into the QB_OPT_APPEND for all the qemu*
machines in OE-Core that support its use (which is all of them).
(From OE-Core rev: e890c05e66a21702e9e8ccce794b74cb7f5518ed)
Signed-off-by: Nathan Rossi <nathan@nathanrossi.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Explicitly set CMAKE_LIBRARY_PATH so that find_library() looks in the native
sysroot before the host.
Also pass --verbose to configure which sets CMAKE_VERBOSE_MAKEFILE for detailed
compile logs.
(From OE-Core rev: 89b28990ff3ef8ac7a33a0a3f9177b9bd0e1530b)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This fixes following error:
,----
| src/libavutil/log.c:51:31: fatal error: valgrind/valgrind.h: No such file or directory
| #include <valgrind/valgrind.h>
`----
(From OE-Core rev: 262f8180c9037b7e82efe08ce3bb1880fee22ea8)
Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Add CVE-2016-4477 patch for avoiding \n and \r characters in passphrase
parameters, which allows remote attackers to cause a denial of service
(daemon outage) via a crafted WPS operation.
Patches came from http://w1.fi/security/2016-1/
(From OE-Core rev: d4d4ed5f31c687b2b2b716ff0fb8ca6c7aa29853)
Signed-off-by: Zhixiong Chi <zhixiong.chi@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Add CVE-2016-4476 patch for avoiding \n and \r characters in passphrase
parameters, which allows remote attackers to cause a denial of service
(daemon outage) via a crafted WPS operation.
Patches came from http://w1.fi/security/2016-1/
(From OE-Core rev: ed610b68f7e19644c89d7131e34c990a02403c62)
Signed-off-by: Zhixiong Chi <zhixiong.chi@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Currently adding a font recipe to an image doesn't have enough
dependencies to cause mkfontdir-native to be included in the native
sysroot. This creates problems with the postinstall scripts for fonts
which call mkfontdir to create font index files: font.dir. The end
result is missing font.dir files in the built image and a malfunctioning
font system.
Dependencies for the relevant recipes currently look like this:
* <font.bb> [D ] -> font-util-native
[R ] -> encodings, font-util
[RN] -> font-util-native
* font-util [D ] -> encodings
[R ] -> mkfontdir, mkfontscale, encodings
[RN] -> mkfontdir-native, mkfontscale-native
* encodings [D ] -> mkfontscale-native, font-util-native
* mkfontdir [R ] -> mkfontscale
[RN] -> mkfontscale-native
* mkfontscale [D ] -> libfontenc
* libfontenc [D ] -> font-util
Where:
* D = DEPENDS
* R = RDEPENDS
* RN = RDEPENDS_class-native
* <font.bb> e.g. font-adobe-100dpi*.bb
Some details where omitted for clarity e.g. dependencies on util-macros.
I believe the intent behind the RDEPENDS_class-native chain:
* <font.bb> -> font-util-native -> mkfontdir-native
was to provide the necessary dependency on mkfontdir. However because
the native sysroot is not built from packages this RDEPENDS_class-native
chain doesn't have the desire effect (i.e. it doesn't pull in
mkfontdir-native).
Changing the RDEPENDS_class-native chain into a DEPENDS_class-native
chain is a non-starter because of the build time dependency loop it
creates:
* font-util-native -> mkfontscale-native -> libfontenc-native -> font-util-native
Having upstream remove the build time dependency of libfontenc on
font-util is also a non-starter[1] even though it does create problems
in other distributions, for example on Debian see [2], [3].
Instead add a DEPENDS on mkfontdir-native in the encodings recipe in
addition to the mkfontscale-native dependency it already contains. This
solves the missing mkfontdir in the native sysroot problem without
introducing a build dependency loop.
[1] https://bugs.freedesktop.org/show_bug.cgi?id=97631
[2] https://wiki.debian.org/CircularBuildDependencies
[3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=717843
(From OE-Core rev: aa8a7b2962f9a77bdd347843c41f86dc291b783e)
Signed-off-by: Gratian Crisan <gratian.crisan@ni.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If the user doesn't set SDKMACHINE in their local.conf then uninative and
buildtools will fail in obscure ways, so ensure that a default value is set.
Also as SDK_ARCH will be overritten then loading the machine-sdk configuration
file, don't bother assigning it.
(From OE-Core rev: 6bd507ef36578ba7bee6ef8b3f8f6465afca4e20)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
buildtools-tarball shouldn't be regenerated when MACHINE changes,
nor should variants for other SDKMACHINE be removed from the deploy
directory when SDKMACHINE changes.
Remove target architecture dependencies so that deploy artefacts
can overlap.
(From OE-Core rev: b7d1a310f6b880e92b124a78af3c948abaab4236)
Signed-off-by: Joshua Lock <joshua.g.lock@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We use toolchain_create_sdk_version() in buildtools-tarball but
don't want the extra classes toolchain-scripts pulls in, therefore
split out a separate base class for this function which both
toolchain-scripts and the buildtools-tarball can inherit.
(From OE-Core rev: a398dfa654dc035c404fc12279fac9edf6403e11)
Signed-off-by: Joshua Lock <joshua.g.lock@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When build lib32-xserver-xorg it has qa warning:
| WARNING: lib32-xserver-xorg-2_1.18.4-r0 do_package_qa: QA Issue:
| Package lib32-xf86-video-modesetting contains Xorg driver
| (modesetting_drv.so) but no xorg-abi- dependencies [xorg-driver-abi]
The qa check xorg-driver-abi has been skipped for xserver-xorg and make
it to skip for multilib package too.
(From OE-Core rev: 5f94d2dd7a16ae9f327c88636822539f79e983eb)
Signed-off-by: Kai Kang <kai.kang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
A "bitbake world -c unpack" currently breaks as not all tasks have an
unpack task. This change allows addition of world targets only if the
specified task exists which makes certain commands possible when otherwise
you just get errors which can't easily be avoided.
(Bitbake rev: ca4f5e6d01b5c8cf315f59bc86194d63c0d3d042)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Currently if you use the subdir parameter in a SRC_URI and pass an absolute path
then it gets appended to the unpack directory instead of being used directly.
This is inconvenient as it may be useful to use ${S} when you want to unpack a
file into the source tree.
Change this behaviour so that absolute paths are used directly instead of being
appended to the root directory. To ensure that recipes cannot write files to an
arbitrary location enforce that the subdir starts with the unpack root.
(Bitbake rev: c3873346c6fa1021a1d63bddd9b898a77c618432)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
${D} is listed in cleandirs so no need to list it in dirs as well.
The default directory is ${B} so this is a cleanup which should have
no changes to the execution.
[YOCTO #10017]
(From OE-Core rev: 7e0f95bf359bc3b5bb1578024a993e184de155cd)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
As things stand there are multiple races in the CONFIG_SITE handling
where checksums can change depending on whether site directories
exist or not when parsing happens. This is bad.
Secondly, there is a build race that occurs if you build virtuals
in parallel with the "main" recipe, since the main recipe is parsed
when the virtual is (since it sets variables like BBCLASSEXTEND)
and with the current code, it may look for files and directories
which could be created/destroyed which the loop is executing. This
is also bad.
The aclocal-copy directory should only ever be accessed by the call
from autotools.bbclass. This changes the parameter name to make it
clear and ensures all callers have the right usage, neatly avoiding
all the problems above. Also added better comments.
(From OE-Core rev: 3207244004c612c1a0e13921251003e5e635d1b1)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The make clean removes doc/a2x.1 and doc/asciidoc.1, then it would cause
build failures since in the second build:
Fixing CONF_DIR in asciidoc.py
Fixing CONF_DIR in a2x.py
python a2x.py -f manpage doc/a2x.1.txt
a2x: ERROR: "xmllint" --nonet --noout --valid "/path/to/asciidoc-native/8.6.9-r0/asciidoc-8.6.9/doc/a2x.1.xml" returned non-zero exit status 4
make: *** [doc/a2x.1] Error 1
The xmllint failed because "--nonext" is used:
I/O error : Attempt to load network entity http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd
/buildarea/lyang1/test_arm/tmp/work/x86_64-linux/asciidoc-native/8.6.9-r0/asciidoc-8.6.9/doc/a2x.1.xml:2: warning: failed to load external entity "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd"
Avoid running make clean will fix the problem.
(From OE-Core rev: f60fc2dc231ffc8cbf5939b0dbfa06c5fe805b86)
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>
Added serial console to kernel command line to to make it
easier to boot wic images on devices without display.
Tested on MinnowBoard MAX.
(From OE-Core rev: 9a774e3bcd5dc4c85d642acc7bf26095b8c620e4)
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>
When built on an i686 host for qemux86-64 without the
fix to obey LD and it fails:
/scratch/dogwood/toolchains/x86_64/bin/i686-pc-linux-gnu-ld:
Relocatable linking with relocations from format elf64-x86-64
(/scratch/dogwood/perf-ld-test/build/tmp/work/qemux86_64-mel-linux/perf/1.0-r9/perf-1.0/fs/fs.o)
to format elf32-i386 (/scratch/dogwood/perf-ld-test/build/tmp/work/qemux86_64-mel-linux/perf/1.0-r9/perf-1.0/fs/libapi-in.o)
is not supported
This is because LD includes HOST_LD_ARCH, which contains TUNE_LDARGS,
which is -m elf32_x86_64 for x86_64. Without that, direct use of ld will fail.
(From OE-Core rev: 0ce06611068e74e6ea2e226e3f967aaa91fecd25)
Signed-off-by: Christopher Larson <chris_larson@mentor.com>
Signed-off-by: Sujith Haridasan <Sujith_Haridasan@mentor.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
works around:
<native-sysroot>/ld: error: Gperf-simple.o: cannot make copy relocation for protected symbol '_Uarm_local_addr_space', defined in ../src/.libs/libunwind-arm.so
collect2: error: ld returned 1 exit status
Makefile:1038: recipe for target 'Gperf-simple' failed
make[1]: *** [Gperf-simple] Error 1
make[1]: *** Waiting for unfinished jobs....
<...>
<native-sysroot>/ld: error: Lperf-simple.o: cannot make copy relocation for protected symbol '_ULarm_local_addr_space', defined in ../src/.libs/libunwind.so
collect2: error: ld returned 1 exit status
Makefile:1094: recipe for target 'Lperf-simple' failed
make[1]: *** [Lperf-simple] Error 1
<...>
ERROR: oe_runmake failed
<native-sysroot>/ld: error: Gperf-trace.o: cannot make copy relocation for protected symbol '_Uarm_local_addr_space', defined in ../src/.libs/libunwind-arm.so
collect2: error: ld returned 1 exit status
Makefile:1042: recipe for target 'Gperf-trace' failed
make[1]: *** [Gperf-trace] Error 1
<native-sysroot>/ld: error: Lperf-trace.o: cannot make copy relocation for protected symbol '_ULarm_local_addr_space', defined in ../src/.libs/libunwind.so
collect2: error: ld returned 1 exit status
Makefile:1098: recipe for target 'Lperf-trace' failed
make[1]: *** [Lperf-trace] Error 1
<...>
<native-sysroot>/ld: error: test-coredump-unwind.o: cannot make copy relocation for protected symbol '_UCD_accessors', defined in ../src/.libs/libunwind-coredump.so
collect2: error: ld returned 1 exit status
Makefile:1186: recipe for target 'test-coredump-unwind' failed
(From OE-Core rev: 482733bae05bdc7b149e515fb209c3266f459a53)
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>
Tried by adding CFLAGS_append = " -fpic " to
the recipe. But that couldn't help resolve the
warning message:
x264/r2491+gitAUTOINC+c8a773ebfc-r0/packages-split/x264/usr/lib/libx264.so.144' has relocations in .text [textrel]
It was found that this warning is emitted because of the
assembly files in the source code. And it is not easy to
get rid of TEXTREL's which are coming from the assembly
source files.
Adding textrel to INSANE_SKIP resolves this issue.
This issue was observed in cyclone5 and imx6qsabresd BSP's.
So generalizing the patch.
(From OE-Core rev: 9470e0911838a6f5a23f01c6944906b69aa1317a)
Signed-off-by: Fahad Usman <fahad_usman@mentor.com>
Signed-off-by: Sujith Haridasan <Sujith_Haridasan@mentor.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The relocation script of the SDK doesn't have enough
error handling when replacing host perl with SDK perl
or changing the symlinks. This will add those checks
along with a sanity check of xargs.
[YOCTO #10114]
(From OE-Core rev: c9982dab4cfdd5963d2c2dd4aab99dd6a27fcd1c)
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>
Configuration failed to detect gold as GNU linker. It was searching for
'GNU ld' but gold returns 'GNU gold (GNU Binutils 2.27.0.20160806) 1.12' which
does not match. When not linking by GNU linker Makefile did some magic link
target alignment:
ifneq ($(GNU_LD),)
SHLIBFLAGS= -Wl,--version-script,newt.0.52.ver -Wl,-soname,$(LIBNEWTSONAME)
else
SHLIBFLAGS=
endif
which caused:
| WARNING: libnewt-0.52.19-r0 do_package_qa: QA Issue: /usr/bin/whiptail contained in package whiptail requires libnewt.so, but no providers found in RDEPENDS_whiptail? [file-rdeps]
(From OE-Core rev: 3b806c927504e682ddd159c890a5f243e273b23e)
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>
The uninative tarball only contains nativesdk compoents. It should
not get regenerated when MACHINE changes for example. Currently its
sstate arch is also incorrect so changing SDKMACHINE results in other
variants being removed from the deploy directory.
This patch removes the target architecture dependencies so that
deploy artefacts can overlap and it doesn't continually rebuild. This
also fixes various autobuilder/release artefact issues we're having
as a result of these issues.
(From OE-Core rev: 6edd0b8dccc6e1e21f2ef87013e2e0a40d19b0d6)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Fixes [YOCTO #10293]
In the section about setting variables, I added a paragraph that
explains the use of single quotes when setting a variable. The
case covers when you must have the double quote charater as part
of your variable's value.
(Bitbake rev: 01e331cd0d612013badfb07df91151907f74903d)
Signed-off-by: Scott Rifenbark <srifenbark@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Fixes [YOCTO #10100]
I added a new parent directory named "Functions You Can Call From
Within Python". This section contains a couple new sub-sections.
One is the existing "Functions for Accessing Datastore Variables".
The other is called "Other Functions", and it is used to point
or reference some commonly used functions that the user can call
from within Python.
(Bitbake rev: ecbcedd74125ef00599f4af384ee303dae8af5b7)
Signed-off-by: Scott Rifenbark <srifenbark@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We don't want a traceback for this exception, we need to catch it, fire
TaskFailed, and return failure.
(Bitbake rev: 63966ada459d44d3dc7817ad2a026a22e8f6700f)
Signed-off-by: Christopher Larson <chris_larson@mentor.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Otherwise the stamps for x86-64 and i686 uninative tarballs match
and we can't deploy both to the DEPLOYDIR.
(From OE-Core rev: fee426ae0c2b27925b05b856ada676958ee10869)
Signed-off-by: Joshua Lock <joshua.g.lock@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If DEPLOY_DIR_IMAGE doesn't exist during check_arg_machine() we
will attempt to guess a suitable value later when check_and_set()
calls validate_paths(), therefore this shouldn't raise an exception
(From OE-Core rev: ed8d6f391c567048bd50dc3234804915f8212cef)
Signed-off-by: Joshua Lock <joshua.g.lock@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If a MACHINE value is passed we can't validate it by running bitbake
as the toolchain environment doesn't include the build system, we
must assume that the passed value for MACHINE is correct.
(From OE-Core rev: 2c569678566c49b3ea237ef2de0fbae782263449)
Signed-off-by: Joshua Lock <joshua.g.lock@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Emulate some logic from the prior, shell based, version of runqemu
to try and infer the correct setting for MACHINE from the kernel
and rootfs filenames.
(From OE-Core rev: a5adabe1414061d6864c5913dd5e66a4527838f1)
Signed-off-by: Joshua Lock <joshua.g.lock@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We need to validate and ensure all paths are set regardless of
whether runqemu was invoked with a .qemuboot.conf file or
otherwise. Split this logic out into a separate method called
during check_and_set()
(From OE-Core rev: e843b2d49a151c1fe0d2a7ba00c41d2a35775736)
Signed-off-by: Joshua Lock <joshua.g.lock@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Boot test for all these boards.
(From meta-yocto rev: 3fe3a876710255ad8d16fae84aea92477c144440)
Signed-off-by: Kevin Hao <kexin.hao@windriver.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Boot test for all these boards.
(From meta-yocto rev: ba5f8d54492d862de5995364e33acfe014281c00)
Signed-off-by: Kevin Hao <kexin.hao@windriver.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Boot test for all these boards.
(From meta-yocto rev: 02239cf4e7d034e1e910b0373fcdc5a9bdd74b6e)
Signed-off-by: Kevin Hao <kexin.hao@windriver.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Added wic images to the list of default image types for genericx86
and genericx86-64 machines. This is a first step of using wic as a
recommended way of creating images for reference BSPs.
[YOCTO #8719]
(From meta-yocto rev: 384fa3a21d515c53c177ac66f74999276933b214)
Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(From meta-yocto rev: aac30f9e8e5ec06479750d460e7342bc990e87fe)
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If you "bitbake glibc-locale" then delete the libpcre-native sstate
and "bitbake glibc-locale -C package_write_rpm", it will fail with
rpmbuild missing the libprce library.
The reason is that libpcre-native fails to install from sstate (since
it isn't present) but doesn't get built and hence rpm-native tries to
run without its dependencies.
The simplest fix is not to add "covered" tasks which have failed to
install sstate. I can't help feeling there is more to this issue but
this does fix the current problem and shouldn't have adverse affects.
It is an unusual situation to have missing dependencies in sstate since
they're usually all present or not at all.
I've taken the opportunity to remove some old cruft from when we had
numeric task ids, the code can be simpler now.
(Bitbake rev: ba566b46d530b495f12f3a74f76434717b22a020)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When the layer is local source don't try and work out the location of
the layer by using the git information (getGitCloneDirectory)
[YOCTO #10199]
(Bitbake rev: 3dfea5214d4bd006e26630e5024774ecb84ea527)
Signed-off-by: Michael Wood <michael.g.wood@intel.com>
Signed-off-by: bavery <brian.avery@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Based on the same test as found in patchwork by Damien Lespiau
https://github.com/dlespiau/patchwork/blob/master/patchwork/tests/test_db.py
(Bitbake rev: 031cb194aaa1b6cc970fed3fa0d0dbd3ebac163f)
Signed-off-by: Michael Wood <michael.g.wood@intel.com>
Signed-off-by: bavery <brian.avery@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
There is no need to lock build environment before changing
build status as this operation is very fast. However, there
is a need to unlock it after changing build status.
Explicitly unlocked BuildEnvironment after build reaches
final status SUCCEEDED, FAILED or CANCELLED. This should
allow runbuilds process to pickup next build faster.
(Bitbake rev: faa88272d656640c039572c5c8f3e6c56535b6f7)
Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com>
Signed-off-by: Michael Wood <michael.g.wood@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Fixed following pylint warnings:
C0330(bad-continuation): Wrong hanging indentation before block.
C0326(bad-whitespace): No space allowed around keyword argument assignment
C0326(bad-whitespace): Exactly one space required before assignment
C0301(line-too-long): Line too long
(Bitbake rev: 0eecd660e374a4dbcefe4c59f4c8654bf3a0e937)
Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com>
Signed-off-by: Michael Wood <michael.g.wood@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If Toaster is stopped incorrectly there could be some
build requests and builds in incorrect state left from the previous run.
Running main processing function on start should take care of those.
(Bitbake rev: 6b9f8f6bb51d1aa2ca4effc34e076e331d0cb8d1)
Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com>
Signed-off-by: Michael Wood <michael.g.wood@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Run main processing function 'runbuild' only if SIGUSR1 is
received. This signal is sent by Toaster when build status
is changed (either started, cancelled or finished).
This should stop continuous database polling as run_builds function
will be called only when needed, i.e. after build status is changed.
[YOCTO #8918]
(Bitbake rev: 62d598cc5aa01d23f1e9284e9e926bd55b1d1878)
Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com>
Signed-off-by: Michael Wood <michael.g.wood@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Nathan Rossi
Ross Burton
Otavio Salvador
Zhixiong Chi
Gratian Crisan
Joshua Lock
Kai Kang
Richard Purdie
Robert Yang
Ed Bartosh
Christopher Larson
Andreas Müller
Maciej Borzecki
Fahad Usman
Mingli Yu
Mariano Lopez
Scott Rifenbark
Alejandro Hernandez
Kevin Hao
Michael Wood