openembedded-core.git/meta/classes/package_deb.bbclass, branch master

package.bbclass: Drop EXPORT_FUNCTIONS use against mapping_rename_hook

2012-05-11T17:03:26Z

The usage of this function renaming and it being called using bb.build.exec_func() causes needless indirection loops, confusing log files and seems generally pointless. This simplification makes the process much simpler and faster. I can't come up with a good reason why the export_functions functionality is needed for this function. Signed-off-by: Richard Purdie

classes/package_deb: create .gz index instead of .bz2

2012-04-11T09:58:16Z

apt is looking for Packages.gz files instead of the .bz2 files we are currently creating and failing when they cannot be found. It is not immediately obvious how to make the current version use the .bz2 indexes; thus create .gz indexes for now which allows us to successfully create images. Tested on both a Fedora 14 and an Ubuntu 11.10 host machine. Fixes [YOCTO #1858]. Signed-off-by: Paul Eggleton Signed-off-by: Richard Purdie

package_{deb,ipk,rpm}: apply umask to files generated in do_package_write_{deb,ipk,rpm}

2012-04-04T15:53:49Z

* Explicitly set umask to 022. Otherwise the build system's umask may leak into the image. Signed-off-by: Andreas Oberritter

meta: Replace bb.data.expand(xxx, d) -> d.expand(xxx)

2012-03-05T18:33:18Z

sed \ -e 's:bb.data.\(expand([^,()]*\), *\([^) ]*\) *):\2.\1):g' \ -i `grep -ril bb.data.expand *` Signed-off-by: Richard Purdie

meta/classes: Convert to use appendVar and appendVarFlags

2012-03-05T18:33:18Z

Signed-off-by: Richard Purdie

getVar/setVar cleanups

2011-11-26T22:42:00Z

Complete the bb.data.getVar/setVar replacements with accesses directly to the data store object. Signed-off-by: Richard Purdie

Convert to use direct access to the data store (instead of bb.data.Var())

2011-11-10T11:35:32Z

This is the result of running the following over the metadata: sed \ -e 's:bb.data.\(setVar([^,()]*,[^,()]*\), *\([^ )]*\) *):\2.\1):g' \ -e 's:bb.data.\(setVarFlag([^,()]*,[^,()]*,[^,()]*\), *\([^) ]*\) *):\2.\1):g' \ -e 's:bb.data.\(getVar([^,()]*\), *\([^(), ]*\) *,\([^)]*\)):\2.\1,\3):g' \ -e 's:bb.data.\(getVarFlag([^,()]*,[^,()]*\), *\([^(), ]*\) *,\([^)]*\)):\2.\1,\3):g' \ -e 's:bb.data.\(getVarFlag([^,()]*,[^,()]*\), *\([^() ]*\) *):\2.\1):g' \ -e 's:bb.data.\(getVar([^,()]*\), *\([^) ]*\) *):\2.\1):g' \ -i `grep -ril bb.data *` Signed-off-by: Richard Purdie

deb packages support: switch from /var/dpkg to /var/lib/dpkg

2011-09-21T12:27:35Z

[YOCTO #1086] The pach was backported from OE: http://git.openembedded.net/cgit.cgi/openembedded/commit/?id=41e0fbf792037f249d1b8d283b3de81718887c9f Signed-off-by: Dexuan Cui

package_deb.bbclass, populate_sdk_deb.bbclass: fix meta-toolchain-gmae build

2011-09-15T10:19:42Z

[YOCTO #1070] Currently with deb packaging, we have 2 issues when running "bitbake meta-toolchain-gmae". 1) when MACHINE="qemux86", SDKMACHINE="i686", INSTALL_BASEARCH_DEB is "i686", too. This causes the following ERROR: | E: Couldn't find package task-sdk-host-nativesdk NOTE: package meta-toolchain-gmae-1.0-r6: task do_populate_sdk: Failed This is becasue: due to the DPKG_ARCH mapping, we create such a deb package tmp/deploy/deb/i686-nativesdk/task-sdk-host-nativesdk_1.0-r10_i386.deb; dpkg can't recoginze the package. We need to map INSTALL_BASEARCH_DEB in the same way. 2) when MACHINE="qemux86", SDKMACHINE="x86_64", INSTALL_BASEARCH_DEB is "x86_64", too. We get such an ERROR: | E: Couldn't find package task-cross-canadian-i586 NOTE: package meta-toolchain-gmae-1.0-r6: task do_populate_sdk: Failed This is because: dpkg can't recognize the generated package tmp/deploy/deb/x86_64-nativesdk/task-cross-canadian-i586_1.0-r0_i386.deb Here the "i386" suffix is incorrect and should be "x86_64" -- the i386 comes from the line DPKG_ARCH_i586 ?= "i386" in package_deb.bbclass. However, for canadian package, actually here the overriding of DPKG (from "x86-64" to "i386") should not happen -- it accidently happens just because TARGET_ARCH exists in OVERRIDES. We can move the overriding logic to the anonymous python function to work this around. Signed-off-by: Lianhao Lu Signed-off-by: Dexuan Cui

package_deb.bbclass: put the stderr into log.do_xxx-attemptonly.xxx

2011-09-07T21:28:34Z

Currently the stderr msgs go into log.do_rootfs and can cause a fatal failure in "log_check rootfs". However, the err msg could be spurious since we *only attempt* to install the the packages, which may not exist actually. E.g., without this patch, we can get a fatal ERROR due to E: Couldn't find package task-core-tools-dev. Signed-off-by: Dexuan Cui