debian.bbclass doesn't work in some setups Was: [oe-commits] Ross Burton : package.bbclass: add a stub implementation of package_name_hook
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 15 lines · On Thu, Jul 10, 2014 at 04:40:12PM +0000, [email protected] wrote:
Module: openembedded-core.git Branch: master Commit: f6eb8e4e44b66217e4ada9f830a058c5ba120932 URL: http://git.openembedded.org/?p=openembedded-core.git&a=commit;h=f6eb8e4e44b66217e4ada9f830a058c5ba120932Author: Ross Burton <[email protected]> Date: Tue Jul 1 16:56:53 2014 +0100package.bbclass: add a stub implementation of
package_name_hook
do_package()callspackage_name_hookso that e.g. debian-style renaming through debian.bbclass can happen. If there is no class providing apackage_name_hookthen this causes "WARNING: Functionpackage_name_hookdoesn't exist" every timedo_package()is executed.
Quoted 4 lines
Silence this warning by providing an empty
package_name_hookin package.bbclass.Signed-off-by Ross Burton <[email protected]>Signed-off-by Saul Wold <[email protected]>
We've discussed this on Friday, so just for reference and people who weren't in #yocto channel
13:52 < JaMa> RP: it seems that debian.bbclass doesn't work with recent changes
13:53 < JaMa> RP: all packagenames lost .so version suffix
13:54 < JaMa> maybe package_name_hook exported from package.bbclass now somehow conflicts with the same function exported by debian.bbclass? 13:54 < JaMa> rburton: ^
13:56 < JaMa> tmp-eglibc/work/arm920tt-oe-linux-gnueabi/libgcc/4.9.0-r0/temp/run.package_name_hook.14013:
13:56 < JaMa> tmp-eglibc/work/arm920tt-oe-linux-gnueabi/libgcc/4.9.0-r0/temp/run.package_package_name_hook.14013:
13:56 < JaMa> both show just empty function
15:03 < rburton> JaMa: whaaaa
15:03 < rburton> i bloody tested that and it bloody worked :(
16:21 < JaMa> rburton: bitbake -e libgcc: http://bpaste.net/show/475166/
16:27 < rburton> JaMa: how interesting
16:28 < pev> Hm, when do you need to set IMAGE_BASENAME? Ive seen it done a couple of times but not sure why/when? 16:28 < rburton> JaMa: python package_name_hook () {
16:28 < rburton> bb.build.exec_func('debian_package_name_hook', d)
16:28 < rburton> }
16:28 < rburton> is what i hae
16:28 < rburton> inherit order?
16:29 < rburton> JaMa: how do you enable debian.bbclass?
16:29 < rburton> poky does INHERIT_DISTRO=debian blaa blaa
16:30 < JaMa> rburton: the same without your patch http://bpaste.net/show/475181/
16:31 < JaMa> env.libgcc:INHERIT=" buildhistory buildstats buildstats-summary blacklist debian shr-mirrors package_ipk debian devshell sstate license blacklist sanity" 16:31 < JaMa> env.libgcc2:INHERIT=" buildhistory buildstats buildstats-summary blacklist debian shr-mirrors package_ipk debian devshell sstate license blacklist sanity" 16:31 < JaMa> $ grep -A 1 "^python package_name_hook" env.libgcc*
16:31 < JaMa> env.libgcc:python package_name_hook () {
16:31 < JaMa> env.libgcc- bb.build.exec_func('package_package_name_hook', d)
16:31 < JaMa> --
16:31 < JaMa> env.libgcc2:python package_name_hook () {
16:31 < JaMa> env.libgcc2- bb.build.exec_func('debian_package_name_hook', d)
16:32 < JaMa> and enabled by:
16:32 < JaMa> # append /OE/build/shr-core/meta-smartphone/meta-shr-distro/conf/distro/shr.conf:70
16:32 < JaMa> # "debian"
16:35 < rburton> maybe this is a distro-inherit vs inherit thing
16:36 < rburton> try using DISTRO_INHERIT for that?
16:36 < rburton> INHERIT_DISTRO even
16:36 < rburton> oh, that's just a variable that gets passed to INHERIT
16:36 < rburton> hm
16:42 < rburton> JaMa: try moving debian after package_ipk 16:43 < rburton> (maybe we need an inherit package in debian)?
16:45 < JaMa> sorry, I've already started different build
16:46 < rburton> np
16:47 < rburton> easily tested outside of a build, i'll have a go in a bit
since then I'm building with this change reverted
Quoted 32 lines
meta/classes/package.bbclass | 12 ++++++++++++ 1 file changed, 12 insertions(+)meta/classes/package.bbclass +12
-0@@ -1119,6 +1119,18 @@ python package_fixsymlinks () { d.setVar('RDEPENDS_' + pkg, bb.utils.join_deps(rdepends, commasep=False)) } + +python package_package_name_hook() { + """ + A package_name_hook function can be used to rewrite the package names by + changing PKG. For an example, see debian.bbclass. + """ + pass +} + +EXPORT_FUNCTIONS package_name_hook + + PKGDESTWORK = "${WORKDIR}/pkgdata" python emit_pkgdata() {Signature · 5 lines
-- _______________________________________________ Openembedded-commits mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-commits
Signature · 1 line
Martin 'JaMa' Jansa jabber: [email protected]
Quoted 9 lines · Martin Jansa
16:42 < rburton> JaMa: try moving debian after
package_ipk16:43 < rburton> (maybe we need an inherit package in debian)?16:45 < JaMa> sorry, I've already started different build
16:46 < rburton> np
16:47 < rburton> easily tested outside of a build, i'll have a go in a bitsince then I'm building with this change reverted
Moving debian to before package_ipkg does indeed replicate the problem with an otherwise pure oe-core. Adding "inherit package" to the top of debian.bbclass appears to fix it - presumably because in your case with the inherit order of debian and then package_ipk the second definition of package_package_name_hook wins.
(export_functions isn't very nice, is it)
Patch incoming.
Ross