A question about PACKAGE_ARCH renaming

A question about PACKAGE_ARCH renaming

[Xu, Dongxiao]

Hi,

I am testing beagleboard with RPM, and there is a question I am confused
with that PACKAGE_ARCH is renamed for certain packages. For example the
"acl" package, whose expected PACKAGE_ARCH is "armv7a-vfp-neon", however
in RPM file, the arch is renamed to "armv7a", see
"acl-2.2.51-r2.armv7a.rpm". However IPK package still shows
"acl_2.2.51-r2_armv7a-vfp-neon.ipk".

Could anybody give hint on this? 

Thanks,
Dongxiao

Re: A question about PACKAGE_ARCH renaming

[Samuel Stirtzel]

2012/4/17 Xu, Dongxiao <dongxiao.xu@intel.com>:
> Hi,
>
> I am testing beagleboard with RPM, and there is a question I am confused
> with that PACKAGE_ARCH is renamed for certain packages. For example the
> "acl" package, whose expected PACKAGE_ARCH is "armv7a-vfp-neon", however
> in RPM file, the arch is renamed to "armv7a", see
> "acl-2.2.51-r2.armv7a.rpm". However IPK package still shows
> "acl_2.2.51-r2_armv7a-vfp-neon.ipk".
>
> Could anybody give hint on this?

Hi,
if applications need to be machine / hardware specific they can
indicate so by setting PACKAGE_ARCH.

For example I use it for recipes that build different when other
machine dependent packages are used by them:
kde-workspace can use the OpenGL ES driver which is machine dependent
so if it is used I set PACKAGE_ARCH = "${MACHINE_ARCH}".

AFAIK the vfp-neon arch indicates that the package uses hard float (or
"vector floating point") libraries instead of soft float.
See mfloat-abi at http://gcc.gnu.org/onlinedocs/gcc/ARM-Options.html

>
> Thanks,
> Dongxiao
>
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto



-- 
Regards
Samuel

Re: A question about PACKAGE_ARCH renaming

[Samuel Stirtzel]

2012/4/17 Samuel Stirtzel <s.stirtzel@googlemail.com>:
> 2012/4/17 Xu, Dongxiao <dongxiao.xu@intel.com>:
>> Hi,
>>
>> I am testing beagleboard with RPM, and there is a question I am confused
>> with that PACKAGE_ARCH is renamed for certain packages. For example the
>> "acl" package, whose expected PACKAGE_ARCH is "armv7a-vfp-neon", however
>> in RPM file, the arch is renamed to "armv7a", see
>> "acl-2.2.51-r2.armv7a.rpm". However IPK package still shows
>> "acl_2.2.51-r2_armv7a-vfp-neon.ipk".
>>
>> Could anybody give hint on this?
>
> Hi,
> if applications need to be machine / hardware specific they can
> indicate so by setting PACKAGE_ARCH.
>
> For example I use it for recipes that build different when other
> machine dependent packages are used by them:
> kde-workspace can use the OpenGL ES driver which is machine dependent
> so if it is used I set PACKAGE_ARCH = "${MACHINE_ARCH}".
>
> AFAIK the vfp-neon arch indicates that the package uses hard float (or
> "vector floating point") libraries instead of soft float.
> See mfloat-abi at http://gcc.gnu.org/onlinedocs/gcc/ARM-Options.html
>
>>
>> Thanks,
>> Dongxiao
>>
>> _______________________________________________
>> yocto mailing list
>> yocto@yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/yocto
>
>
>
> --
> Regards
> Samuel

Ah sorry i misread your post,
don't know about the renaming details.

Sending mails before the first coffee is bad :(,
sorry for the noise.

-- 
Regards
Samuel

Re: A question about PACKAGE_ARCH renaming

[Xu, Dongxiao]

Any hint on this question?

I need answers to address a Hob issue. Thanks in advance.

Thanks,
Dongxiao

On Tue, 2012-04-17 at 09:01 +0800, Xu, Dongxiao wrote:
> Hi,
> 
> I am testing beagleboard with RPM, and there is a question I am confused
> with that PACKAGE_ARCH is renamed for certain packages. For example the
> "acl" package, whose expected PACKAGE_ARCH is "armv7a-vfp-neon", however
> in RPM file, the arch is renamed to "armv7a", see
> "acl-2.2.51-r2.armv7a.rpm". However IPK package still shows
> "acl_2.2.51-r2_armv7a-vfp-neon.ipk".
> 
> Could anybody give hint on this? 
> 
> Thanks,
> Dongxiao
> 
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto

Re: A question about PACKAGE_ARCH renaming

[Mark Hatle]

On 4/16/12 8:01 PM, Xu, Dongxiao wrote:
> Hi,
>
> I am testing beagleboard with RPM, and there is a question I am confused
> with that PACKAGE_ARCH is renamed for certain packages. For example the
> "acl" package, whose expected PACKAGE_ARCH is "armv7a-vfp-neon", however
> in RPM file, the arch is renamed to "armv7a", see
> "acl-2.2.51-r2.armv7a.rpm". However IPK package still shows
> "acl_2.2.51-r2_armv7a-vfp-neon.ipk".
>
> Could anybody give hint on this?
>
> Thanks,
> Dongxiao
>

I've not seen that happen before.  Can you checked if an 
acl-...armv7a-vfp-neon.rpm was generated and RPM is simply not using it, or was 
it never generated?

As another user mentioned, it is possible for a package to say it wants a 
specific arch type, but if it did -- it should be consistent between packaging 
systems.

--Mark

Re: A question about PACKAGE_ARCH renaming

[Mark Hatle]

On 4/17/12 1:43 AM, Samuel Stirtzel wrote:
> 2012/4/17 Xu, Dongxiao<dongxiao.xu@intel.com>:
>> Hi,
>>
>> I am testing beagleboard with RPM, and there is a question I am confused
>> with that PACKAGE_ARCH is renamed for certain packages. For example the
>> "acl" package, whose expected PACKAGE_ARCH is "armv7a-vfp-neon", however
>> in RPM file, the arch is renamed to "armv7a", see
>> "acl-2.2.51-r2.armv7a.rpm". However IPK package still shows
>> "acl_2.2.51-r2_armv7a-vfp-neon.ipk".
>>
>> Could anybody give hint on this?
>
> Hi,
> if applications need to be machine / hardware specific they can
> indicate so by setting PACKAGE_ARCH.
>
> For example I use it for recipes that build different when other
> machine dependent packages are used by them:
> kde-workspace can use the OpenGL ES driver which is machine dependent
> so if it is used I set PACKAGE_ARCH = "${MACHINE_ARCH}".
>
> AFAIK the vfp-neon arch indicates that the package uses hard float (or
> "vector floating point") libraries instead of soft float.
> See mfloat-abi at http://gcc.gnu.org/onlinedocs/gcc/ARM-Options.html

Just want to clarify...

VFP indicates it's using the VFP hardware for floating point, but the ABI 
remains as the standard EABI.  (adding 'hf' means that it's using the 
EABI-hardware floating point ABI instead.  Original EABI is defined to allow 
multiple instruction sets, processor units, etc to interact with a compatible 
ABI.  While EABI-hf requires vfp support.)

--Mark

>>
>> Thanks,
>> Dongxiao
>>
>> _______________________________________________
>> yocto mailing list
>> yocto@yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/yocto
>
>
>

Re: A question about PACKAGE_ARCH renaming

[Xu, Dongxiao]

On Tue, 2012-04-17 at 10:35 -0500, Mark Hatle wrote:
> On 4/16/12 8:01 PM, Xu, Dongxiao wrote:
> > Hi,
> >
> > I am testing beagleboard with RPM, and there is a question I am confused
> > with that PACKAGE_ARCH is renamed for certain packages. For example the
> > "acl" package, whose expected PACKAGE_ARCH is "armv7a-vfp-neon", however
> > in RPM file, the arch is renamed to "armv7a", see
> > "acl-2.2.51-r2.armv7a.rpm". However IPK package still shows
> > "acl_2.2.51-r2_armv7a-vfp-neon.ipk".
> >
> > Could anybody give hint on this?
> >
> > Thanks,
> > Dongxiao
> >
> 
> I've not seen that happen before.  Can you checked if an 
> acl-...armv7a-vfp-neon.rpm was generated and RPM is simply not using it, or was 
> it never generated?

No, there is no acl-xxx.armv7a-vfp-neon.rpm, only acl-xxx.armv7a.rpm
created.

Actually I think this issue does exist since our 1.1 release, you can
have a look at the package repo:

http://downloads.yoctoproject.org/releases/yocto/yocto-1.1/rpm/armv7a-vfp-neon/

The directory is named as "armv7a-vfp-neon", however all the packages
under the directory are of "armv7a" architecture.

While see the ipk part:
http://downloads.yoctoproject.org/releases/yocto/yocto-1.1/ipk/armv7a-vfp-neon/
The directory name and rpm architecture name are the same.

Thanks,
Dongxiao

> 
> As another user mentioned, it is possible for a package to say it wants a 
> specific arch type, but if it did -- it should be consistent between packaging 
> systems.
> 
> --Mark

Re: A question about PACKAGE_ARCH renaming

[Xu, Dongxiao]

On Wed, 2012-04-18 at 08:38 +0800, Xu, Dongxiao wrote:
> On Tue, 2012-04-17 at 10:35 -0500, Mark Hatle wrote:
> > On 4/16/12 8:01 PM, Xu, Dongxiao wrote:
> > > Hi,
> > >
> > > I am testing beagleboard with RPM, and there is a question I am confused
> > > with that PACKAGE_ARCH is renamed for certain packages. For example the
> > > "acl" package, whose expected PACKAGE_ARCH is "armv7a-vfp-neon", however
> > > in RPM file, the arch is renamed to "armv7a", see
> > > "acl-2.2.51-r2.armv7a.rpm". However IPK package still shows
> > > "acl_2.2.51-r2_armv7a-vfp-neon.ipk".
> > >
> > > Could anybody give hint on this?
> > >
> > > Thanks,
> > > Dongxiao
> > >
> > 
> > I've not seen that happen before.  Can you checked if an 
> > acl-...armv7a-vfp-neon.rpm was generated and RPM is simply not using it, or was 
> > it never generated?
> 
> No, there is no acl-xxx.armv7a-vfp-neon.rpm, only acl-xxx.armv7a.rpm
> created.

Just looked at this issue with Lianhao, and we got some clues.

It seems that we don't allow '-' exists in architecture label within
RPM. Here for the beagleboard case, we use the parameter as:

rpm ... --target "armv7a-vfp-neon-poky-linux"

I think the RPM internal strips all the contents after the first '-' and
use "armv7a" as the architecture label.

Similar is the multilib case, we can see from the code that, we use
'lib64_qemux86' instead of 'lib64-qemux86' as the architecture label.

If our thoughts are right, I think we need a fix for that before 1.2
release?

Thanks,
Dongxiao

> 
> Actually I think this issue does exist since our 1.1 release, you can
> have a look at the package repo:
> 
> http://downloads.yoctoproject.org/releases/yocto/yocto-1.1/rpm/armv7a-vfp-neon/
> 
> The directory is named as "armv7a-vfp-neon", however all the packages
> under the directory are of "armv7a" architecture.
> 
> While see the ipk part:
> http://downloads.yoctoproject.org/releases/yocto/yocto-1.1/ipk/armv7a-vfp-neon/
> The directory name and rpm architecture name are the same.
> 
> Thanks,
> Dongxiao
> 
> > 
> > As another user mentioned, it is possible for a package to say it wants a 
> > specific arch type, but if it did -- it should be consistent between packaging 
> > systems.
> > 
> > --Mark
> 

Re: A question about PACKAGE_ARCH renaming

[Hatle, Mark]

There is/was a conversion that changed - to _ in the package arch.  And yes this needs to be fixed ASAP.



On Apr 18, 2012, at 12:23 AM, "Xu, Dongxiao" <dongxiao.xu@intel.com> wrote:

> On Wed, 2012-04-18 at 08:38 +0800, Xu, Dongxiao wrote:
>> On Tue, 2012-04-17 at 10:35 -0500, Mark Hatle wrote:
>>> On 4/16/12 8:01 PM, Xu, Dongxiao wrote:
>>>> Hi,
>>>> 
>>>> I am testing beagleboard with RPM, and there is a question I am confused
>>>> with that PACKAGE_ARCH is renamed for certain packages. For example the
>>>> "acl" package, whose expected PACKAGE_ARCH is "armv7a-vfp-neon", however
>>>> in RPM file, the arch is renamed to "armv7a", see
>>>> "acl-2.2.51-r2.armv7a.rpm". However IPK package still shows
>>>> "acl_2.2.51-r2_armv7a-vfp-neon.ipk".
>>>> 
>>>> Could anybody give hint on this?
>>>> 
>>>> Thanks,
>>>> Dongxiao
>>>> 
>>> 
>>> I've not seen that happen before.  Can you checked if an 
>>> acl-...armv7a-vfp-neon.rpm was generated and RPM is simply not using it, or was 
>>> it never generated?
>> 
>> No, there is no acl-xxx.armv7a-vfp-neon.rpm, only acl-xxx.armv7a.rpm
>> created.
> 
> Just looked at this issue with Lianhao, and we got some clues.
> 
> It seems that we don't allow '-' exists in architecture label within
> RPM. Here for the beagleboard case, we use the parameter as:
> 
> rpm ... --target "armv7a-vfp-neon-poky-linux"
> 
> I think the RPM internal strips all the contents after the first '-' and
> use "armv7a" as the architecture label.
> 
> Similar is the multilib case, we can see from the code that, we use
> 'lib64_qemux86' instead of 'lib64-qemux86' as the architecture label.
> 
> If our thoughts are right, I think we need a fix for that before 1.2
> release?
> 
> Thanks,
> Dongxiao
> 
>> 
>> Actually I think this issue does exist since our 1.1 release, you can
>> have a look at the package repo:
>> 
>> http://downloads.yoctoproject.org/releases/yocto/yocto-1.1/rpm/armv7a-vfp-neon/
>> 
>> The directory is named as "armv7a-vfp-neon", however all the packages
>> under the directory are of "armv7a" architecture.
>> 
>> While see the ipk part:
>> http://downloads.yoctoproject.org/releases/yocto/yocto-1.1/ipk/armv7a-vfp-neon/
>> The directory name and rpm architecture name are the same.
>> 
>> Thanks,
>> Dongxiao
>> 
>>> 
>>> As another user mentioned, it is possible for a package to say it wants a 
>>> specific arch type, but if it did -- it should be consistent between packaging 
>>> systems.
>>> 
>>> --Mark
>> 
> 
> 

Re: A question about PACKAGE_ARCH renaming

[Richard Purdie]

On Wed, 2012-04-18 at 12:45 +0000, Hatle, Mark wrote:
> There is/was a conversion that changed - to _ in the package arch.  And yes this needs to be fixed ASAP.

Let put this really simply. We are not doing this just as the -rc4 is
about to build. If we want to start considering a change like this we
might as well abort the release, start again and slip four weeks.

Why? That dash syntax works fine in opkg and is in use in real world
opkg feeds. This appears to be an rpm only issue. It also only appears
to be directly affecting hob right at this point.

When we filtered MACHINE people complained a lot. When we filtered
MACHINE_ARCH there were more complaints. If you just put the filtering
straight onto PACKAGE_ARCH as well, there will be immense trouble as it
will badly break Angstrom for a start :(.

I'd ask people think about what they're proposing and put it into
perspective.

I believe Dongxiao has a patch which would allow us to work around the
issue in hob for this release and then we can re-assess this issue in
1.3. I suspect the fix is going to be to drop the name mangling in the
core and move it to be specific to rpm.

Cheers,

Richard

Re: A question about PACKAGE_ARCH renaming

[Xu, Dongxiao]

On Wed, 2012-04-18 at 13:55 +0100, Richard Purdie wrote:
> On Wed, 2012-04-18 at 12:45 +0000, Hatle, Mark wrote:
> > There is/was a conversion that changed - to _ in the package arch.  And yes this needs to be fixed ASAP.
> 
> Let put this really simply. We are not doing this just as the -rc4 is
> about to build. If we want to start considering a change like this we
> might as well abort the release, start again and slip four weeks.
> 
> Why? That dash syntax works fine in opkg and is in use in real world
> opkg feeds. This appears to be an rpm only issue. It also only appears
> to be directly affecting hob right at this point.
> 
> When we filtered MACHINE people complained a lot. When we filtered
> MACHINE_ARCH there were more complaints. If you just put the filtering
> straight onto PACKAGE_ARCH as well, there will be immense trouble as it
> will badly break Angstrom for a start :(.
> 
> I'd ask people think about what they're proposing and put it into
> perspective.
> 
> I believe Dongxiao has a patch which would allow us to work around the
> issue in hob for this release and then we can re-assess this issue in
> 1.3. I suspect the fix is going to be to drop the name mangling in the
> core and move it to be specific to rpm.

A bug 2328 is filed for this issue.

Thanks,
Dongxiao

> 
> Cheers,
> 
> Richard
> 
> 
> 
> 

Re: A question about PACKAGE_ARCH renaming

[Hatle, Mark]

On Apr 18, 2012, at 7:56 AM, "Richard Purdie" <richard.purdie@linuxfoundation.org> wrote:

> On Wed, 2012-04-18 at 12:45 +0000, Hatle, Mark wrote:
>> There is/was a conversion that changed - to _ in the package arch.  And yes this needs to be fixed ASAP.
> 
> Let put this really simply. We are not doing this just as the -rc4 is
> about to build. If we want to start considering a change like this we
> might as well abort the release, start again and slip four weeks.
> 
> Why? That dash syntax works fine in opkg and is in use in real world
> opkg feeds. This appears to be an rpm only issue. It also only appears
> to be directly affecting hob right at this point

I agree completely, the conversion is package manager specific.  I swear the RPM integration did this conversion in prior versions, the zypper setup has code to do the same as well.

The code belongs in the package_rpm.bbclass...

> When we filtered MACHINE people complained a lot. When we filtered
> MACHINE_ARCH there were more complaints. If you just put the filtering
> straight onto PACKAGE_ARCH as well, there will be immense trouble as it
> will badly break Angstrom for a start :(.
> 
> I'd ask people think about what they're proposing and put it into
> perspective.
> 
> I believe Dongxiao has a patch which would allow us to work around the
> issue in hob for this release and then we can re-assess this issue in
> 1.3. I suspect the fix is going to be to drop the name mangling in the
> core and move it to be specific to rpm.
> 
> Cheers,
> 
> Richard
> 
> 
> 
>