testimage.bbclass uses runqemu to execute runtime tests on a qemu
target, this means that bitbake is already running and `bitbake -e`
can't be called to obtain bitbake variables.
runqemu tries to work around being unable to read values for
bitbake variables by inferring the MACHINE from the
DEPLOY_DIR_IMAGE setting, however if a user sets that variable in
a manner which doesn't follow the systems expectations (i.e. if
running `bitbake -c testimage` against a directory of pre-generated
images in a user-specified path) the inferring of the MACHINE name
from the DEPLOY_DIR_IMAGE location will fail.
It's possible that check_arg_machine() shouldn't cause runqemu to
fail and that runqemu should proceed with the user-supplied value
even if it can't be verified. This patch simply ensures that a
workflow where the user sets DEPLOY_DIR_IMAGE continues to work
without changing too much of the runqemu code.
[YOCTO #10238]
(From OE-Core rev: f94ac02f459e2ea0fc471463966997814a67e0ca)
Signed-off-by: Joshua Lock <joshua.g.lock@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When runqemu is invoked from a running bitbake instance it will be
unable to call `bitbake -e` due to the lock held by the calling
bitbake instance.
Our test code sets an OE_TMPDIR environment variable from which we
can infer/guess paths. Add code to do so when self.bitbake_e can't
be set, much as the sh version of runqemu did.
[YOCTO #10240]
(From OE-Core rev: 1e8165ea2f19aecdc03ccd102ee44ef0544f0f39)
Signed-off-by: Joshua Lock <joshua.g.lock@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If the STAGING_*_NATIVE directories from the config file don't exist
and we're in a sourced OE build directory try to extract the paths
from `bitbake -e`
(From OE-Core rev: 9326af1c20636320c70caecebd47aedafb3f2d25)
Signed-off-by: Joshua Lock <joshua.g.lock@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When runqemu is started with a *.qemuboot.conf arg assume that image
artefacts are relative to that file, rather than in whatever
directory the DEPLOY_DIR_IMAGE variable in the conf file points to.
(From OE-Core rev: a6448371b87f754def669adfdc01b07d18003405)
Signed-off-by: Joshua Lock <joshua.g.lock@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Previously, runqemu had hard coded machine knowledge, which limited its
usage, for example, qemu can boot genericx86, but runqemu can't, we need
edit runqemu/runqemu-internal a lot if we want to boot genericx86.
Now bsp conf files can set vars to make it can be boot by runqemu, and
qemuboot.bbclass will save these info to DEPLOY_DIR_IMAGE/qemuboot.conf.
Please see qemuboot.bbclass' comments on how to set the vars.
* Re-write it in python3, which can reduce lines from 1239 to about 750
lines
* All the machine knowledges are gone
* All of the TUN_ARCH knowledge are gone
* All the previous options are preserved, and there is a new way to run
runqemu: (it doesn't need run "bitake -e" in such a case)
$ runqemu tmp/deploy/images/qemux86
or:
$ runqemu tmp/deploy/images/qemuarm/<image>.ext4
or:
$ runqemu tmp/deploy/images/qemuarm/qemuboot.conf
* Fixed audio support, not limited on x86 or x86_64
* Fix SLIRP mode, add help message, avoid mixing with tap
* Fix NFS boot, it will extract <image>.tar.bz2 or tar.gz to
DEPLOY_DIR_IMAGE/<image>-nfsroot when no NFS_DIR, and remove it after
stop.
* More bsps can be boot, such as genericx86 and genericx86-64.
* The patch for qemuzynq, qemuzynqmp, qemumicroblaze has been sent to
meta-xilinx' mailing list.
* I can't find any qemush4 bsp or how to build it, so it is not
considered atm.
[YOCTO #1018]
[YOCTO #4827]
[YOCTO #7459]
[YOCTO #7887]
(From OE-Core rev: 60ca8a8d899b90a4693fd62b6ec97d0c76a9f6c5)
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
All qemu boards should be able to boot by runqemu.
(From OE-Core rev: 5174889d59a5d6da29b4290376010dd176767e1f)
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
qemuppc can use virtio networking and we may as well do so for better
prformance as we do under the other emulated hardware.
(From OE-Core rev: 8a82ded799be79eacb64cf313b6f2799a4f5ffab)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(From OE-Core rev: 2c8e5657cafafe848c7e7c714e5e73bb82799d65)
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Add qemuboot-mips.inc to reduce duplicated code, the various mips bsps
which can be boot by runqemu can require qemuboot-mips.inc
(From OE-Core rev: cb28128477e98ed7dc7a90dd197f6dd04cf75be0)
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Add qemuboot-x86.inc to reduce duplicated code, the x86/x86_64 bsps
which can be boot by runqemu can require qemuboot-x86.inc.
(From OE-Core rev: b5ff3dda2a576ba7e5d68198ea6c6eb49cf80eb8)
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(From OE-Core rev: 73bccbbfc0f987fc82aca5411e15f62c02e5336c)
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The base_version_less_or_equal() will raise errors if
PREFERRED_VERSION_linux-yocto is None. For example, when we build
DISTRO = "nodistro", PREFERRED_VERSION_linux-yocto is not be defined
since it is defined in poky.conf, and then bitbake will
choose the higher version which is 4.8 currently, so set
PREFERRED_VERSION_linux-yocto to 4.8, otherwise, runqemu can't boot it.
(From OE-Core rev: fd31e30f97ee9bd128d5b7b748987b0a6427b279)
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
For kernels after 4.7, we need to ensure the DTB file for the kernel is
used by runqemu. Doing this conditionally based upon the kernel verison
being built seems to be the only way forward for this.
(From OE-Core rev: 4615764509234bfb206ffe4cd430653b88d46ec3)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
These info are from old runqemu.
(From OE-Core rev: f22f09f8e1bb24e92e9109fcd7a347277acedcce)
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
It saves vars in ${DEPLOY_DIR_IMAGE}/<image>.qemuboot.conf, and runqemu
will read it.
The bsp which can be boot by runqemu will inherit it.
(From OE-Core rev: 1675e9b89e00b875d0da13411a2a939aa4ba5298)
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
bitbake qemu
This error shows up:
ERROR: qemu-2.7.0-r1 do_install_ptest_base: Function failed:
do_install_ptest_base
...
cp: cannot stat '...tmp/work/core2-64-poky-linux/qemu/2.7.0-r1
/qemu-2.7.0/tests/Makefile: No such file or directory
...
Commit 46e7b70699d8bf4db08c8bb5111974318dd5416d in qemu project
renamed tests/Makefile to tests/Makefile.include, we apply the
same change in recipe accordingly to fix this issue.
Fixes [YOCTO #10245]
(From OE-Core rev: 7009a9309051061455fa7237e09796ef12c9e308)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This upgrade can fix a qemuppc + openssh bug, the ssh connection maybe
refused or closed randomly, and it's not easy to reproduce. RP pointed
that this upgrade can fix the problem, and it does work in my local
testing.
* Update add-ptest-in-makefile.patch
* Drop backported patch 0001-configure-support-vte-2.91.patch
Here is the Changlog:
http://wiki.qemu.org/ChangeLog/2.7
(From OE-Core rev: 056ce17e168bf856ff95a6f659098403169cb889)
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
qemu 2.7.0 introduces kernel errors:
[ 2.310768] pci 0000:00:00.0: [11ab:4620] type 00 class 0x060000
[ 2.311338] pci 0000:00:00.0: [Firmware Bug]: reg 0x14: invalid BAR (can't size)
[ 2.311604] pci 0000:00:00.0: [Firmware Bug]: reg 0x18: invalid BAR (can't size)
[ 2.311835] pci 0000:00:00.0: [Firmware Bug]: reg 0x1c: invalid BAR (can't size)
[ 2.312063] pci 0000:00:00.0: [Firmware Bug]: reg 0x20: invalid BAR (can't size)
[ 2.312323] pci 0000:00:00.0: [Firmware Bug]: reg 0x24: invalid BAR (can't size)
[ 2.314320] pci 0000:00:0a.0: [8086:7110] type 00 class 0x060100
[ 2.315363] pci 0000:00:0a.1: [8086:7111] type 00 class 0x010180
Whitelist this for now since this is preferable to the random failures
we're seeing from qemuppc with 2.6.0.
(From OE-Core rev: 4d542cdc86c34f0f4a3dde8b0aab059bca76a9fb)
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Fixes [YOCTO #10146]
(From OE-Core rev: cd5d532bd2a3f409b9470591c8d6f6b21e5995dd)
Signed-off-by: Henry Bruce <henry.bruce@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(From OE-Core rev: 1868db95819b45961cd7e8499ecace403e6bc91d)
Signed-off-by: Henry Bruce <henry.bruce@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Provides configuration files for watchdog.
Add watchdog-config as a runtime dependence of watchdog and remove
watchdog.conf file from watchdog installation.
(From OE-Core rev: 6864ad2e863205472f8ea2057c61e949dc450151)
Signed-off-by: Fabio Berton <fabio.berton@ossystems.com.br>
Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This is a simplified version of the watchdog daemon. It only opens
/dev/watchdog, and keeps writing to it often enough to keep the kernel
from resetting, at least once per minute. Each write delays the reboot
time another minute. After a minute of inactivity the watchdog hardware
will cause a reset. In the case of the software watchdog the ability to
reboot will depend on the state of the machines and interrupts.
Installs wd_keepalive binary and enable initscript.
(From OE-Core rev: b76af8a0982c3c7473bd6ba067d1c8030d4d2f26)
Signed-off-by: Fabio Berton <fabio.berton@ossystems.com.br>
Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The SRCREVs were previously updated to -rc5, but the LINUX_VERSION
was missed. As such, we are building and booting -rc5, but all the
packaging says -rc4.
Worth a quick update while we wait for -rc6
(From OE-Core rev: ea2f99161a22ae2e9eefd3b337c9af7704c33e37)
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Instead of build depending on pkgconfig-native, inherit pkgconfig
class which does the same thing.
(From OE-Core rev: 3a2b6b5ee1e43ec9c968062a3fbeb0e1a4630c18)
Signed-off-by: Maxin B. John <maxin.john@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Instead of DEPENDS += "pkgconfig-native", inherit pkgconfig class which does
the same.
(From OE-Core rev: dbaa536c569d728f47f949fedbab165b73c9985d)
Signed-off-by: Maxin B. John <maxin.john@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
X startup is now handled in xserver-nodm-init.
(From OE-Core rev: 877851cf0f76a5052900954670fb64aed27a7a1f)
Signed-off-by: Jussi Kukkonen <jussi.kukkonen@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This commit should provide the same functionality as before, but
should make meta-oe xserver-nodm-init-2.0 obsolete as well as
keep systemd and sysvinit startup better in sync.
/etc/X11/Xserver is not called anymore: it is provided by both
x11-common and xserver-common with no useful differences (but some
annoying ones). Instead xserver-nodm-init provides
/etc/xserver-nodm/Xserver as the startup script and
/etc/default/xserver-nodm as the default settings file. These are
used by both init systems.
The Xserver script could be completely removed (with sysv and
systemd calling xinit directly), but to keep compatibility with
meta-oes xserver-nodm-init-2.0 the Xserver script sources
/etc/X11/xserver-common if one exists -- and systemd EnvironmentFile
cannot do that.
x11-common used to have a packageconfig to easily control screen
blanking. Move this to xserver-nodm-init.
(From OE-Core rev: e8ce3d2626e505924a75de96650abca166fd230a)
Signed-off-by: Jussi Kukkonen <jussi.kukkonen@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
With the recent changes, executing depmod is not needed
anymore.
This simplifies and removes a lot of unnecessary code.
(From OE-Core rev: 8296e258b36a6238605e068e13c1982b1d12fe53)
Signed-off-by: André Draszik <git@andred.net>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The information retrieved via depmod is incomplete with
regards to kernel modules that are dependencies, in
particular where two kernel modules are built from
different source trees / recipes, which leads to incomplete
dependency information for packages created.
So far, our packages created didn't contain dependencies on
packages created by other recipes, as we solely use depmod
for that, and depmod can only work well after *all* kernel
modules have been copied into one place - it doesn't work
well in a staged approach.
Now that all .ko have correct dependency information at packaging
time, we can use that information to properly track dependencies
across recipies, and can combine the information from the
.modinfo elf section with the information from depmod.
(From OE-Core rev: e4af1fa3aee7f1cf00ca27944b10b886f41f2fda)
Signed-off-by: André Draszik <git@andred.net>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When compiling multiple external kernel modules, where one
depends on the other, there are two problems at the
moment:
1) we get compile time warnings from the kernel build
system due to missing symbols (from modpost).
2) Any modules generated are missing dependency
information (in the .modinfo elf section) for any
dependencies outside the current source tree and
outside the kernel itself.
This is expected, but the kernel build system has a way to
deal with this - the dependent module is expected to
specify KBUILD_EXTRA_SYMBOLS (as a space-separated list)
to point to any and all Module.symvers of kernel modules
that are dependencies.
While 1) by itself is not really a big issue, 2) prevents
the packaging process from generating cross-source tree
package dependencies.
As a first step to solve the missing dependencies in
packages created, we:
1) install Module.symvers of all external kernel module
builds (into a location that is automatically packaged
into the -dev package)
2) make use of KBUILD_EXTRA_SYMBOLS and pass the location
of all Module.symvers of all kernel-module-* packages
we depend on
This solves both problems mentioned above.
(From OE-Core rev: 88f1bc77c22091fccb00e80839adfdf34534187f)
Signed-off-by: André Draszik <git@andred.net>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Integrating the following patch:
[
We try to make this change a generic extension, but it is
actually for a corner case. When a VM (qemu) gets a very limited
cpu bandwidth from host, which could be under a heavy load, the
existing 5000 ms timeout could occur and trigger error messages
in the task function's callers.
This change adds a new timeout parameter so that we can tweak
the value as a workaround or for troubleshooting purposes. In
the infinite wait case, A warning message is printed at 5000ms
interval.
In real world, the current 5 sec is generous enough for a video
request in my opinion, so this change could not be very useful.
Upstream Status: Inappropriate
Signed-off-by: Jianxun Zhang <jianxun.zhang@linux.intel.com>
]
(From OE-Core rev: 872a83be6e86005f6426c90073ece56de4534ac0)
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Some of the meta-data from the 4.4 kernel was missing from the 4.8
branch. This resulted in some functionality drops and also a size/time
increase in the kernel build (due to debug being turned on).
With this resync, we now have the missing config restored.
(From OE-Core rev: eb0b4f05f89ae014953492ea7bc0afc9fef1abce)
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Previously merge_config.sh was wrapped by the configme script, configme
took the different KCONFIG_MODES as options, and used --allnoconfig
or --alldefconfig.
With the switch to merge_config.sh no longer being wrapped, the new
processing wasn't matching the existing values and only supported
allnoconfig or alldefconfig.
To avoid breaking existing layers, and also keep any working that
have already switched, we can make the case statement match both.
(From OE-Core rev: 614227f28a023fe148307e0d85a5e9b8d9b74372)
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Before the kernel tools were simplified and streamlined, there was code
which not only migrated a patch/cfg/scc to the kernel build tree, it
also migrated any subdirectories of those patches.
The effect of this data migration was that any other meta data in
a patch's directory structure would be available for processing.
While we don't want to do this migration anymore, it is possible to
check the path of any SRC_URI patches, and if they include a "kernel-meta"
subdirectory add it to the search path.
This restores the functionality without the old complexity.
(From OE-Core rev: 7ef7af5c03bad28faf380986f792f7f3d4d5944d)
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If we output extra blank lines (because of some automated editing) then
it makes the output recipe look a bit untidy. You could argue that we
should simply have the editing code not do that, but sometimes we don't
have enough context there for that to be practical. It's simple enough
to just filter out the extra blank lines when writing the file, so just
do it that way.
(From OE-Core rev: cbebc9a2edf7d7a422ee5c71219e79e3b349de3b)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If you have your own node.js application you may not publish it (or at
least not immediately) in an npm registry - it might just be in a
repository on github or on your local machine. Add support to recipetool
create for creating recipes to build such applications - extract their
dependencies, fetch them, and add corresponding npm:// URLs to SRC_URI,
and ensure that LICENSE / LIC_FILES_CHKSUM are updated to match. For
example, you can now run:
recipetool create https://github.com/diversario/node-ssdp
(I had to borrow some code from bitbake/lib/bb/fetch2/npm.py to
implement this functionality; this should be refactored out but now
isn't the time to do that refactoring.)
Part of the fix for [YOCTO #9537].
(From OE-Core rev: 4fb8b399c05a1b66986fc76e13525f6c5e0d9b58)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If you make adjustments to the source tree (as create_npm.py will be)
then you will need to re-run the license variable handling code at the
end so that we get all of the files that should go into
LIC_FILES_CHKSUM if nothing else. Split out the license variable
handling to a separate function in order to allow this.
(From OE-Core rev: f0d6f4b7e87ea781ac0dffcc8d0310570975811b)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
For debugging it's useful to be able to tell recipetool to keep the
temporary directory.
(From OE-Core rev: 480a6b745a85b2881e5cc1a0bbb572e3235ca008)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Ensure we fetch submodules and set SRC_URI correctly when pointing to a
git repository that contains submodules.
(From OE-Core rev: 65d5cc62d4ecfc78ce4b37b3886a7fe5aa05a75e)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When trying to map python module dependencies to the packages that
provide them, if we're looking for .so files that satisfy
dependencies then we need to exclude files found under the .debug
directory, otherwise the dependency will get mapped to the python-dbg
package which isn't correct.
For example, this fixes creating a recipe for pyserial and not getting
python-fcntl in RDEPENDS_${PN}, leading to errors when trying to use the
serial module on the target.
(From OE-Core rev: 46a068ca35975988a8e9c0310f71fdcee55937a4)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If AX_PKG_SWIG is found in configure.ac, then what's being looked for is
the swig binary, not swig for the target - so fix the dependency
accordingly.
(From OE-Core rev: 2600cd6f6c63ecf79804e2bc6eb6f198a012d5d6)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.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>
Bitbake collects all events in special event queue when called with
-w option. However, it starts to write events to the eventlog only
after BuildStarted event is received. In some cases this event is
not received at all, e.g. when bitbake is run with --parse-only
command line option.
It makes sense to write all collected events when CookerExit event
received to make sure all events are written into the eventlog even
if BuildStarted event is not fired.
[YOCTO #10145]
(Bitbake rev: 57912de63fa83550c0ae658eb99b76e9cc91a8d1)
Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Toaster script kills runserver process 2 ways:
- sending signal to pid from .toastermain.pid.
- sending signal to pids found by grepping ps output:
ps fux | grep "python.*manage.py runserver"
Second approach is redundant and harmfull as it kills all django
development server running on the machine.
[YOCTO #7973]
(Bitbake rev: 0f47b17fe88dc660648d94b2d8d8286d87ae6295)
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>
This file is not created anywhere, but handled in toaster
script code.
(Bitbake rev: 16f3cd3535c9eec71ea7594c1e3a83db00dba7ca)
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>
There is no point of trying to kill django development server
when toaster starts because 'manage.py checksocket' command is already
used in the script code to check if development server port is occupied.
Even if Toaster is listening on another port, killing previous instance
looks quite implicit and doesn't solve anything as there are other
processes that might be still running.
(Bitbake rev: 0dab45e9815e8939219900264e86f569c714b7c6)
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>
Joshua Lock
Joshua Lock
Robert Yang
Richard Purdie
Jianxun Zhang
Joe Slater
Henry Bruce
Fabio Berton
Bruce Ashfield
Maxin B. John
Jussi Kukkonen
André Draszik
Paul Eggleton
Ed Bartosh