[PATCH 0/1]lib32-packagegroup-core-nfs: fix qa issue - install files into a shared area when those files already exist

[PATCH 0/1]lib32-packagegroup-core-nfs: fix qa issue - install files into a shared area when those files already exist

[Hongxu Jia]

The following changes since commit ea92671d9823e3667d6ced7ac2af20f991da404d:

  bitbake: cooker: replace "w" file opening mode with "a" mode (2013-11-12 17:01:37 +0000)

are available in the git repository at:

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

Hongxu Jia (1):
  lib32-packagegroup-core-nfs: fix qa issue - install files into a
    shared area when those files already exist

 meta/recipes-core/packagegroups/packagegroup-core-nfs.bb | 1 +
 1 file changed, 1 insertion(+)

-- 
1.8.1.2

[PATCH 1/1] lib32-packagegroup-core-nfs: fix qa issue - install files into a shared area when those files already exist

[Hongxu Jia]

By default, packagegroup-core-nfs do not depend on a certain architecture,
there will be qa warning while multilib enabled.

$ bitbake packagegroup-core-nfs
$ bitbake lib32-packagegroup-core-nfs
...
WARNING: The recipe lib32-packagegroup-core-nfs is trying to install files into a shared area when those files already exist. Those files and their manifest location are:
tmp/deploy/rpm/all/packagegroup-core-nfs-server-1.0-r2.0.all.rpm
Matched in manifest-allarch-packagegroup-core-nfs.deploy-rpm
Please verify which package should provide the above files.
...

Set PACKAGE_ARCH with MACHINE_ARCH fixed this issue.

[YOCTO #5532]

Signed-off-by: Hongxu Jia <hongxu.jia@windriver.com>
---
 meta/recipes-core/packagegroups/packagegroup-core-nfs.bb | 1 +
 1 file changed, 1 insertion(+)

diff --git a/meta/recipes-core/packagegroups/packagegroup-core-nfs.bb b/meta/recipes-core/packagegroups/packagegroup-core-nfs.bb
index 531eceb..b57ef63 100644
--- a/meta/recipes-core/packagegroups/packagegroup-core-nfs.bb
+++ b/meta/recipes-core/packagegroups/packagegroup-core-nfs.bb
@@ -7,6 +7,7 @@ LICENSE = "MIT"
 PR = "r2"
 
 inherit packagegroup
+PACKAGE_ARCH = "${MACHINE_ARCH}"
 
 PACKAGES = "${PN}-server"
 
-- 
1.8.1.2

[RFC PATCH 1/1] lib32-packagegroup-core-nfs: fix qa issue - install files into a shared area when those files already exist

[Hongxu Jia]

Hi All,

In this case, there are two 'packagegroup-core-nfs-server-1.0-r2.0.all.rpm'
in tmp/deploy/rpm/all. One is made by 'bitbake packagegroup-core-nfs ',
and the other is made by 'bitbake lib32-packagegroup-core-nfs '.
The last one overrode the previous triggered the QA check.

By default, packagegroup inherit allarch, which means the PACKAGE_ARCH
is "all".

Is it proper that 'all' packages are not supposed to be expanded into the
multilib versions?

There are some other packagegroup recipes have the similar issue.

//Hongxu

On 11/14/2013 05:02 PM, Hongxu Jia wrote:
> By default, packagegroup-core-nfs do not depend on a certain architecture,
> there will be qa warning while multilib enabled.
>
> $ bitbake packagegroup-core-nfs
> $ bitbake lib32-packagegroup-core-nfs
> ...
> WARNING: The recipe lib32-packagegroup-core-nfs is trying to install files into a shared area when those files already exist. Those files and their manifest location are:
> tmp/deploy/rpm/all/packagegroup-core-nfs-server-1.0-r2.0.all.rpm
> Matched in manifest-allarch-packagegroup-core-nfs.deploy-rpm
> Please verify which package should provide the above files.
> ...
>
> Set PACKAGE_ARCH with MACHINE_ARCH fixed this issue.
>
> [YOCTO #5532]
>
> Signed-off-by: Hongxu Jia <hongxu.jia@windriver.com>
> ---
>   meta/recipes-core/packagegroups/packagegroup-core-nfs.bb | 1 +
>   1 file changed, 1 insertion(+)
>
> diff --git a/meta/recipes-core/packagegroups/packagegroup-core-nfs.bb b/meta/recipes-core/packagegroups/packagegroup-core-nfs.bb
> index 531eceb..b57ef63 100644
> --- a/meta/recipes-core/packagegroups/packagegroup-core-nfs.bb
> +++ b/meta/recipes-core/packagegroups/packagegroup-core-nfs.bb
> @@ -7,6 +7,7 @@ LICENSE = "MIT"
>   PR = "r2"
>   
>   inherit packagegroup
> +PACKAGE_ARCH = "${MACHINE_ARCH}"
>   
>   PACKAGES = "${PN}-server"
>   

Re: [RFC PATCH 1/1] lib32-packagegroup-core-nfs: fix qa issue - install files into a shared area when those files already exist

[Richard Purdie]

On Thu, 2013-11-21 at 21:39 +0800, Hongxu Jia wrote:
> Hi All,
> 
> In this case, there are two 'packagegroup-core-nfs-server-1.0-r2.0.all.rpm'
> in tmp/deploy/rpm/all. One is made by 'bitbake packagegroup-core-nfs ',
> and the other is made by 'bitbake lib32-packagegroup-core-nfs '.
> The last one overrode the previous triggered the QA check.
> 
> By default, packagegroup inherit allarch, which means the PACKAGE_ARCH
> is "all".
> 
> Is it proper that 'all' packages are not supposed to be expanded into the
> multilib versions?

Yes.

> There are some other packagegroup recipes have the similar issue.

It sounds like there is some configuration causing this to get rebuild.
Can you run bitbake-diffsigs on the stamps for the two tasks and see why
its building this twice? It sound only happen once.

Cheers,

Richard

Re: [RFC PATCH 1/1] lib32-packagegroup-core-nfs: fix qa issue - install files into a shared area when those files already exist

[Hongxu Jia]

Hi Richard,

1. What is the situation to set PACKAGE_ARCH = "${MACHINE_ARCH}"
in packagegroup recipe?

In this case, MACHINE is qemux86-64, and the packagegroup-core-nfs's
RDEPENDS are:
"packagegroup-core-nfs-server" -> "nfs-utils" [style=dashed]
"packagegroup-core-nfs-server" -> "nfs-utils-client" [style=dashed]

We check one utility in nfs-utils by invoking file:
$ file image/usr/sbin/exportfs
image/usr/sbin/exportfs: ELF 64-bit LSB executable, x86-64,
version 1 (SYSV), dynamically linked (uses shared libs), for
GNU/Linux 2.6.34, not stripped

Should we consider the nfs-utils and lib32-nfs-utils are different
arch? If the answer is yes, the lib32-packagegroup-core-nfs's
RDEPENDS should be:
"lib32-packagegroup-core-nfs-server" -> "lib32-nfs-utils-client" 
[style=dashed]
"lib32-packagegroup-core-nfs-server" -> "lib32-nfs-utils" [style=dashed]

In this situation, I think we should set PACKAGE_ARCH with
"${MACHINE_ARCH}" in packagegroup-core-nfs recipe.

But there are lots of packagegroup packages that didn't have set
PACKAGE_ARCH with "${MACHINE_ARCH}" in their recipe. After a quick
search in oe-core, 7 packagegroup recipes did set and almost 33 didn't,
so how about use PACKAGE_ARCH = "${MACHINE_ARCH}" by default for
packagegroup or just did not inherit allarch in packagegroup.bbclass?

2. What shoud we do if packagegroup packages is allarch?

When the packagegroup packages is allarch and multilib is enabled,
should we still *do the multilib work* for this allarch recipe?
If we do, the override issue happened.

In this case, if we don't set PACKAGE_ARCH with "${MACHINE_ARCH}",
packagegroup-core-nfs and lib32-packagegroup-core-nfs have different
${WORKDIR}:

WORKDIR="${BASE_WORKDIR}/${MULTIMACH_TARGET_SYS}/${PN}/${EXTENDPE}${PV}-${PR}"
MULTIMACH_TARGET_SYS="${PACKAGE_ARCH}${TARGET_VENDOR}-${TARGET_OS}"

In packagegroup-core-nfs, we have:
TARGET_VENDOR="-poky"
PN="packagegroup-core-nfs"

In lib32-packagegroup-core-nfs, after the multilib process we have:
TARGET_VENDOR="-pokymllib32"
PN="lib32-packagegroup-core-nfs"

So we had better to forbid multilib work for the allarch recipe.

//Hongxu

On 11/21/2013 09:50 PM, Richard Purdie wrote:
> On Thu, 2013-11-21 at 21:39 +0800, Hongxu Jia wrote:
>> Hi All,
>>
>> In this case, there are two 'packagegroup-core-nfs-server-1.0-r2.0.all.rpm'
>> in tmp/deploy/rpm/all. One is made by 'bitbake packagegroup-core-nfs ',
>> and the other is made by 'bitbake lib32-packagegroup-core-nfs '.
>> The last one overrode the previous triggered the QA check.
>>
>> By default, packagegroup inherit allarch, which means the PACKAGE_ARCH
>> is "all".
>>
>> Is it proper that 'all' packages are not supposed to be expanded into the
>> multilib versions?
> Yes.
>
>> There are some other packagegroup recipes have the similar issue.
> It sounds like there is some configuration causing this to get rebuild.
> Can you run bitbake-diffsigs on the stamps for the two tasks and see why
> its building this twice? It sound only happen once.
>
> Cheers,
>
> Richard
>

Re: [RFC PATCH 1/1] lib32-packagegroup-core-nfs: fix qa issue - install files into a shared area when those files already exist

[Richard Purdie]

On Fri, 2013-11-22 at 20:21 +0800, Hongxu Jia wrote:
> Hi Richard,
> 
> 1. What is the situation to set PACKAGE_ARCH = "${MACHINE_ARCH}"
> in packagegroup recipe?
> 
> In this case, MACHINE is qemux86-64, and the packagegroup-core-nfs's
> RDEPENDS are:
> "packagegroup-core-nfs-server" -> "nfs-utils" [style=dashed]
> "packagegroup-core-nfs-server" -> "nfs-utils-client" [style=dashed]
> 
> We check one utility in nfs-utils by invoking file:
> $ file image/usr/sbin/exportfs
> image/usr/sbin/exportfs: ELF 64-bit LSB executable, x86-64,
> version 1 (SYSV), dynamically linked (uses shared libs), for
> GNU/Linux 2.6.34, not stripped
> 
> Should we consider the nfs-utils and lib32-nfs-utils are different
> arch? If the answer is yes, the lib32-packagegroup-core-nfs's
> RDEPENDS should be:
> "lib32-packagegroup-core-nfs-server" -> "lib32-nfs-utils-client" 
> [style=dashed]
> "lib32-packagegroup-core-nfs-server" -> "lib32-nfs-utils" [style=dashed]
> 
> In this situation, I think we should set PACKAGE_ARCH with
> "${MACHINE_ARCH}" in packagegroup-core-nfs recipe.
> 
> But there are lots of packagegroup packages that didn't have set
> PACKAGE_ARCH with "${MACHINE_ARCH}" in their recipe. After a quick
> search in oe-core, 7 packagegroup recipes did set and almost 33 didn't,
> so how about use PACKAGE_ARCH = "${MACHINE_ARCH}" by default for
> packagegroup or just did not inherit allarch in packagegroup.bbclass?
> 
> 2. What shoud we do if packagegroup packages is allarch?
> 
> When the packagegroup packages is allarch and multilib is enabled,
> should we still *do the multilib work* for this allarch recipe?
> If we do, the override issue happened.
> 
> In this case, if we don't set PACKAGE_ARCH with "${MACHINE_ARCH}",
> packagegroup-core-nfs and lib32-packagegroup-core-nfs have different
> ${WORKDIR}:
> 
> WORKDIR="${BASE_WORKDIR}/${MULTIMACH_TARGET_SYS}/${PN}/${EXTENDPE}${PV}-${PR}"
> MULTIMACH_TARGET_SYS="${PACKAGE_ARCH}${TARGET_VENDOR}-${TARGET_OS}"
> 
> In packagegroup-core-nfs, we have:
> TARGET_VENDOR="-poky"
> PN="packagegroup-core-nfs"
> 
> In lib32-packagegroup-core-nfs, after the multilib process we have:
> TARGET_VENDOR="-pokymllib32"
> PN="lib32-packagegroup-core-nfs"
> 
> So we had better to forbid multilib work for the allarch recipe.

Do you have
http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=26559c581695f60861483691e08eee06f524287f applied to your tree?

I'm hoping this issue does not exist when that patch is applied.

Cheers,

Richard

Re: [RFC PATCH 1/1] lib32-packagegroup-core-nfs: fix qa issue - install files into a shared area when those files already exist

[Hongxu Jia]

On 11/22/2013 08:27 PM, Richard Purdie wrote:
> On Fri, 2013-11-22 at 20:21 +0800, Hongxu Jia wrote:
>> Hi Richard,
>>
>> 1. What is the situation to set PACKAGE_ARCH = "${MACHINE_ARCH}"
>> in packagegroup recipe?
>>
>> In this case, MACHINE is qemux86-64, and the packagegroup-core-nfs's
>> RDEPENDS are:
>> "packagegroup-core-nfs-server" -> "nfs-utils" [style=dashed]
>> "packagegroup-core-nfs-server" -> "nfs-utils-client" [style=dashed]
>>
>> We check one utility in nfs-utils by invoking file:
>> $ file image/usr/sbin/exportfs
>> image/usr/sbin/exportfs: ELF 64-bit LSB executable, x86-64,
>> version 1 (SYSV), dynamically linked (uses shared libs), for
>> GNU/Linux 2.6.34, not stripped
>>
>> Should we consider the nfs-utils and lib32-nfs-utils are different
>> arch? If the answer is yes, the lib32-packagegroup-core-nfs's
>> RDEPENDS should be:
>> "lib32-packagegroup-core-nfs-server" -> "lib32-nfs-utils-client"
>> [style=dashed]
>> "lib32-packagegroup-core-nfs-server" -> "lib32-nfs-utils" [style=dashed]
>>
>> In this situation, I think we should set PACKAGE_ARCH with
>> "${MACHINE_ARCH}" in packagegroup-core-nfs recipe.
>>
>> But there are lots of packagegroup packages that didn't have set
>> PACKAGE_ARCH with "${MACHINE_ARCH}" in their recipe. After a quick
>> search in oe-core, 7 packagegroup recipes did set and almost 33 didn't,
>> so how about use PACKAGE_ARCH = "${MACHINE_ARCH}" by default for
>> packagegroup or just did not inherit allarch in packagegroup.bbclass?
>>
>> 2. What shoud we do if packagegroup packages is allarch?
>>
>> When the packagegroup packages is allarch and multilib is enabled,
>> should we still *do the multilib work* for this allarch recipe?
>> If we do, the override issue happened.
>>
>> In this case, if we don't set PACKAGE_ARCH with "${MACHINE_ARCH}",
>> packagegroup-core-nfs and lib32-packagegroup-core-nfs have different
>> ${WORKDIR}:
>>
>> WORKDIR="${BASE_WORKDIR}/${MULTIMACH_TARGET_SYS}/${PN}/${EXTENDPE}${PV}-${PR}"
>> MULTIMACH_TARGET_SYS="${PACKAGE_ARCH}${TARGET_VENDOR}-${TARGET_OS}"
>>
>> In packagegroup-core-nfs, we have:
>> TARGET_VENDOR="-poky"
>> PN="packagegroup-core-nfs"
>>
>> In lib32-packagegroup-core-nfs, after the multilib process we have:
>> TARGET_VENDOR="-pokymllib32"
>> PN="lib32-packagegroup-core-nfs"
>>
>> So we had better to forbid multilib work for the allarch recipe.
> Do you have
> http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=26559c581695f60861483691e08eee06f524287f applied to your tree?

Yes, I have that commit on my poky/master, the issue still existed.

//Hongxu

> I'm hoping this issue does not exist when that patch is applied.
>
> Cheers,
>
> Richard
>

Re: [RFC PATCH 1/1] lib32-packagegroup-core-nfs: fix qa issue - install files into a shared area when those files already exist

[Hongxu Jia]

Hi Richard,

This issue could be reproduced only by building multilib packagegroup
package in the first time.

*Step:
1) bitbake packagegroup-core-nfs-server

2) bitbake lib32-packagegroup-core-nfs-server
     Only the first time to do the build has this issue:
     ...
    WARNING: The recipe lib32-packagegroup-core-nfs is trying to install 
files into a shared area when those files already exist. Those files  
and their manifest location are:
/home/jiahongxu/yocto/build-20131120-yocto-qemux86-64/tmp/deploy/rpm/all/packagegroup-core-nfs-server-1.0-r2.all.rpm
       Matched in manifest-allarch-packagegroup-core-nfs.deploy-rpm
    ...

*Why was the first build?
1) If not the first time to build lib32-packagegroup-*, the
    lib32-packagegroup*'s manifest existed, and the current
    build could remove the existed rpm package by reading
    and cleaning the manifest.

2) During the first time, its manifest didn't exist, so there was
    no cleaning operation. But if packagegroup-*'s manifest existed,
    the existed conflict file check will search it, and report the
    warning.

//Hongxu



On 11/22/2013 08:27 PM, Richard Purdie wrote:
> On Fri, 2013-11-22 at 20:21 +0800, Hongxu Jia wrote:
>> Hi Richard,
>>
>> 1. What is the situation to set PACKAGE_ARCH = "${MACHINE_ARCH}"
>> in packagegroup recipe?
>>
>> In this case, MACHINE is qemux86-64, and the packagegroup-core-nfs's
>> RDEPENDS are:
>> "packagegroup-core-nfs-server" -> "nfs-utils" [style=dashed]
>> "packagegroup-core-nfs-server" -> "nfs-utils-client" [style=dashed]
>>
>> We check one utility in nfs-utils by invoking file:
>> $ file image/usr/sbin/exportfs
>> image/usr/sbin/exportfs: ELF 64-bit LSB executable, x86-64,
>> version 1 (SYSV), dynamically linked (uses shared libs), for
>> GNU/Linux 2.6.34, not stripped
>>
>> Should we consider the nfs-utils and lib32-nfs-utils are different
>> arch? If the answer is yes, the lib32-packagegroup-core-nfs's
>> RDEPENDS should be:
>> "lib32-packagegroup-core-nfs-server" -> "lib32-nfs-utils-client"
>> [style=dashed]
>> "lib32-packagegroup-core-nfs-server" -> "lib32-nfs-utils" [style=dashed]
>>
>> In this situation, I think we should set PACKAGE_ARCH with
>> "${MACHINE_ARCH}" in packagegroup-core-nfs recipe.
>>
>> But there are lots of packagegroup packages that didn't have set
>> PACKAGE_ARCH with "${MACHINE_ARCH}" in their recipe. After a quick
>> search in oe-core, 7 packagegroup recipes did set and almost 33 didn't,
>> so how about use PACKAGE_ARCH = "${MACHINE_ARCH}" by default for
>> packagegroup or just did not inherit allarch in packagegroup.bbclass?
>>
>> 2. What shoud we do if packagegroup packages is allarch?
>>
>> When the packagegroup packages is allarch and multilib is enabled,
>> should we still *do the multilib work* for this allarch recipe?
>> If we do, the override issue happened.
>>
>> In this case, if we don't set PACKAGE_ARCH with "${MACHINE_ARCH}",
>> packagegroup-core-nfs and lib32-packagegroup-core-nfs have different
>> ${WORKDIR}:
>>
>> WORKDIR="${BASE_WORKDIR}/${MULTIMACH_TARGET_SYS}/${PN}/${EXTENDPE}${PV}-${PR}"
>> MULTIMACH_TARGET_SYS="${PACKAGE_ARCH}${TARGET_VENDOR}-${TARGET_OS}"
>>
>> In packagegroup-core-nfs, we have:
>> TARGET_VENDOR="-poky"
>> PN="packagegroup-core-nfs"
>>
>> In lib32-packagegroup-core-nfs, after the multilib process we have:
>> TARGET_VENDOR="-pokymllib32"
>> PN="lib32-packagegroup-core-nfs"
>>
>> So we had better to forbid multilib work for the allarch recipe.
> Do you have
> http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=26559c581695f60861483691e08eee06f524287f applied to your tree?
>
> I'm hoping this issue does not exist when that patch is applied.
>
> Cheers,
>
> Richard
>