| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Sometimes it is convenient to prepare a bootable image from the
host rather than using a live-image to install to a disk on the
target.
This script takes a live image as input, partitions a device, and
performs the installation just as the installer would if run on
the target.
(From OE-Core rev: 7225c6739f9f1e51741a42437692868165aa1dfe)
Signed-off-by: Darren Hart <dvhart@linux.intel.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
oe-core removed the prerequisite to have sh as bash. POSIX doesn't define
any options and furthermore allows 'echo -e' to be the default behavior.
This means that in dash 'echo -e' will actually print '-e' and interpret
backslashes by default. We use instead 'printf' builtin command with or
without '\n' to simulate 'echo -e' or 'echo -n'.
'printf' needs format while 'echo' can be used without any arguments. So
'echo >' was replaced by 'printf "" >'.
'echo' without '-n' flag adds a new line by default so to keep the same
behavior of two new lines while using 'echo "\n"', 'printf "\n\n"' is
used.
[YOCTO #3138]
(From OE-Core rev: a19880ad10ccb5d7d909dcf9de5c3dc58a0ebcd3)
Signed-off-by: Andrei Gherzan <andrei@gherzan.ro>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
|
| |
"Package group" is a much more appropriate name for these than task,
since we use the word task to describe units of work executed by
BitBake.
(From OE-Core rev: 424dcf7046e4ad09dcc664eb1992201195247fcf)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The os.popen function would fail (more or less) silently if the executed
program cannot be found, and here what we need is os.system not os.popen
since it doesn't use the return value, use os.unlink() and ignore
exceptions from it would be better as Chris suggested.
[YOCTO #2454]
(From OE-Core rev: bc9f7d7b7eda1c45ad1aaee469ebe28ee1c0c96b)
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
| |
Add intercept multilib header for pyconfig.h in python.
This is part of the bug fixing [YOCTO #2216].
(From OE-Core rev: 99591085186c465f2ddfaef08f419ec7584d4522)
Signed-off-by: Lianhao Lu <lianhao.lu@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If you install the top-level python package only on a minimal
system which has no other python packages installed then python
is not functional at all. Without any extra packages installed
this error is seen:
# python
Traceback (most recent call last):
File "/usr/lib/python2.7/site.py", line 64, in <module>
import traceback
ImportError: No module named traceback
Installing python-lang only partly fixes the problem as this
error still exists:
# python
Traceback (most recent call last):
File "/usr/lib/python2.7/site.py", line 569, in <module>
main()
File "/usr/lib/python2.7/site.py", line 551, in main
known_paths = addusersitepackages(known_paths)
File "/usr/lib/python2.7/site.py", line 278, in addusersitepackages
user_site = getusersitepackages()
File "/usr/lib/python2.7/site.py", line 253, in getusersitepackages
user_base = getuserbase() # this will also set USER_BASE
File "/usr/lib/python2.7/site.py", line 243, in getuserbase
USER_BASE = get_config_var('userbase')
File "/usr/lib/python2.7/sysconfig.py", line 520, in get_config_var
return get_config_vars().get(name)
File "/usr/lib/python2.7/sysconfig.py", line 400, in get_config_vars
import re
ImportError: No module named re
(From OE-Core rev: c239564c768d0f305d8707103f4c59cf60431670)
Signed-off-by: Gary Thomas <gary@mlbassoc.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fixes [YOCTO #1806]
Standard practice is to use the Linux "dd" command to write images to boot
media. This can be error prone and the results of sloppy usage can be
disastrous. Locating the device you want to use is a clumsy process, especially
on a headless build system.
The ddimage script does the following:
o Check the image and device exist
o Check the device is writable
o Compare the device to a blacklist and abort if it's listed
Blacklist defaults to "/dev/sda"
o Display useful identifying information about the image and device
o Prompt the user before commencing the write
The output looks something like this:
$ sudo ~/bin/ddimage tmp/deploy/images/core-image-sato-fri2-noemgd.hddimg /dev/sdk
Image details
=============
image: `tmp/deploy/images/core-image-sato-fri2-noemgd.hddimg' -> `core-image-sato-fri2-noemgd-20111202214038.hddimg'
size: 318568448 bytes
modified: 2011-12-02 13:45:05.298897861 -0800
type: x86 boot sector, code offset 0x58, OEM-ID "SYSLINUX", sectors/cluster 16, root entries 512, Media descriptor 0xf8, sectors/FAT 152, heads 64, hidden sectors 32, sectors 622204 (volumes > 32 MB) , serial number 0x4ed946e0, label: "boot ", FAT (16 bit)
Device details
==============
device: /dev/sdk
vendor: Kingston
model: DT 101 G2
Write tmp/deploy/images/core-image-sato-fri2-noemgd.hddimg to /dev/sdk [y/N]? y
Writing image...
303+1 records in
303+1 records out
318568448 bytes (319 MB) copied, 53.6766 s, 5.9 MB/s
(From OE-Core rev: 87e581bb7da9f1530d190cd023fcf892c8b858f5)
Signed-off-by: Darren Hart <dvhart@linux.intel.com>
CC: Dexuan Cui <dexuan.cui@intel.com>
CC: Joshua Lock <josh@linux.intel.com>
CC: Kishore K Bodke <kishore.k.bodke@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
| |
(From OE-Core rev: 0030644f4890ca25894916189470317650ec8246)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
| |
COMMERCIAL_LICENSE no longer exists; the equivalent functionality is
now has been replaced by LICENSE_FLAGS_WHITELIST, so replace the
COMMERCIAL_LICENSE warning with a similarly equivalent warning.
(From OE-Core rev: 64e1db588bcb7b66b08097c0ea443bd4406422d3)
Signed-off-by: Tom Zanussi <tom.zanussi@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* move 2to3 to separate package and include lib2to3 (was in python-misc)
* fix pattern for python-unittest (was in python-misc because it's in subdirectory now)
* add pydoc_data to python-pydoc (was in python-misc)
* add more stuff to smtpd, audio, codecs, ctypes, html, io, json, mime,
pickle, stringold, xmlrpc
* move all FILES_ details from python recipe to manifest generator so it's in one place
* added manual line break in FILES_${PN}-core, because git send-email
doesn't like too long lines
$ git send-email -1 dfaae65839f0ab23e5b2ae2a68df0f370bca84d2
fatal: /tmp/k8zbDajUNP/0001-python-improve-packaging.patch: 64: patch contains a line longer than 998 characters
(From OE-Core rev: f17f6b28ed2f62250f8690617e9126a43c3a8020)
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This script is used to enumerate which recipes are building
documentation. It does this by checking that a -doc package
gets generated and contains files.
The script works by building each recipe using the output from
bitbake -s.
It will generate several report files, listing which recipes
include documentation, which are missing documentation, and
which did not successfully build at all.
(From OE-Core rev: d5e5023c67dacf78cd3b6e3593777b30e5a8f05d)
Signed-off-by: Scott Garman <scott.a.garman@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
|
| |
script: add needed files into the python-core package
regenerate python-2.7-manifest.inc file with newer script
(From OE-Core rev: 12fe0f0b503f76995a975b1e87d5d652d7f6a24b)
Signed-off-by: Nitin A Kamble <nitin.a.kamble@intel.com>
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
| |
* it needs to be regenerated to actually package something
(From OE-Core rev: 0a4ac566987950815fc1ae8a0ec0496bd42a46ed)
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
test_build_time.sh is a bash script intended to be used in conjunction
with "git bisect run" in order to find regressions in build time, however
it can also be used independently. It cleans out the build output
directories, runs a specified worker script (an example is
test_build_time_worker.sh) under TIME(1), logs the results, and returns
a value telling "git bisect run" whether the build time is good (under
the specified threshold) or bad (over it).
(From OE-Core rev: d866a36d7839247e8cf61512a0092d7f4f396d1a)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
| |
The bash string operation ${BB##*0} was greedy and in addition to converting
"02" to "2", also converted "20" to "", causing all builds for a BB value ending
in 0 to run with BB_NUMBER_THREADS=1.
(From OE-Core rev: b975de5ea76c5f8827fb48c0c3c29902872ad3d6)
Signed-off-by: Darren Hart <dvhart@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The bb-matrix.sh script will run a bitbake command, building core-image-minimal
by default, for various combinations of BB_NUMBER_THREADS and PARALLEL_MAKE. It
records all relevant metrics of the TIME(1) command for each combination in a
data file.
The bb-matrix-plot.sh script can be used to visualize each of these metrics via
a 3d surface plot, either solid surface or wireframe with a value-map
projection on the XY plane.
(From OE-Core rev: 50fdf562ce5c41782ff1bdea43a20e769e61eb92)
Signed-off-by: Darren Hart <dvhart@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
| |
Python was missing a lot of debug information. Switch to use the default
-dbg package. Also add some additional debug information to the -dbg package.
(From OE-Core rev: 63f4e1b469046753009d0cef498ef09c87c54912)
Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
|
|
|
|
|
|
|
|
|
| |
* imported from OE with sorted entries etc
(From OE-Core rev: 94b36524550ff2c94a5f8d82a9bc2073c06d418a)
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Acked-by: Nitin A Kamble <nitin.a.kamble@intel.com>
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
bbvars.py will compare recipes in meta directories with documentation files
and report on variables that don't appear to be documented. It reports the
number of times a variable is used as well as any doctags present in the
documentation config file.
The output of this is intended to aid in determining where documentation may
be lacking, but it is not perfect, and does generate some false positives. An
experienced eye and careful attention to count and doctag should be applied to
the results.
$ ./bbvars.py -d ../../documentation/poky-ref-manual/poky-ref-manual.html -m ../../meta -t ../../meta/conf/documentation.conf -T | head -n 10
Found 1413 undocumented bb variables (out of 1578):
VARIABLE COUNT DOCTAG
===================================================
BUILD_ARCH 4 The name of the building architecture. E.g. i686.
BUILD_CC_ARCH 2 FIXME
BUILD_PREFIX 4 FIXME
BUILD_SYS 13 FIXME
BUILD_VENDOR 2 FIXME
CACHE 1 The directory holding the cache of the metadata.
COMPATIBLE_HOST 19 A regular expression which matches the HOST_SYS names supported by the package/file. Failure to match will cause the file to be skipped by the parser.
Signed-off-by: Darren Hart <dvhart@linux.intel.com>
CC: Richard Purdie <richard.purdie@linuxfoundation.org>
|