summaryrefslogtreecommitdiffstats
path: root/meta/lib/oe/package.py
Commit message (Collapse)AuthorAgeFilesLines
* split_and_strip_files: regroup hardlinks to make build deterministicEd Bartosh2015-05-151-2/+1
| | | | | | | | | | | | | | | | | | | | | | | Reverted 7c0fd561bad0250a00cef63e3d787573112a59cf Created separate group of hardlinks for the files inside the same package. This should prevent stripped files to be populated outside of package directories. This turns out not to be straightforward and has overlap with the other hardlink handling code in this area. The code is condensed into a more concise and documented form. [Original patch from Ed with tweaks from RP] [YOCTO #7586] (From OE-Core master rev: 82d00f7254b7d3bb6a167d675d798134884d1b19) (From OE-Core rev: 2abacf00ee3f60735bf7c0dc7130c72267822b30) Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* meta/lib/oe/package.py: fix files ownership in packagesFabrice Coulon2015-03-201-1/+1
| | | | | | | | | | | | | | | | This fix solves the problem with the ownership of files in packages. The do_install task was producing correct and expected output but when the files were being put in, e.g. a rpm package, the ownership could be different than that in the do_install task. [YOCTO #7428] (From OE-Core rev: 1a50cc5aeafff0d8ee6c4a41dd2770ecd31455f0) Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com> Signed-off-by: Fabrice Coulon <fabrice.coulon@axis.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* lib/oe/package: Ensure strip breaks hardlinksRichard Purdie2015-01-231-1/+2
| | | | | | | | | | | | | Normally, strip preserves hardlinks which in the case of the way our hardlink rather than copy functionality works, is a disadvantage and leads to non-deterministic builds. This adds a move into place after the strip operation to ensure hardlinks are broken and we bring back build determinism. (From OE-Core rev: 7c0fd561bad0250a00cef63e3d787573112a59cf) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* classes/package: move read_shlib_providers() to a common unitPaul Eggleton2014-12-211-0/+26
| | | | | | | | | This allows us to use this function elsewhere in the code. (From OE-Core rev: 657cff8a0f0e5db171b2ed9388a790ee0b135842) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* package.py: use subprocess.Popen for rpmdeps callMartin Jansa2014-03-071-4/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | * I've noticed errors like this in log.do_package: DEBUG: Executing python function package_do_filedeps sh: 1: Syntax error: "(" unexpected sh: 1: Syntax error: "(" unexpected DEBUG: Python function package_do_filedeps finished which are actually caused by some filenames included in package containing '()' characters Maybe we should change meta/classes/package.bbclass to fail when some filedeprunner call fails like this and fix filedeprunner to escape '()' and other possibly dangerous chars it's called like this: processed = list(pool.imap(oe.package.filedeprunner, pkglist)) * don't use shell=True * show the command when it fails and let do_package task to fail (From OE-Core rev: 148c04c1bf39ca0d21288fdce61c51dc8e1c3226) Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com> Signed-off-by: Saul Wold <sgw@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* package: Process package stripping in parallelRichard Purdie2013-02-061-0/+45
| | | | | | (From OE-Core rev: 981fed49ee80560fb067b3f47aeada1fdee792ca) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* package.bbclass: Multithread per file dependency generation codeRichard Purdie2013-02-061-0/+51
(From OE-Core rev: b659eb0f2070149d9516c129b3853b41fbbd1033) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>