fix install package "postinst-intercept pointercal-xinput oprofileui avahi" to image failed

PATCH Superseded Hongxu Jia 5 participants 19 messages Nov 7, 2014 – Nov 11, 2014 2 messages not in the archive

lore

Share & tools

lore

Hongxu Jia

author

2014-11-07 07:57 UTC #0 lore raw

cover fix install package "postinst-intercept pointercal-xinput oprofileui avahi" to image failed

vim local.conf
...
IMAGE_INSTALL_append = " pointercal-xinput oprofileui avahi"
...

bitbake core-image-minimal

//Hongxu

The following changes since commit 9bfd0dee4f585825f27d314c4fd7cd26cf93da79:

poky-tiny.conf: remove inherit of blacklist (2014-11-04 15:14:23 +0000)

are available in the git repository at:

git://git.pokylinux.org/poky-contrib hongxu/fix-nonexist-pkg
http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=hongxu/fix-nonexist-pkg

Hongxu Jia (4):
avahi.inc: use avahi-daemon as avahi's provider
oprofileui: use oprofileui-viewer as oprofileui's provider
pointercal-xinput: add the missing ALLOW_EMPTY
postinst-intercept: rename recipe for nativesdk only

 meta/recipes-connectivity/avahi/avahi.inc                          | 2 ++
 ...stinst-intercept_1.0.bb => nativesdk-postinst-intercept_1.0.bb} | 6 +++---
 meta/recipes-graphics/xinput-calibrator/pointercal-xinput_0.0.bb   | 1 +
 meta/recipes-kernel/oprofile/oprofileui_git.bb                     | 7 ++++---
 4 files changed, 10 insertions(+), 6 deletions(-)
 rename meta/recipes-devtools/postinst-intercept/{postinst-intercept_1.0.bb => nativesdk-postinst-intercept_1.0.bb} (83%)

Signature · 1 line

1.9.1

Hongxu Jia

author

2014-11-07 07:57 UTC #1 lore raw

PATCH 1/4 avahi.inc: use avahi-daemon as avahi's provider

The package avahi does not exist, so we use avahi-daemon as the provider. It avoids the do_rootfs failure while IMAGE_INSTALL += "avahi"

[YOCTO #6937]

Signed-off-by Hongxu Jia <[email protected]>

---
 meta/recipes-connectivity/avahi/avahi.inc | 2 ++
 1 file changed, 2 insertions(+)

meta/recipes-connectivity/avahi/avahi.inc +2 -0

index b060437..5573372 100644
@@ -76,6 +76,8 @@ PACKAGES =+ "avahi-daemon libavahi-common libavahi-core libavahi-client avahi-dn
 # As avahi doesn't put any files into PN, clear the files list to avoid problems
 # if extra libraries appear.
 FILES_avahi = ""
+# Let avahi-daemon to provide avahi
+RPROVIDES_avahi-daemon = "avahi"
 FILES_avahi-autoipd = "${sbindir}/avahi-autoipd \
                        ${sysconfdir}/avahi/avahi-autoipd.action \
                        ${sysconfdir}/dhcp/*/avahi-autoipd \

Signature · 1 line

1.9.1

Martin Jansa

2014-11-07 14:38 UTC #2 lore raw

Re: [PATCH 1/4] avahi.inc: use avahi-daemon as avahi's provider

Quoted 2 lines · Hongxu Jia

The package avahi does not exist, so we use avahi-daemon as the provider. It avoids the do_rootfs failure while IMAGE_INSTALL += "avahi"

Why don't you fix your IMAGE_INSTALL instead?

Quoted 29 lines

[YOCTO #6937]

Signed-off-by Hongxu Jia <[email protected]>

---
 meta/recipes-connectivity/avahi/avahi.inc | 2 ++
 1 file changed, 2 insertions(+)

meta/recipes-connectivity/avahi/avahi.inc +2 -0

index b060437..5573372 100644
@@ -76,6 +76,8 @@ PACKAGES =+ "avahi-daemon libavahi-common libavahi-core libavahi-client avahi-dn
 # As avahi doesn't put any files into PN, clear the files list to avoid problems
 # if extra libraries appear.
 FILES_avahi = ""
+# Let avahi-daemon to provide avahi
+RPROVIDES_avahi-daemon = "avahi"
 FILES_avahi-autoipd = "${sbindir}/avahi-autoipd \
                        ${sysconfdir}/avahi/avahi-autoipd.action \
                        ${sysconfdir}/dhcp/*/avahi-autoipd \

Signature · 7 lines

1.9.1

-- 
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Signature · 1 line

Martin 'JaMa' Jansa     jabber: [email protected]

Burton, Ross

2014-11-07 14:43 UTC #3 lore raw

Re: [PATCH 1/4] avahi.inc: use avahi-daemon as avahi's provider

Quoted 5 lines · Martin Jansa

Quoted 2 lines · Hongxu Jia
The package avahi does not exist, so we use avahi-daemon as the provider. It avoids the do_rootfs failure while IMAGE_INSTALL += "avahi"
Why don't you fix your IMAGE_INSTALL instead?

Or propose the recipe is changed so that the daemon is in PN (which rprovides avahi-daemon for compatibility). Providing PN seems like the worst solution.

Ross

Hongxu Jia

author

2014-11-08 02:31 UTC #4 lore raw

Re: [PATCH 1/4] avahi.inc: use avahi-daemon as avahi's provider

Quoted 8 lines · Ross

On 7 November 2014 14:38, Martin Jansa <[email protected] <mailto:[email protected]>> wrote:
On Fri, Nov 07, 2014 at 03:57:01PM +0800, Hongxu Jia wrote:
> The package avahi does not exist, so we use avahi-daemon as the provider.
> It avoids the do_rootfs failure while IMAGE_INSTALL += "avahi"

Quoted 5 lines

Why don't you fix your IMAGE_INSTALL instead?
Or propose the recipe is changed so that the daemon is in PN (which rprovides avahi-daemon for compatibility). Providing PN seems like the worst solution.

Good idea, V2 incoming

//Hongxu

Quoted 1 line

Ross

Koen Kooi

2014-11-08 18:53 UTC #5 lore raw

Re: [PATCH 1/4] avahi.inc: use avahi-daemon as avahi's provider

In reply to Martin Jansa

Quoted 8 lines

Op 7 nov. 2014, om 15:38 heeft Martin Jansa <[email protected]> het volgende geschreven:
Quoted 2 lines · Hongxu Jia
The package avahi does not exist, so we use avahi-daemon as the provider. It avoids the do_rootfs failure while IMAGE_INSTALL += "avahi"
Why don't you fix your IMAGE_INSTALL instead?

I agree with Martin, this is a non-problem, please fix your IMAGE_INSTALL.

Hongxu Jia

author

2014-11-10 02:02 UTC #6 lore raw

Re: [PATCH 1/4] avahi.inc: use avahi-daemon as avahi's provider

Quoted 7 lines · Koen Kooi

Quoted 6 lines
Op 7 nov. 2014, om 15:38 heeft Martin Jansa <[email protected]> het volgende geschreven:
Quoted 2 lines · Hongxu Jia
The package avahi does not exist, so we use avahi-daemon as the provider. It avoids the do_rootfs failure while IMAGE_INSTALL += "avahi"
Why don't you fix your IMAGE_INSTALL instead?
I agree with Martin, this is a non-problem, please fix your IMAGE_INSTALL.

I am afraid it is not the issue of IMAGE_INSTALL

As doc said:
http://www.yoctoproject.org/docs/1.5/ref-manual/ref-manual.html#var-IMAGE_INSTALL
Variable IMAGE_INSTALL is used to specify the packages to install into an image.

While adding some packages to image ,the rpm based do_rootfs failed with '*** not found in the base feeds'

The failure was caused by two kinds of situations:
1. Package does not exist (such as python3), but provided by other package (such as python-core), the rpm based do_rootfs could not search its provider. And the deb/ ipk based do_rootfs worked well, it is a defect, and I have fixed it (patch sent to community, YOCTO 6918);

2. Package does not exist, and no other package provides it, the package installation will fail in any type do_rootfs. We met this issue when we set IMAGE_INSTALL = "recipe_name", but we don't have the package with that name.

I think what I do is to fix the situation 2.

Further more, we should add checking at the package generating time, if the package *with recipe name* was empty and not created, trigger a warn and according the warn, we could fix the issue recipes.

We already have that checking at the package generating time, but it a note, not warn. I suggest we should use warn instead.

//Hongxu

Martin Jansa

2014-11-10 06:42 UTC #7 lore raw

Re: [PATCH 1/4] avahi.inc: use avahi-daemon as avahi's provider

Quoted 31 lines · Hongxu Jia

Quoted 7 lines · Koen Kooi
Quoted 6 lines
Op 7 nov. 2014, om 15:38 heeft Martin Jansa <[email protected]> het volgende geschreven:
Quoted 2 lines · Hongxu Jia
The package avahi does not exist, so we use avahi-daemon as the provider. It avoids the do_rootfs failure while IMAGE_INSTALL += "avahi"
Why don't you fix your IMAGE_INSTALL instead?
I agree with Martin, this is a non-problem, please fix your IMAGE_INSTALL.
I am afraid it is not the issue of IMAGE_INSTALL
As doc said:
http://www.yoctoproject.org/docs/1.5/ref-manual/ref-manual.html#var-IMAGE_INSTALL
Variable IMAGE_INSTALL is used to specify the packages to install into an image.
While adding some packages to image ,the rpm based do_rootfs failed with '*** not found in the base feeds'
The failure was caused by two kinds of situations:
1. Package does not exist (such as python3), but provided by other package (such as python-core), the rpm based do_rootfs could not search its provider. And the deb/ ipk based do_rootfs worked well, it is a defect, and I have fixed it (patch sent to community, YOCTO 6918);
2. Package does not exist, and no other package provides it, the package installation will fail in any type do_rootfs. We met this issue when we set IMAGE_INSTALL = "recipe_name", but we don't have the package with that name.

Quoted 5 lines

I think what I do is to fix the situation 2.
Further more, we should add checking at the package generating time, if the package *with recipe name* was empty and not created, trigger a warn and according the warn, we could fix the issue recipes.

The docs say that IMAGE_INSTALL is for "package_name". So I think it's correct that it fails when you put "recipe_name" in it and sometimes there isn't any package with the same name. It's the same as trying to make RDEPENDS/DEPENDS entries to be interchangeable (putting recipe_names to RDEPENDS and package_names to DEPENDS)."

Especially with that patch for xinput-pointercal, if user explicitly asks for installing xinput-pointercal, what's the reason to create him completely empty package? IMHO it's only hiding that issue from him and instead of discovering the issue in do_rootfs task, he has to check generated rootfs or even boot the device.

Quoted 5 lines

We already have that checking at the package generating time, but it a note, not warn. I suggest we should use warn instead.
//Hongxu

Signature · 1 line

Martin 'JaMa' Jansa     jabber: [email protected]

Hongxu Jia

author

2014-11-10 07:35 UTC #8 lore raw

Re: [PATCH 1/4] avahi.inc: use avahi-daemon as avahi's provider

Quoted 11 lines · Martin Jansa

The docs say that IMAGE_INSTALL is for "package_name". So I think it's correct that it fails when you put "recipe_name" in it and sometimes there isn't any package with the same name. It's the same as trying to make RDEPENDS/DEPENDS entries to be interchangeable (putting recipe_names to RDEPENDS and package_names to DEPENDS)."
Especially with that patch for xinput-pointercal, if user explicitly asks for installing xinput-pointercal, what's the reason to create him completely empty package? IMHO it's only hiding that issue from him and instead of discovering the issue in do_rootfs task, he has to check generated rootfs or even boot the device.

For most recipes, they generate packages with recipe name, it is not convenience to figure out the different between package_name and recipe_name, especially for newbies, which I means we should reduce that convenience, build relationship between recipe and package, especially when the recipe doesn't generate the same name package.

As you said, for specific recipes, we don't want to generate packages, it doesn't make sense to install it by setting IMAGE_INSTALL. But if the recipe generate packages, it is reasonable to take one with recipe name, take python3 for example, it choose python-core as the provider.

That's why I sent patch for avahi and oprofileui. The avahi didn't generate package avahi, but it is reasonable to choose avahi-daemon, as the SUMMARY said it is a IPv4 configuration daemon.

For oprofileui, it only generates package oprofileui-viewer, if we have oprofileui as its nick name, I think it is more convenience for the users.

//Hongxu

Koen Kooi

2014-11-11 09:02 UTC #9 lore raw

Re: [PATCH 1/4] avahi.inc: use avahi-daemon as avahi's provider

Quoted 16 lines

Op 10 nov. 2014, om 08:35 heeft Hongxu Jia <[email protected]> het volgende geschreven:
Quoted 11 lines · Martin Jansa
The docs say that IMAGE_INSTALL is for "package_name". So I think it's correct that it fails when you put "recipe_name" in it and sometimes there isn't any package with the same name. It's the same as trying to make RDEPENDS/DEPENDS entries to be interchangeable (putting recipe_names to RDEPENDS and package_names to DEPENDS)."
Especially with that patch for xinput-pointercal, if user explicitly asks for installing xinput-pointercal, what's the reason to create him completely empty package? IMHO it's only hiding that issue from him and instead of discovering the issue in do_rootfs task, he has to check generated rootfs or even boot the device.

Quoted 5 lines

For most recipes, they generate packages with recipe name, it is not convenience to figure out the different between package_name and recipe_name, especially for newbies, which I means we should reduce that convenience, build relationship between recipe and package, especially when the recipe doesn't generate the same name package.

It is not a bug when recipe foo.bb doesn't generate foo.ipk. Your changes introduce needless churn and break upgrade paths only to cater to people making wrong assumptions.

Hongxu Jia

author

2014-11-11 09:19 UTC #10 lore raw

Re: [PATCH 1/4] avahi.inc: use avahi-daemon as avahi's provider

Quoted 1 line · Koen Kooi

It is not a bug when recipe foo.bb doesn't generate foo.ipk. Your changes introduce needless churn and break upgrade paths only to cater to people making wrong assumptions.

Except on purpose to not generate recipe_name package, the other situation is indeed a bug, such as ssmping and pimd, it don't generate any package at all.

http://cgit.openembedded.org/meta-openembedded/commit/?id=4b6970c24c3fb0926fd700678c0e11de43a5bf92
http://cgit.openembedded.org/meta-openembedded/commit/?id=c5398fc0fe246e4828c9e950f779f437266bfaa1

If the "Your chagnes" means add checking about the non-create package, I think you are right, many recipe don't want generate recipe_name package on purpose, we should avoid that noisy warning, maybe we should add a script to do that on the result of world build.

But if the "Your chagnes" means the above fix, I think these fixes is reasonable for users, especially for newbies. (Actually the issues were reported by our customer)

//Hongxu

Hongxu Jia

author

2014-11-07 07:57 UTC #11 lore raw

PATCH 2/4 oprofileui: use oprofileui-viewer as oprofileui's provider

In reply to Hongxu Jia

The package oprofileui does not exist, so we use oprofileui-viewer as the provider. It avoids the do_rootfs failure while IMAGE_INSTALL += "oprofileui"

Use ${PN} to instead of the hardcoded oprofileui.

[YOCTO #6937]

Signed-off-by Hongxu Jia <[email protected]>

---
 meta/recipes-kernel/oprofile/oprofileui_git.bb | 7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)

meta/recipes-kernel/oprofile/oprofileui_git.bb +4 -3

index bb69d54..ed6ab93 100644
@@ -11,7 +11,8 @@ SRC_URI = "git://git.yoctoproject.org/oprofileui"
 
 EXTRA_OECONF += "--enable-client --disable-server"
 
-PACKAGES =+ "oprofileui-viewer"
+PACKAGES =+ "${PN}-viewer"
+RPROVIDES_${PN}-viewer = "${PN}"
 
-FILES_oprofileui-viewer = "${bindir}/oparchconv ${bindir}/oprofile-viewer ${datadir}/applications/ ${datadir}/oprofileui/ ${datadir}/icons"
-RDEPENDS_oprofileui-viewer = "oprofile"
+FILES_${PN}-viewer = "${bindir}/oparchconv ${bindir}/oprofile-viewer ${datadir}/applications/ ${datadir}/oprofileui/ ${datadir}/icons"
+RDEPENDS_${PN}-viewer = "oprofile"

Signature · 1 line

1.9.1

Burton, Ross

2014-11-07 12:06 UTC #12 lore raw

Re: [PATCH 2/4] oprofileui: use oprofileui-viewer as oprofileui's provider

Quoted 4 lines · Hongxu Jia

The package oprofileui does not exist, so we use oprofileui-viewer as the provider. It avoids the do_rootfs failure while IMAGE_INSTALL += "oprofileui"

Erm, meta/recipes-kernel/oprofile/oprofileui_git.bb?

Ross

Burton, Ross

2014-11-07 14:48 UTC #13 lore raw

Re: [PATCH 2/4] oprofileui: use oprofileui-viewer as oprofileui's provider

Quoted 9 lines · Ross

Quoted 4 lines · Hongxu Jia
The package oprofileui does not exist, so we use oprofileui-viewer as the provider. It avoids the do_rootfs failure while IMAGE_INSTALL += "oprofileui"
Erm, meta/recipes-kernel/oprofile/oprofileui_git.bb

Sorry, my mistake at not reading properly.

Looks like a better fix would be to fix the packaging and provide the old name for compatibility.

Ross

Hongxu Jia

author

2014-11-08 09:20 UTC #14 lore raw

Re: [PATCH 2/4] oprofileui: use oprofileui-viewer as oprofileui's provider

Quoted 13 lines · Ross

On 7 November 2014 12:06, Burton, Ross <[email protected] <mailto:[email protected]>> wrote:
On 7 November 2014 07:57, Hongxu Jia <[email protected] <mailto:[email protected]>> wrote:
The package oprofileui does not exist, so we use oprofileui-viewer as
the provider. It avoids the do_rootfs failure while IMAGE_INSTALL +=
"oprofileui"

Quoted 8 lines

Erm, meta/recipes-kernel/oprofile/oprofileui_git.bb
<http://oprofileui_git.bb>
Sorry, my mistake at not reading properly.
Looks like a better fix would be to fix the packaging and provide the old name for compatibility.

You mean refer [PATCH 1/4] avahi, change the ${PN}-viewer to PN (which rprovides ${PN}-viewer for compatibility)?

Or I don't understand what 'fix the packaging' mean, modify package.bbclass?

//Hongxu

Quoted 1 line

Ross

Hongxu Jia

author

2014-11-07 07:57 UTC #15 lore raw

PATCH 3/4 pointercal-xinput: add the missing ALLOW_EMPTY

In reply to Hongxu Jia

Since the do_install conditionally install file if it has a contents, it should allow the package empty.

It avoids the do_rootfs failure while IMAGE_INSTALL += "pointercal-xinput"

[YOCTO #6937]

Signed-off-by Hongxu Jia <[email protected]>

---
 meta/recipes-graphics/xinput-calibrator/pointercal-xinput_0.0.bb | 1 +
 1 file changed, 1 insertion(+)

meta/recipes-graphics/xinput-calibrator/pointercal-xinput_0.0.bb +1 -0

index 65348c3..ebc5155 100644
@@ -16,5 +16,6 @@ do_install() {
     fi
 }
 
+ALLOW_EMPTY_${PN} = "1"
 PACKAGE_ARCH = "${MACHINE_ARCH}"
 CONFFILES_${PN} = "${sysconfdir}/pointercal.xinput"

Signature · 1 line

1.9.1

Martin Jansa

2014-11-07 14:49 UTC #16 lore raw

Re: [PATCH 3/4] pointercal-xinput: add the missing ALLOW_EMPTY

Quoted 4 lines · Hongxu Jia

Since the do_install conditionally install file if it has a contents, it should allow the package empty.
It avoids the do_rootfs failure while IMAGE_INSTALL += "pointercal-xinput"

It was removed intentionally

http://git.openembedded.org/meta-openembedded/commit/?id=9477e53e8a8ffde17b558ac436550687db4b86a0

Quoted 26 lines

[YOCTO #6937]

Signed-off-by Hongxu Jia <[email protected]>

---
 meta/recipes-graphics/xinput-calibrator/pointercal-xinput_0.0.bb | 1 +
 1 file changed, 1 insertion(+)

meta/recipes-graphics/xinput-calibrator/pointercal-xinput_0.0.bb +1 -0

index 65348c3..ebc5155 100644
@@ -16,5 +16,6 @@ do_install() {
     fi
 }
 
+ALLOW_EMPTY_${PN} = "1"
 PACKAGE_ARCH = "${MACHINE_ARCH}"
 CONFFILES_${PN} = "${sysconfdir}/pointercal.xinput"

Signature · 7 lines

1.9.1

-- 
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Signature · 1 line

Martin 'JaMa' Jansa     jabber: [email protected]

Hongxu Jia

author

2014-11-07 07:57 UTC #17 lore raw

PATCH 4/4 postinst-intercept: rename recipe for nativesdk only

In reply to Hongxu Jia

The recipe postinst-intercept is only used for nativesdk, so we rename it from postinst-intercept to nativesdk-postinst-intercept.

It avoids unnecessary build of postinst-intercept.

[YOCTO #6937]

Signed-off-by Hongxu Jia <[email protected]>

---
 ...ostinst-intercept_1.0.bb => nativesdk-postinst-intercept_1.0.bb} | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)
 rename meta/recipes-devtools/postinst-intercept/{postinst-intercept_1.0.bb => nativesdk-postinst-intercept_1.0.bb} (83%)

meta/recipes-devtools/postinst-intercept/nativesdk-postinst-intercept_1.0.bb renamed from meta/recipes-devtools/postinst-intercept/postinst-intercept_1.0.bb +3 -3

similarity index 83%
rename from meta/recipes-devtools/postinst-intercept/postinst-intercept_1.0.bb
rename to meta/recipes-devtools/postinst-intercept/nativesdk-postinst-intercept_1.0.bb
index 41b9a6e..7dc45c6 100644
@@ -2,12 +2,12 @@ SUMMARY = "Postinstall scriptlets"
 LICENSE = "MIT"
 LIC_FILES_CHKSUM = "file://${COREBASE}/meta/COPYING.MIT;md5=3da9cfbcb788c80a0384361b4de20420"
 
-FILES_${PN}_append_class-nativesdk = " ${datadir}/postinst-intercepts/*"
+FILES_${PN}_append = " ${datadir}/postinst-intercepts/*"
 
 do_configure[noexec] = "1"
 do_compile[noexec] = "1"
 
-do_install_append_class-nativesdk() {
+do_install() {
 	install -d ${D}${datadir}/postinst-intercepts
 	install -m 755 ${COREBASE}/scripts/postinst-intercepts/postinst_intercept ${D}${datadir}/postinst-intercepts/
 	install -m 755 ${COREBASE}/scripts/postinst-intercepts/update_font_cache ${D}${datadir}/postinst-intercepts/

@@ -15,5 +15,5 @@ do_install_append_class-nativesdk() {
 	install -m 755 ${COREBASE}/scripts/postinst-intercepts/update_pixbuf_cache ${D}${datadir}/postinst-intercepts/
 }
 
-BBCLASSEXTEND = "nativesdk"
+inherit nativesdk
 INHIBIT_DEFAULT_DEPS = "1"

Signature · 1 line

1.9.1

A message that is not in the archive (sent off-list or not yet received): CALbNGRTsV6udERwG8XBoxuoFVqeyexwM46-u1Ot__AFBD_TAUg@mail.gmail.com

A message that is not in the archive (sent off-list or not yet received): [email protected]

Andreas Müller

2014-11-07 09:28 UTC #20 lore raw

Re: [PATCH 4/4] postinst-intercept: rename recipe for nativesdk only

Quoted 68 lines · Hongxu Jia

Quoted 58 lines · Andreas Müller
Quoted 55 lines · Hongxu Jia
The recipe postinst-intercept is only used for nativesdk, so we rename it from postinst-intercept to nativesdk-postinst-intercept.
It avoids unnecessary build of postinst-intercept.
[YOCTO #6937]
Signed-off-by Hongxu Jia <[email protected]>
---
  ...ostinst-intercept_1.0.bb => nativesdk-postinst-intercept_1.0.bb} | 6
+++---
  1 file changed, 3 insertions(+), 3 deletions(-)
rename
meta/recipes-devtools/postinst-intercept/{postinst-intercept_1.0.bb => nativesdk-postinst-intercept_1.0.bb} (83%)
diff --git a/meta/recipes-devtools/postinst-intercept/postinst-intercept_1.0.bb b/meta/recipes-devtools/postinst-intercept/nativesdk-postinst-intercept_1.0.bb similarity index 83%
rename from meta/recipes-devtools/postinst-intercept/postinst-intercept_1.0.bb rename to meta/recipes-devtools/postinst-intercept/nativesdk-postinst-intercept_1.0.bb index 41b9a6e..7dc45c6 100644
--- a/meta/recipes-devtools/postinst-intercept/postinst-intercept_1.0.bb
+++
b/meta/recipes-devtools/postinst-intercept/nativesdk-postinst-intercept_1.0.bb
(quoted diff) +0 -0
@@ -2,12 +2,12 @@ SUMMARY = "Postinstall scriptlets"
  LICENSE = "MIT"
  LIC_FILES_CHKSUM =
"file://${COREBASE}/meta/COPYING.MIT;md5=3da9cfbcb788c80a0384361b4de20420"
meta/recipes-devtools/postinst-intercept/nativesdk-postinst-intercept_1.0.bb renamed from meta/recipes-devtools/postinst-intercept/postinst-intercept_1.0.bb +2 -2
-FILES_${PN}_append_class-nativesdk = " ${datadir}/postinst-intercepts/*"
+FILES_${PN}_append = " ${datadir}/postinst-intercepts/*"
 
  do_configure[noexec] = "1"
  do_compile[noexec] = "1"
 
-do_install_append_class-nativesdk() {
+do_install() {
         install -d ${D}${datadir}/postinst-intercepts
         install -m 755
${COREBASE}/scripts/postinst-intercepts/postinst_intercept ${D}${datadir}/postinst-intercepts/
         install -m 755
${COREBASE}/scripts/postinst-intercepts/update_font_cache ${D}${datadir}/postinst-intercepts/
(quoted diff) +0 -0
@@ -15,5 +15,5 @@ do_install_append_class-nativesdk() {
         install -m 755
${COREBASE}/scripts/postinst-intercepts/update_pixbuf_cache ${D}${datadir}/postinst-intercepts/
}
Quoted 7 lines
Quoted 6 lines
meta/recipes-devtools/postinst-intercept/nativesdk-postinst-intercept_1.0.bb renamed from meta/recipes-devtools/postinst-intercept/postinst-intercept_1.0.bb +1 -2
-BBCLASSEXTEND = "nativesdk"
+inherit nativesdk
  INHIBIT_DEFAULT_DEPS = "1"
--
1.9.1
is it possible that the commit message does not match to the patch?

Quoted 10 lines

You mean the patch doesn't match with cover letter or the patch's commit message?
Rename it is to avoid to install postinst-intercept, that will let build postinst-intercept
invalid at parsing time rather than failed at image's do_root.
//Hongxu

Aargh - I did not read the patch properly - should learn not to write coffee-less comments

Andreas