summaryrefslogtreecommitdiffstats
path: root/meta/classes/packagefeed-stability.bbclass
AgeCommit message (Collapse)Author
2017-01-31meta: remove remaining True option to getVar callsMing Liu
This is a complementary fix to commit 7c552996: [ meta: remove True option to getVar calls ] it intended to remove all True option to getVar calls, but there are still some remaining. Search made with the following regex: getVar ?\((.*), True\) Signed-off-by: Ming Liu <peter.x.liu@external.atlascopco.com> Signed-off-by: Ross Burton <ross.burton@intel.com>
2017-01-06meta/scripts: Various getVar/getVarFlag expansion parameter fixesRichard Purdie
There were a few straggling expansion parameter removals left for getVar/getVarFlag where the odd whitespace meant they were missed on previous passes. There were also some plain broken ussages such as: d.getVar('ALTERNATIVE_TARGET', old_name, True) path = d.getVar('PATH', d, True) d.getVar('IMAGE_ROOTFS', 'True') which I've corrected (they happend to work by luck). Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2016-12-16meta: remove True option to getVarFlag callsJoshua Lock
getVarFlag() now defaults to expanding by default, thus remove the True option from getVarFlag() calls with a regex search and replace. Search made with the following regex: getVarFlag ?\(( ?[^,()]*, ?[^,()]*), True\) Signed-off-by: Joshua Lock <joshua.g.lock@intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com>
2016-12-16meta: remove True option to getVar callsJoshua Lock
getVar() now defaults to expanding by default, thus remove the True option from getVar() calls with a regex search and replace. Search made with the following regex: getVar ?\(( ?[^,()]*), True\) Signed-off-by: Joshua Lock <joshua.g.lock@intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com>
2016-08-20packagefeed-stability.bbclass: cleansstate should remove pkgs from deploy dirRobert Yang
"bitbake recipe -ccleansstate" should remove binary pkgs from deploy dir as normal cleansstate does without packagefeed-stability.bbclass. Signed-off-by: Robert Yang <liezhi.yang@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2016-08-10packagefeed-stability.bbclass: fix multilib + rpmRobert Yang
* Fix multilib + rpm since its multilib package name is special. * Update SSTATE_DUPWHITELIST to avoid shared location conflicted error. * Fix message when "not copying", now the messages are: Copying packages for recipe <foo> Not copying packages for recipe <foo> Signed-off-by: Robert Yang <liezhi.yang@windriver.com> Signed-off-by: Ross Burton <ross.burton@intel.com>
2016-07-25packagefeed-stability.bbclass: copy all packages of a recipeRobert Yang
A recipes can generate several rpms such as a.rpm, a-dev.rpm, a-dbg.rpm, when update one of them in the repo, we'd better update all of them, otherwise, there might be a-dev.r0.1.rpm and a-dbg.r0.3.rpm in the repo, which looks strange. Signed-off-by: Robert Yang <liezhi.yang@windriver.com> Signed-off-by: Ross Burton <ross.burton@intel.com>
2016-07-25packagefeed-stability.bbclass: minor fixesRobert Yang
* fix for python3 iteritems() -> items() * Return immediately for native and cross. * Remove the usage of __BBDELTASKS, there is no such var in bitbake. Signed-off-by: Robert Yang <liezhi.yang@windriver.com> Signed-off-by: Ross Burton <ross.burton@intel.com>
2016-07-25packagefeed-stability: add class to help reduce package feed churnPaul Eggleton
When a dependency causes a recipe to effectively be rebuilt, its output may in fact not change; but new packages (with an increased PR value, if using the PR server) will be generated nonetheless. There's no practical way for us to predict whether or not this is going to be the case based solely on the inputs, but we can compare the package output and see if that is materially different and based upon that decide to replace the old package with the new one. This class effectively intercepts packages as they are written out by do_package_write_*, causing them to be written into a different directory where we can compare them to whatever older packages might be in the "real" package feed directory, and avoid copying the new package to the feed if it has not materially changed. We use build-compare to do the package comparison. Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com>