All of lore.kernel.org
 help / color / mirror / Atom feed
* Problems adding native support packages
@ 2011-03-11  3:28 Gary Thomas
  2011-03-11  4:57 ` Tian, Kevin
  0 siblings, 1 reply; 14+ messages in thread
From: Gary Thomas @ 2011-03-11  3:28 UTC (permalink / raw)
  To: Poky

I'm trying to import a native package from OE for which the
main package depends on libiconv.  This seems to imply that
when I extend to the native package using BBCLASSEXTEND, the
native package depends on virtual/libiconv-native

I can't figure out how to provide this.  Any clues?

n.b. the recipe from OE is librsvg and importing it seems to be
pretty invasive.  To build the native package, I needed to add
native support for all of these packages:

#       modified:   meta/recipes-gnome/gnome/libart-lgpl_2.3.21.bb
#       modified:   meta/recipes-gnome/gtk+/gtk+.inc
#       modified:   meta/recipes-graphics/cairo/cairo.inc
#       modified:   meta/recipes-graphics/pango/pango.inc
#       modified:   meta/recipes-graphics/xorg-lib/libxcomposite_0.4.3.bb
#       modified:   meta/recipes-graphics/xorg-lib/libxcursor_1.1.11.bb
#       modified:   meta/recipes-graphics/xorg-lib/libxdamage_1.1.3.bb
#       modified:   meta/recipes-graphics/xorg-lib/libxfixes_4.0.5.bb
#       modified:   meta/recipes-graphics/xorg-lib/libxft_2.2.0.bb
#       modified:   meta/recipes-graphics/xorg-lib/libxrandr_1.3.1.bb
#       modified:   meta/recipes-graphics/xorg-lib/libxrender_0.9.6.bb
#       modified:   meta/recipes-graphics/xorg-lib/pixman_0.20.2.bb
#       modified:   meta/recipes-graphics/xorg-proto/compositeproto_0.4.2.bb
#       modified:   meta/recipes-graphics/xorg-proto/damageproto_1.2.1.bb
#       modified:   meta/recipes-graphics/xorg-proto/fixesproto_4.1.2.bb
#       modified:   meta/recipes-graphics/xorg-proto/randrproto_1.3.2.bb
#       modified:   meta/recipes-graphics/xorg-proto/renderproto_0.11.1.bb
#       modified:   meta/recipes-graphics/xorg-proto/xineramaproto_1.2.1.bb
#       modified:   meta/recipes-multimedia/alsa/alsa-tools_1.0.20.bb
#       modified:   meta/recipes-support/atk/atk.inc
#       modified:   meta/recipes-support/libcroco/libcroco_0.6.2.bb
#       modified:   meta/recipes-support/libgcrypt/libgcrypt.inc
#       modified:   meta/recipes-support/libgpg-error/libgpg-error_1.9.bb

I also ran into a problem when I added native to atk, I get this error
which makes no sense at all to me:
   NOTE: package atk-native-1.32.0-r0: task do_fetch: Started
   ERROR: Function 'Fetcher failure for URL: 'http://download.gnome.org/sources/atk/1.32/atk-native-1.32.0.tar.bz2'. Unable to fetch URL 
http://download.gnome.org/sources/atk/1.32/atk-native-1.32.0.tar.bz2 from any source.' failed
This seems to be the only package in the set above that wants to fetch a -native
tarball (there are no such files in the sources repository as far as I can tell)

Thanks


-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------


^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Problems adding native support packages
  2011-03-11  3:28 Problems adding native support packages Gary Thomas
@ 2011-03-11  4:57 ` Tian, Kevin
  2011-03-11  5:09   ` Xu, Dongxiao
  2011-03-11 11:19   ` Gary Thomas
  0 siblings, 2 replies; 14+ messages in thread
From: Tian, Kevin @ 2011-03-11  4:57 UTC (permalink / raw)
  To: Gary Thomas, Poky

> From: Gary Thomas
> Sent: Friday, March 11, 2011 11:29 AM
> 
> I'm trying to import a native package from OE for which the
> main package depends on libiconv.  This seems to imply that
> when I extend to the native package using BBCLASSEXTEND, the
> native package depends on virtual/libiconv-native
> 
> I can't figure out how to provide this.  Any clues?

I'm not sure about the problem here. do you want virtual/libiconv-native dependency
or not? If target recipe already has a DEPENDS = "libiconv", then with BBCLASSEXTEND
you have libiconv-native automatically.

Or if you only want to add libiconv-native for native recipe exclusively, then:

DEPENDS_virtclass-native = "virtual/libiconv-native"

Thanks
Kevin

> 
> n.b. the recipe from OE is librsvg and importing it seems to be
> pretty invasive.  To build the native package, I needed to add
> native support for all of these packages:
> 
> #       modified:   meta/recipes-gnome/gnome/libart-lgpl_2.3.21.bb
> #       modified:   meta/recipes-gnome/gtk+/gtk+.inc
> #       modified:   meta/recipes-graphics/cairo/cairo.inc
> #       modified:   meta/recipes-graphics/pango/pango.inc
> #       modified:   meta/recipes-graphics/xorg-lib/libxcomposite_0.4.3.bb
> #       modified:   meta/recipes-graphics/xorg-lib/libxcursor_1.1.11.bb
> #       modified:   meta/recipes-graphics/xorg-lib/libxdamage_1.1.3.bb
> #       modified:   meta/recipes-graphics/xorg-lib/libxfixes_4.0.5.bb
> #       modified:   meta/recipes-graphics/xorg-lib/libxft_2.2.0.bb
> #       modified:   meta/recipes-graphics/xorg-lib/libxrandr_1.3.1.bb
> #       modified:   meta/recipes-graphics/xorg-lib/libxrender_0.9.6.bb
> #       modified:   meta/recipes-graphics/xorg-lib/pixman_0.20.2.bb
> #       modified:
> meta/recipes-graphics/xorg-proto/compositeproto_0.4.2.bb
> #       modified:
> meta/recipes-graphics/xorg-proto/damageproto_1.2.1.bb
> #       modified:   meta/recipes-graphics/xorg-proto/fixesproto_4.1.2.bb
> #       modified:   meta/recipes-graphics/xorg-proto/randrproto_1.3.2.bb
> #       modified:
> meta/recipes-graphics/xorg-proto/renderproto_0.11.1.bb
> #       modified:
> meta/recipes-graphics/xorg-proto/xineramaproto_1.2.1.bb
> #       modified:   meta/recipes-multimedia/alsa/alsa-tools_1.0.20.bb
> #       modified:   meta/recipes-support/atk/atk.inc
> #       modified:   meta/recipes-support/libcroco/libcroco_0.6.2.bb
> #       modified:   meta/recipes-support/libgcrypt/libgcrypt.inc
> #       modified:   meta/recipes-support/libgpg-error/libgpg-error_1.9.bb
> 
> I also ran into a problem when I added native to atk, I get this error
> which makes no sense at all to me:
>    NOTE: package atk-native-1.32.0-r0: task do_fetch: Started
>    ERROR: Function 'Fetcher failure for URL:
> 'http://download.gnome.org/sources/atk/1.32/atk-native-1.32.0.tar.bz2'.
> Unable to fetch URL
> http://download.gnome.org/sources/atk/1.32/atk-native-1.32.0.tar.bz2 from
> any source.' failed
> This seems to be the only package in the set above that wants to fetch a
> -native
> tarball (there are no such files in the sources repository as far as I can tell)
> 
> Thanks
> 
> 
> --
> ------------------------------------------------------------
> Gary Thomas                 |  Consulting for the
> MLB Associates              |    Embedded world
> ------------------------------------------------------------
> _______________________________________________
> poky mailing list
> poky@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/poky


^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Problems adding native support packages
  2011-03-11  4:57 ` Tian, Kevin
@ 2011-03-11  5:09   ` Xu, Dongxiao
  2011-03-11  5:15     ` Tian, Kevin
  2011-03-11  8:21     ` Khem Raj
  2011-03-11 11:19   ` Gary Thomas
  1 sibling, 2 replies; 14+ messages in thread
From: Xu, Dongxiao @ 2011-03-11  5:09 UTC (permalink / raw)
  To: Tian, Kevin, Gary Thomas, Poky

Tian, Kevin wrote:
>> From: Gary Thomas
>> Sent: Friday, March 11, 2011 11:29 AM
>> 
>> I'm trying to import a native package from OE for which the main
>> package depends on libiconv.  This seems to imply that when I extend
>> to the native package using BBCLASSEXTEND, the native package depends
>> on virtual/libiconv-native
>> 
>> I can't figure out how to provide this.  Any clues?
> 
> I'm not sure about the problem here. do you want
> virtual/libiconv-native dependency or not? If target recipe already
> has a DEPENDS = "libiconv", then with BBCLASSEXTEND you have
> libiconv-native automatically.   
> 
> Or if you only want to add libiconv-native for native recipe
> exclusively, then: 
> 
> DEPENDS_virtclass-native = "virtual/libiconv-native"
> 
> Thanks
> Kevin
> 
>> 
>> n.b. the recipe from OE is librsvg and importing it seems to be
>> pretty invasive.  To build the native package, I needed to add
>> native support for all of these packages: 
>> 
>> #       modified:   meta/recipes-gnome/gnome/libart-lgpl_2.3.21.bb
>> #       modified:   meta/recipes-gnome/gtk+/gtk+.inc
>> #       modified:   meta/recipes-graphics/cairo/cairo.inc
>> #       modified:   meta/recipes-graphics/pango/pango.inc
>> #       modified:  
>> meta/recipes-graphics/xorg-lib/libxcomposite_0.4.3.bb #      
>> modified:   meta/recipes-graphics/xorg-lib/libxcursor_1.1.11.bb #   
>> modified:   meta/recipes-graphics/xorg-lib/libxdamage_1.1.3.bb #    
>> modified:   meta/recipes-graphics/xorg-lib/libxfixes_4.0.5.bb #     
>> modified:   meta/recipes-graphics/xorg-lib/libxft_2.2.0.bb #      
>> modified:   meta/recipes-graphics/xorg-lib/libxrandr_1.3.1.bb #     
>> modified:   meta/recipes-graphics/xorg-lib/libxrender_0.9.6.bb #    
>> modified:   meta/recipes-graphics/xorg-lib/pixman_0.20.2.bb #      
>> modified: meta/recipes-graphics/xorg-proto/compositeproto_0.4.2.bb #
>> modified: meta/recipes-graphics/xorg-proto/damageproto_1.2.1.bb #   
>> modified:   meta/recipes-graphics/xorg-proto/fixesproto_4.1.2.bb #  
>> modified:   meta/recipes-graphics/xorg-proto/randrproto_1.3.2.bb #  
>> modified: meta/recipes-graphics/xorg-proto/renderproto_0.11.1.bb #  
>> modified: meta/recipes-graphics/xorg-proto/xineramaproto_1.2.1.bb # 
>> modified:   meta/recipes-multimedia/alsa/alsa-tools_1.0.20.bb #     
>> modified:   meta/recipes-support/atk/atk.inc #       modified:  
>> meta/recipes-support/libcroco/libcroco_0.6.2.bb #       modified:  
>> meta/recipes-support/libgcrypt/libgcrypt.inc #       modified:  
>> meta/recipes-support/libgpg-error/libgpg-error_1.9.bb 
>> 
>> I also ran into a problem when I added native to atk, I get this
>> error which makes no sense at all to me:
>>    NOTE: package atk-native-1.32.0-r0: task do_fetch: Started
>>    ERROR: Function 'Fetcher failure for URL:
>> 'http://download.gnome.org/sources/atk/1.32/atk-native-1.32.0.tar.bz2'.
>> Unable to fetch URL
>> http://download.gnome.org/sources/atk/1.32/atk-native-1.32.0.tar.bz2
>> from any source.' failed This seems to be the only package in the
>> set above that wants to fetch a -native tarball (there are no such
>> files  
>> in the sources repository as far as I can tell)

atk's SRC_URI is assigned like:

SRC_URI = "http://download.gnome.org/sources/atk/1.32/${PN}-${PV}.tar.bz2"

After introducing native to atk, PN is changed to atk-native, thus no resouce is found in the repo.

I will make a fix to that. But for your quick workaournd, you can change the atk's SRC_URI to:

SRC_URI = "http://download.gnome.org/sources/atk/1.32/atk-${PV}.tar.bz2"

Thanks,
Dongxiao

>> 
>> Thanks
>> 
>> 
>> --
>> ------------------------------------------------------------
>> Gary Thomas                 |  Consulting for the
>> MLB Associates              |    Embedded world
>> ------------------------------------------------------------
>> _______________________________________________
>> poky mailing list
>> poky@yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/poky
> _______________________________________________
> poky mailing list
> poky@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/poky



^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Problems adding native support packages
  2011-03-11  5:09   ` Xu, Dongxiao
@ 2011-03-11  5:15     ` Tian, Kevin
  2011-03-11  5:18       ` Xu, Dongxiao
  2011-03-11  8:21     ` Khem Raj
  1 sibling, 1 reply; 14+ messages in thread
From: Tian, Kevin @ 2011-03-11  5:15 UTC (permalink / raw)
  To: Xu, Dongxiao, Gary Thomas, Poky

> From: Xu, Dongxiao
> Sent: Friday, March 11, 2011 1:09 PM
> 
> Tian, Kevin wrote:
> >> From: Gary Thomas
> >> Sent: Friday, March 11, 2011 11:29 AM
> >>
> >> I'm trying to import a native package from OE for which the main
> >> package depends on libiconv.  This seems to imply that when I extend
> >> to the native package using BBCLASSEXTEND, the native package depends
> >> on virtual/libiconv-native
> >>
> >> I can't figure out how to provide this.  Any clues?
> >
> > I'm not sure about the problem here. do you want
> > virtual/libiconv-native dependency or not? If target recipe already
> > has a DEPENDS = "libiconv", then with BBCLASSEXTEND you have
> > libiconv-native automatically.
> >
> > Or if you only want to add libiconv-native for native recipe
> > exclusively, then:
> >
> > DEPENDS_virtclass-native = "virtual/libiconv-native"
> >
> > Thanks
> > Kevin
> >
> >>
> >> n.b. the recipe from OE is librsvg and importing it seems to be
> >> pretty invasive.  To build the native package, I needed to add
> >> native support for all of these packages:
> >>
> >> #       modified:   meta/recipes-gnome/gnome/libart-lgpl_2.3.21.bb
> >> #       modified:   meta/recipes-gnome/gtk+/gtk+.inc
> >> #       modified:   meta/recipes-graphics/cairo/cairo.inc
> >> #       modified:   meta/recipes-graphics/pango/pango.inc
> >> #       modified:
> >> meta/recipes-graphics/xorg-lib/libxcomposite_0.4.3.bb #
> >> modified:   meta/recipes-graphics/xorg-lib/libxcursor_1.1.11.bb #
> >> modified:   meta/recipes-graphics/xorg-lib/libxdamage_1.1.3.bb #
> >> modified:   meta/recipes-graphics/xorg-lib/libxfixes_4.0.5.bb #
> >> modified:   meta/recipes-graphics/xorg-lib/libxft_2.2.0.bb #
> >> modified:   meta/recipes-graphics/xorg-lib/libxrandr_1.3.1.bb #
> >> modified:   meta/recipes-graphics/xorg-lib/libxrender_0.9.6.bb #
> >> modified:   meta/recipes-graphics/xorg-lib/pixman_0.20.2.bb #
> >> modified: meta/recipes-graphics/xorg-proto/compositeproto_0.4.2.bb #
> >> modified: meta/recipes-graphics/xorg-proto/damageproto_1.2.1.bb #
> >> modified:   meta/recipes-graphics/xorg-proto/fixesproto_4.1.2.bb #
> >> modified:   meta/recipes-graphics/xorg-proto/randrproto_1.3.2.bb #
> >> modified: meta/recipes-graphics/xorg-proto/renderproto_0.11.1.bb #
> >> modified: meta/recipes-graphics/xorg-proto/xineramaproto_1.2.1.bb #
> >> modified:   meta/recipes-multimedia/alsa/alsa-tools_1.0.20.bb #
> >> modified:   meta/recipes-support/atk/atk.inc #       modified:
> >> meta/recipes-support/libcroco/libcroco_0.6.2.bb #       modified:
> >> meta/recipes-support/libgcrypt/libgcrypt.inc #       modified:
> >> meta/recipes-support/libgpg-error/libgpg-error_1.9.bb
> >>
> >> I also ran into a problem when I added native to atk, I get this
> >> error which makes no sense at all to me:
> >>    NOTE: package atk-native-1.32.0-r0: task do_fetch: Started
> >>    ERROR: Function 'Fetcher failure for URL:
> >> 'http://download.gnome.org/sources/atk/1.32/atk-native-1.32.0.tar.bz2'.
> >> Unable to fetch URL
> >> http://download.gnome.org/sources/atk/1.32/atk-native-1.32.0.tar.bz2
> >> from any source.' failed This seems to be the only package in the
> >> set above that wants to fetch a -native tarball (there are no such
> >> files
> >> in the sources repository as far as I can tell)
> 
> atk's SRC_URI is assigned like:
> 
> SRC_URI =
> "http://download.gnome.org/sources/atk/1.32/${PN}-${PV}.tar.bz2"
> 
> After introducing native to atk, PN is changed to atk-native, thus no resouce is
> found in the repo.
> 
> I will make a fix to that. But for your quick workaournd, you can change the
> atk's SRC_URI to:
> 
> SRC_URI = "http://download.gnome.org/sources/atk/1.32/atk-${PV}.tar.bz2"
> 

use ${BPN}-${PV} instead.

Thanks
Kevin


^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Problems adding native support packages
  2011-03-11  5:15     ` Tian, Kevin
@ 2011-03-11  5:18       ` Xu, Dongxiao
  2011-03-11  5:52         ` Tian, Kevin
  2011-03-11 11:29         ` Gary Thomas
  0 siblings, 2 replies; 14+ messages in thread
From: Xu, Dongxiao @ 2011-03-11  5:18 UTC (permalink / raw)
  To: Tian, Kevin, Gary Thomas, Poky, Richard Purdie

Tian, Kevin wrote:
>> From: Xu, Dongxiao
>> Sent: Friday, March 11, 2011 1:09 PM
>> 
>> Tian, Kevin wrote:
>>>> From: Gary Thomas
>>>> Sent: Friday, March 11, 2011 11:29 AM
>>>> 
>>>> I'm trying to import a native package from OE for which the main
>>>> package depends on libiconv.  This seems to imply that when I
>>>> extend to the native package using BBCLASSEXTEND, the native
>>>> package depends on virtual/libiconv-native
>>>> 
>>>> I can't figure out how to provide this.  Any clues?
>>> 
>>> I'm not sure about the problem here. do you want
>>> virtual/libiconv-native dependency or not? If target recipe already
>>> has a DEPENDS = "libiconv", then with BBCLASSEXTEND you have
>>> libiconv-native automatically.
>>> 
>>> Or if you only want to add libiconv-native for native recipe
>>> exclusively, then: 
>>> 
>>> DEPENDS_virtclass-native = "virtual/libiconv-native"
>>> 
>>> Thanks
>>> Kevin
>>> 
>>>> 
>>>> n.b. the recipe from OE is librsvg and importing it seems to be
>>>> pretty invasive.  To build the native package, I needed to add
>>>> native support for all of these packages:
>>>> 
>>>> #       modified:   meta/recipes-gnome/gnome/libart-lgpl_2.3.21.bb
>>>> #       modified:   meta/recipes-gnome/gtk+/gtk+.inc
>>>> #       modified:   meta/recipes-graphics/cairo/cairo.inc
>>>> #       modified:   meta/recipes-graphics/pango/pango.inc #      
>>>> modified: meta/recipes-graphics/xorg-lib/libxcomposite_0.4.3.bb #
>>>> modified:   meta/recipes-graphics/xorg-lib/libxcursor_1.1.11.bb #
>>>> modified:   meta/recipes-graphics/xorg-lib/libxdamage_1.1.3.bb #
>>>> modified:   meta/recipes-graphics/xorg-lib/libxfixes_4.0.5.bb #
>>>> modified:   meta/recipes-graphics/xorg-lib/libxft_2.2.0.bb #
>>>> modified:   meta/recipes-graphics/xorg-lib/libxrandr_1.3.1.bb #
>>>> modified:   meta/recipes-graphics/xorg-lib/libxrender_0.9.6.bb #
>>>> modified:   meta/recipes-graphics/xorg-lib/pixman_0.20.2.bb #
>>>> modified: meta/recipes-graphics/xorg-proto/compositeproto_0.4.2.bb
>>>> # modified: meta/recipes-graphics/xorg-proto/damageproto_1.2.1.bb #
>>>> modified:   meta/recipes-graphics/xorg-proto/fixesproto_4.1.2.bb #
>>>> modified:   meta/recipes-graphics/xorg-proto/randrproto_1.3.2.bb #
>>>> modified: meta/recipes-graphics/xorg-proto/renderproto_0.11.1.bb #
>>>> modified: meta/recipes-graphics/xorg-proto/xineramaproto_1.2.1.bb #
>>>> modified:   meta/recipes-multimedia/alsa/alsa-tools_1.0.20.bb #
>>>> modified:   meta/recipes-support/atk/atk.inc #       modified:
>>>> meta/recipes-support/libcroco/libcroco_0.6.2.bb #       modified:
>>>> meta/recipes-support/libgcrypt/libgcrypt.inc #       modified:
>>>> meta/recipes-support/libgpg-error/libgpg-error_1.9.bb
>>>> 
>>>> I also ran into a problem when I added native to atk, I get this
>>>> error which makes no sense at all to me:
>>>>    NOTE: package atk-native-1.32.0-r0: task do_fetch: Started
>>>>    ERROR: Function 'Fetcher failure for URL:
>>>> 'http://download.gnome.org/sources/atk/1.32/atk-native-1.32.0.tar.bz2'.
>>>> Unable to fetch URL
>>>> http://download.gnome.org/sources/atk/1.32/atk-native-1.32.0.tar.bz
>>>> 2 from any source.' failed This seems to be the only package in
>>>> the set above that wants to fetch a -native tarball (there are no
>>>> such files in the sources repository as far as I can tell) 
>> 
>> atk's SRC_URI is assigned like:
>> 
>> SRC_URI =
>> "http://download.gnome.org/sources/atk/1.32/${PN}-${PV}.tar.bz2"
>> 
>> After introducing native to atk, PN is changed to atk-native, thus
>> no resouce is found in the repo. 
>> 
>> I will make a fix to that. But for your quick workaournd, you can
>> change the atk's SRC_URI to: 
>> 
>> SRC_URI =
>> "http://download.gnome.org/sources/atk/1.32/atk-${PV}.tar.bz2" 
>> 
> 
> use ${BPN}-${PV} instead.

Yes. This is the right approach.

I checked in current poky meta recipes, there are about 67 recipes which directly uses ${PN} in the SRC_URI line.

Do we need to change all of them to ${BPN}?

Thanks,
Dongxiao

> 
> Thanks
> Kevin



^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Problems adding native support packages
  2011-03-11  5:18       ` Xu, Dongxiao
@ 2011-03-11  5:52         ` Tian, Kevin
  2011-03-11 22:25           ` Richard Purdie
  2011-03-11 11:29         ` Gary Thomas
  1 sibling, 1 reply; 14+ messages in thread
From: Tian, Kevin @ 2011-03-11  5:52 UTC (permalink / raw)
  To: Xu, Dongxiao, Gary Thomas, Poky, Richard Purdie

> From: Xu, Dongxiao
> Sent: Friday, March 11, 2011 1:19 PM
> 
> Tian, Kevin wrote:
> >> From: Xu, Dongxiao
> >> Sent: Friday, March 11, 2011 1:09 PM
> >>
> >> Tian, Kevin wrote:
> >>>> From: Gary Thomas
> >>>> Sent: Friday, March 11, 2011 11:29 AM
> >>>>
> >>>> I'm trying to import a native package from OE for which the main
> >>>> package depends on libiconv.  This seems to imply that when I
> >>>> extend to the native package using BBCLASSEXTEND, the native
> >>>> package depends on virtual/libiconv-native
> >>>>
> >>>> I can't figure out how to provide this.  Any clues?
> >>>
> >>> I'm not sure about the problem here. do you want
> >>> virtual/libiconv-native dependency or not? If target recipe already
> >>> has a DEPENDS = "libiconv", then with BBCLASSEXTEND you have
> >>> libiconv-native automatically.
> >>>
> >>> Or if you only want to add libiconv-native for native recipe
> >>> exclusively, then:
> >>>
> >>> DEPENDS_virtclass-native = "virtual/libiconv-native"
> >>>
> >>> Thanks
> >>> Kevin
> >>>
> >>>>
> >>>> n.b. the recipe from OE is librsvg and importing it seems to be
> >>>> pretty invasive.  To build the native package, I needed to add
> >>>> native support for all of these packages:
> >>>>
> >>>> #       modified:   meta/recipes-gnome/gnome/libart-lgpl_2.3.21.bb
> >>>> #       modified:   meta/recipes-gnome/gtk+/gtk+.inc
> >>>> #       modified:   meta/recipes-graphics/cairo/cairo.inc
> >>>> #       modified:   meta/recipes-graphics/pango/pango.inc #
> >>>> modified: meta/recipes-graphics/xorg-lib/libxcomposite_0.4.3.bb #
> >>>> modified:   meta/recipes-graphics/xorg-lib/libxcursor_1.1.11.bb #
> >>>> modified:   meta/recipes-graphics/xorg-lib/libxdamage_1.1.3.bb #
> >>>> modified:   meta/recipes-graphics/xorg-lib/libxfixes_4.0.5.bb #
> >>>> modified:   meta/recipes-graphics/xorg-lib/libxft_2.2.0.bb #
> >>>> modified:   meta/recipes-graphics/xorg-lib/libxrandr_1.3.1.bb #
> >>>> modified:   meta/recipes-graphics/xorg-lib/libxrender_0.9.6.bb #
> >>>> modified:   meta/recipes-graphics/xorg-lib/pixman_0.20.2.bb #
> >>>> modified: meta/recipes-graphics/xorg-proto/compositeproto_0.4.2.bb
> >>>> # modified: meta/recipes-graphics/xorg-proto/damageproto_1.2.1.bb #
> >>>> modified:   meta/recipes-graphics/xorg-proto/fixesproto_4.1.2.bb #
> >>>> modified:   meta/recipes-graphics/xorg-proto/randrproto_1.3.2.bb #
> >>>> modified: meta/recipes-graphics/xorg-proto/renderproto_0.11.1.bb #
> >>>> modified: meta/recipes-graphics/xorg-proto/xineramaproto_1.2.1.bb #
> >>>> modified:   meta/recipes-multimedia/alsa/alsa-tools_1.0.20.bb #
> >>>> modified:   meta/recipes-support/atk/atk.inc #       modified:
> >>>> meta/recipes-support/libcroco/libcroco_0.6.2.bb #       modified:
> >>>> meta/recipes-support/libgcrypt/libgcrypt.inc #       modified:
> >>>> meta/recipes-support/libgpg-error/libgpg-error_1.9.bb
> >>>>
> >>>> I also ran into a problem when I added native to atk, I get this
> >>>> error which makes no sense at all to me:
> >>>>    NOTE: package atk-native-1.32.0-r0: task do_fetch: Started
> >>>>    ERROR: Function 'Fetcher failure for URL:
> >>>> 'http://download.gnome.org/sources/atk/1.32/atk-native-1.32.0.tar.bz2'.
> >>>> Unable to fetch URL
> >>>> http://download.gnome.org/sources/atk/1.32/atk-native-1.32.0.tar.bz
> >>>> 2 from any source.' failed This seems to be the only package in
> >>>> the set above that wants to fetch a -native tarball (there are no
> >>>> such files in the sources repository as far as I can tell)
> >>
> >> atk's SRC_URI is assigned like:
> >>
> >> SRC_URI =
> >> "http://download.gnome.org/sources/atk/1.32/${PN}-${PV}.tar.bz2"
> >>
> >> After introducing native to atk, PN is changed to atk-native, thus
> >> no resouce is found in the repo.
> >>
> >> I will make a fix to that. But for your quick workaournd, you can
> >> change the atk's SRC_URI to:
> >>
> >> SRC_URI =
> >> "http://download.gnome.org/sources/atk/1.32/atk-${PV}.tar.bz2"
> >>
> >
> > use ${BPN}-${PV} instead.
> 
> Yes. This is the right approach.
> 
> I checked in current poky meta recipes, there are about 67 recipes which
> directly uses ${PN} in the SRC_URI line.
> 
> Do we need to change all of them to ${BPN}?
> 

I think it's a cleaner way to use BPN, or even simple BP. This would avoid an error
alarm when extending some recipes to native. :-)

Thanks,
Kevin


^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Problems adding native support packages
  2011-03-11  5:09   ` Xu, Dongxiao
  2011-03-11  5:15     ` Tian, Kevin
@ 2011-03-11  8:21     ` Khem Raj
  1 sibling, 0 replies; 14+ messages in thread
From: Khem Raj @ 2011-03-11  8:21 UTC (permalink / raw)
  To: Xu, Dongxiao; +Cc: Poky

On (11/03/11 13:09), Xu, Dongxiao wrote:
> Tian, Kevin wrote:
> >> From: Gary Thomas
> >> Sent: Friday, March 11, 2011 11:29 AM
> >> 
> >> I'm trying to import a native package from OE for which the main
> >> package depends on libiconv.  This seems to imply that when I extend
> >> to the native package using BBCLASSEXTEND, the native package depends
> >> on virtual/libiconv-native
> >> 
> >> I can't figure out how to provide this.  Any clues?
> > 
> > I'm not sure about the problem here. do you want
> > virtual/libiconv-native dependency or not? If target recipe already
> > has a DEPENDS = "libiconv", then with BBCLASSEXTEND you have
> > libiconv-native automatically.   
> > 
> > Or if you only want to add libiconv-native for native recipe
> > exclusively, then: 
> > 
> > DEPENDS_virtclass-native = "virtual/libiconv-native"
> > 
> > Thanks
> > Kevin
> > 
> >> 
> >> n.b. the recipe from OE is librsvg and importing it seems to be
> >> pretty invasive.  To build the native package, I needed to add
> >> native support for all of these packages: 
> >> 
> >> #       modified:   meta/recipes-gnome/gnome/libart-lgpl_2.3.21.bb
> >> #       modified:   meta/recipes-gnome/gtk+/gtk+.inc
> >> #       modified:   meta/recipes-graphics/cairo/cairo.inc
> >> #       modified:   meta/recipes-graphics/pango/pango.inc
> >> #       modified:  
> >> meta/recipes-graphics/xorg-lib/libxcomposite_0.4.3.bb #      
> >> modified:   meta/recipes-graphics/xorg-lib/libxcursor_1.1.11.bb #   
> >> modified:   meta/recipes-graphics/xorg-lib/libxdamage_1.1.3.bb #    
> >> modified:   meta/recipes-graphics/xorg-lib/libxfixes_4.0.5.bb #     
> >> modified:   meta/recipes-graphics/xorg-lib/libxft_2.2.0.bb #      
> >> modified:   meta/recipes-graphics/xorg-lib/libxrandr_1.3.1.bb #     
> >> modified:   meta/recipes-graphics/xorg-lib/libxrender_0.9.6.bb #    
> >> modified:   meta/recipes-graphics/xorg-lib/pixman_0.20.2.bb #      
> >> modified: meta/recipes-graphics/xorg-proto/compositeproto_0.4.2.bb #
> >> modified: meta/recipes-graphics/xorg-proto/damageproto_1.2.1.bb #   
> >> modified:   meta/recipes-graphics/xorg-proto/fixesproto_4.1.2.bb #  
> >> modified:   meta/recipes-graphics/xorg-proto/randrproto_1.3.2.bb #  
> >> modified: meta/recipes-graphics/xorg-proto/renderproto_0.11.1.bb #  
> >> modified: meta/recipes-graphics/xorg-proto/xineramaproto_1.2.1.bb # 
> >> modified:   meta/recipes-multimedia/alsa/alsa-tools_1.0.20.bb #     
> >> modified:   meta/recipes-support/atk/atk.inc #       modified:  
> >> meta/recipes-support/libcroco/libcroco_0.6.2.bb #       modified:  
> >> meta/recipes-support/libgcrypt/libgcrypt.inc #       modified:  
> >> meta/recipes-support/libgpg-error/libgpg-error_1.9.bb 
> >> 
> >> I also ran into a problem when I added native to atk, I get this
> >> error which makes no sense at all to me:
> >>    NOTE: package atk-native-1.32.0-r0: task do_fetch: Started
> >>    ERROR: Function 'Fetcher failure for URL:
> >> 'http://download.gnome.org/sources/atk/1.32/atk-native-1.32.0.tar.bz2'.
> >> Unable to fetch URL
> >> http://download.gnome.org/sources/atk/1.32/atk-native-1.32.0.tar.bz2
> >> from any source.' failed This seems to be the only package in the
> >> set above that wants to fetch a -native tarball (there are no such
> >> files  
> >> in the sources repository as far as I can tell)
> 
> atk's SRC_URI is assigned like:
> 
> SRC_URI = "http://download.gnome.org/sources/atk/1.32/${PN}-${PV}.tar.bz2"
> 
> After introducing native to atk, PN is changed to atk-native, thus no resouce is found in the repo.
> 
> I will make a fix to that. But for your quick workaournd, you can change the atk's SRC_URI to:
> 
> SRC_URI = "http://download.gnome.org/sources/atk/1.32/atk-${PV}.tar.bz2"

Use BPN instead


^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Problems adding native support packages
  2011-03-11  4:57 ` Tian, Kevin
  2011-03-11  5:09   ` Xu, Dongxiao
@ 2011-03-11 11:19   ` Gary Thomas
  2011-03-11 12:13     ` Gary Thomas
  1 sibling, 1 reply; 14+ messages in thread
From: Gary Thomas @ 2011-03-11 11:19 UTC (permalink / raw)
  To: Tian, Kevin; +Cc: Poky

On 03/10/2011 09:57 PM, Tian, Kevin wrote:
>> From: Gary Thomas
>> Sent: Friday, March 11, 2011 11:29 AM
>>
>> I'm trying to import a native package from OE for which the
>> main package depends on libiconv.  This seems to imply that
>> when I extend to the native package using BBCLASSEXTEND, the
>> native package depends on virtual/libiconv-native
>>
>> I can't figure out how to provide this.  Any clues?
>
> I'm not sure about the problem here. do you want virtual/libiconv-native dependency
> or not? If target recipe already has a DEPENDS = "libiconv", then with BBCLASSEXTEND
> you have libiconv-native automatically.
>
> Or if you only want to add libiconv-native for native recipe exclusively, then:
>
> DEPENDS_virtclass-native = "virtual/libiconv-native"

Actually, the problem is that such a dependency was added automatically by BBCLASSEXTEND.
virtual/libiconv is provided by eglibc package, but it's not clear if it can provide
virtual/libiconv-native

The other problem is that there is a meta/recipes-support/libiconv/libiconv_1.9.2.bb recipe
in the tree which does not build at all, native or target.

>>
>> n.b. the recipe from OE is librsvg and importing it seems to be
>> pretty invasive.  To build the native package, I needed to add
>> native support for all of these packages:
>>
>> #       modified:   meta/recipes-gnome/gnome/libart-lgpl_2.3.21.bb
>> #       modified:   meta/recipes-gnome/gtk+/gtk+.inc
>> #       modified:   meta/recipes-graphics/cairo/cairo.inc
>> #       modified:   meta/recipes-graphics/pango/pango.inc
>> #       modified:   meta/recipes-graphics/xorg-lib/libxcomposite_0.4.3.bb
>> #       modified:   meta/recipes-graphics/xorg-lib/libxcursor_1.1.11.bb
>> #       modified:   meta/recipes-graphics/xorg-lib/libxdamage_1.1.3.bb
>> #       modified:   meta/recipes-graphics/xorg-lib/libxfixes_4.0.5.bb
>> #       modified:   meta/recipes-graphics/xorg-lib/libxft_2.2.0.bb
>> #       modified:   meta/recipes-graphics/xorg-lib/libxrandr_1.3.1.bb
>> #       modified:   meta/recipes-graphics/xorg-lib/libxrender_0.9.6.bb
>> #       modified:   meta/recipes-graphics/xorg-lib/pixman_0.20.2.bb
>> #       modified:
>> meta/recipes-graphics/xorg-proto/compositeproto_0.4.2.bb
>> #       modified:
>> meta/recipes-graphics/xorg-proto/damageproto_1.2.1.bb
>> #       modified:   meta/recipes-graphics/xorg-proto/fixesproto_4.1.2.bb
>> #       modified:   meta/recipes-graphics/xorg-proto/randrproto_1.3.2.bb
>> #       modified:
>> meta/recipes-graphics/xorg-proto/renderproto_0.11.1.bb
>> #       modified:
>> meta/recipes-graphics/xorg-proto/xineramaproto_1.2.1.bb
>> #       modified:   meta/recipes-multimedia/alsa/alsa-tools_1.0.20.bb
>> #       modified:   meta/recipes-support/atk/atk.inc
>> #       modified:   meta/recipes-support/libcroco/libcroco_0.6.2.bb
>> #       modified:   meta/recipes-support/libgcrypt/libgcrypt.inc
>> #       modified:   meta/recipes-support/libgpg-error/libgpg-error_1.9.bb
>>
>> I also ran into a problem when I added native to atk, I get this error
>> which makes no sense at all to me:
>>     NOTE: package atk-native-1.32.0-r0: task do_fetch: Started
>>     ERROR: Function 'Fetcher failure for URL:
>> 'http://download.gnome.org/sources/atk/1.32/atk-native-1.32.0.tar.bz2'.
>> Unable to fetch URL
>> http://download.gnome.org/sources/atk/1.32/atk-native-1.32.0.tar.bz2 from
>> any source.' failed
>> This seems to be the only package in the set above that wants to fetch a
>> -native
>> tarball (there are no such files in the sources repository as far as I can tell)
>>
>> Thanks
>>
>>
>> --
>> ------------------------------------------------------------
>> Gary Thomas                 |  Consulting for the
>> MLB Associates              |    Embedded world
>> ------------------------------------------------------------
>> _______________________________________________
>> poky mailing list
>> poky@yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/poky

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------


^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Problems adding native support packages
  2011-03-11  5:18       ` Xu, Dongxiao
  2011-03-11  5:52         ` Tian, Kevin
@ 2011-03-11 11:29         ` Gary Thomas
  1 sibling, 0 replies; 14+ messages in thread
From: Gary Thomas @ 2011-03-11 11:29 UTC (permalink / raw)
  To: Xu, Dongxiao; +Cc: Poky

On 03/10/2011 10:18 PM, Xu, Dongxiao wrote:
> Tian, Kevin wrote:
>>> From: Xu, Dongxiao
>>> Sent: Friday, March 11, 2011 1:09 PM
>>>
>>> Tian, Kevin wrote:
>>>>> From: Gary Thomas
>>>>> Sent: Friday, March 11, 2011 11:29 AM
>>>>>
>>>>> I'm trying to import a native package from OE for which the main
>>>>> package depends on libiconv.  This seems to imply that when I
>>>>> extend to the native package using BBCLASSEXTEND, the native
>>>>> package depends on virtual/libiconv-native
>>>>>
>>>>> I can't figure out how to provide this.  Any clues?
>>>>
>>>> I'm not sure about the problem here. do you want
>>>> virtual/libiconv-native dependency or not? If target recipe already
>>>> has a DEPENDS = "libiconv", then with BBCLASSEXTEND you have
>>>> libiconv-native automatically.
>>>>
>>>> Or if you only want to add libiconv-native for native recipe
>>>> exclusively, then:
>>>>
>>>> DEPENDS_virtclass-native = "virtual/libiconv-native"
>>>>
>>>> Thanks
>>>> Kevin
>>>>
>>>>>
>>>>> n.b. the recipe from OE is librsvg and importing it seems to be
>>>>> pretty invasive.  To build the native package, I needed to add
>>>>> native support for all of these packages:
>>>>>
>>>>> #       modified:   meta/recipes-gnome/gnome/libart-lgpl_2.3.21.bb
>>>>> #       modified:   meta/recipes-gnome/gtk+/gtk+.inc
>>>>> #       modified:   meta/recipes-graphics/cairo/cairo.inc
>>>>> #       modified:   meta/recipes-graphics/pango/pango.inc #
>>>>> modified: meta/recipes-graphics/xorg-lib/libxcomposite_0.4.3.bb #
>>>>> modified:   meta/recipes-graphics/xorg-lib/libxcursor_1.1.11.bb #
>>>>> modified:   meta/recipes-graphics/xorg-lib/libxdamage_1.1.3.bb #
>>>>> modified:   meta/recipes-graphics/xorg-lib/libxfixes_4.0.5.bb #
>>>>> modified:   meta/recipes-graphics/xorg-lib/libxft_2.2.0.bb #
>>>>> modified:   meta/recipes-graphics/xorg-lib/libxrandr_1.3.1.bb #
>>>>> modified:   meta/recipes-graphics/xorg-lib/libxrender_0.9.6.bb #
>>>>> modified:   meta/recipes-graphics/xorg-lib/pixman_0.20.2.bb #
>>>>> modified: meta/recipes-graphics/xorg-proto/compositeproto_0.4.2.bb
>>>>> # modified: meta/recipes-graphics/xorg-proto/damageproto_1.2.1.bb #
>>>>> modified:   meta/recipes-graphics/xorg-proto/fixesproto_4.1.2.bb #
>>>>> modified:   meta/recipes-graphics/xorg-proto/randrproto_1.3.2.bb #
>>>>> modified: meta/recipes-graphics/xorg-proto/renderproto_0.11.1.bb #
>>>>> modified: meta/recipes-graphics/xorg-proto/xineramaproto_1.2.1.bb #
>>>>> modified:   meta/recipes-multimedia/alsa/alsa-tools_1.0.20.bb #
>>>>> modified:   meta/recipes-support/atk/atk.inc #       modified:
>>>>> meta/recipes-support/libcroco/libcroco_0.6.2.bb #       modified:
>>>>> meta/recipes-support/libgcrypt/libgcrypt.inc #       modified:
>>>>> meta/recipes-support/libgpg-error/libgpg-error_1.9.bb
>>>>>
>>>>> I also ran into a problem when I added native to atk, I get this
>>>>> error which makes no sense at all to me:
>>>>>     NOTE: package atk-native-1.32.0-r0: task do_fetch: Started
>>>>>     ERROR: Function 'Fetcher failure for URL:
>>>>> 'http://download.gnome.org/sources/atk/1.32/atk-native-1.32.0.tar.bz2'.
>>>>> Unable to fetch URL
>>>>> http://download.gnome.org/sources/atk/1.32/atk-native-1.32.0.tar.bz
>>>>> 2 from any source.' failed This seems to be the only package in
>>>>> the set above that wants to fetch a -native tarball (there are no
>>>>> such files in the sources repository as far as I can tell)
>>>
>>> atk's SRC_URI is assigned like:
>>>
>>> SRC_URI =
>>> "http://download.gnome.org/sources/atk/1.32/${PN}-${PV}.tar.bz2"
>>>
>>> After introducing native to atk, PN is changed to atk-native, thus
>>> no resouce is found in the repo.
>>>
>>> I will make a fix to that. But for your quick workaournd, you can
>>> change the atk's SRC_URI to:
>>>
>>> SRC_URI =
>>> "http://download.gnome.org/sources/atk/1.32/atk-${PV}.tar.bz2"
>>>
>>
>> use ${BPN}-${PV} instead.
>
> Yes. This is the right approach.
>
> I checked in current poky meta recipes, there are about 67 recipes which directly uses ${PN} in the SRC_URI line.
>
> Do we need to change all of them to ${BPN}?

This worked fine, thanks.  Now to figure out how to get virtual/libiconv-native built.

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------


^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Problems adding native support packages
  2011-03-11 11:19   ` Gary Thomas
@ 2011-03-11 12:13     ` Gary Thomas
  2011-03-11 16:23       ` Joshua Lock
  2011-03-12  0:09       ` Tian, Kevin
  0 siblings, 2 replies; 14+ messages in thread
From: Gary Thomas @ 2011-03-11 12:13 UTC (permalink / raw)
  To: Tian, Kevin; +Cc: Poky

On 03/11/2011 04:19 AM, Gary Thomas wrote:
> On 03/10/2011 09:57 PM, Tian, Kevin wrote:
>>> From: Gary Thomas
>>> Sent: Friday, March 11, 2011 11:29 AM
>>>
>>> I'm trying to import a native package from OE for which the
>>> main package depends on libiconv. This seems to imply that
>>> when I extend to the native package using BBCLASSEXTEND, the
>>> native package depends on virtual/libiconv-native
>>>
>>> I can't figure out how to provide this. Any clues?
>>
>> I'm not sure about the problem here. do you want virtual/libiconv-native dependency
>> or not? If target recipe already has a DEPENDS = "libiconv", then with BBCLASSEXTEND
>> you have libiconv-native automatically.
>>
>> Or if you only want to add libiconv-native for native recipe exclusively, then:
>>
>> DEPENDS_virtclass-native = "virtual/libiconv-native"
>
> Actually, the problem is that such a dependency was added automatically by BBCLASSEXTEND.
> virtual/libiconv is provided by eglibc package, but it's not clear if it can provide
> virtual/libiconv-native

It comes from this dependency which seems very hard to satisfy:
   meta/recipes-graphics/pango/pango.inc:DEPENDS = "glib-2.0 fontconfig freetype zlib virtual/libiconv virtual/libx11 libxft gtk-doc-native cairo"

It looks like I can side-step this by adding
   ASSUME_PROVIDED += " virtual/libiconv-native "

>
> The other problem is that there is a meta/recipes-support/libiconv/libiconv_1.9.2.bb recipe
> in the tree which does not build at all, native or target.
>
>>>
>>> n.b. the recipe from OE is librsvg and importing it seems to be
>>> pretty invasive. To build the native package, I needed to add
>>> native support for all of these packages:
>>>
>>> # modified: meta/recipes-gnome/gnome/libart-lgpl_2.3.21.bb
>>> # modified: meta/recipes-gnome/gtk+/gtk+.inc
>>> # modified: meta/recipes-graphics/cairo/cairo.inc
>>> # modified: meta/recipes-graphics/pango/pango.inc
>>> # modified: meta/recipes-graphics/xorg-lib/libxcomposite_0.4.3.bb
>>> # modified: meta/recipes-graphics/xorg-lib/libxcursor_1.1.11.bb
>>> # modified: meta/recipes-graphics/xorg-lib/libxdamage_1.1.3.bb
>>> # modified: meta/recipes-graphics/xorg-lib/libxfixes_4.0.5.bb
>>> # modified: meta/recipes-graphics/xorg-lib/libxft_2.2.0.bb
>>> # modified: meta/recipes-graphics/xorg-lib/libxrandr_1.3.1.bb
>>> # modified: meta/recipes-graphics/xorg-lib/libxrender_0.9.6.bb
>>> # modified: meta/recipes-graphics/xorg-lib/pixman_0.20.2.bb
>>> # modified:
>>> meta/recipes-graphics/xorg-proto/compositeproto_0.4.2.bb
>>> # modified:
>>> meta/recipes-graphics/xorg-proto/damageproto_1.2.1.bb
>>> # modified: meta/recipes-graphics/xorg-proto/fixesproto_4.1.2.bb
>>> # modified: meta/recipes-graphics/xorg-proto/randrproto_1.3.2.bb
>>> # modified:
>>> meta/recipes-graphics/xorg-proto/renderproto_0.11.1.bb
>>> # modified:
>>> meta/recipes-graphics/xorg-proto/xineramaproto_1.2.1.bb
>>> # modified: meta/recipes-multimedia/alsa/alsa-tools_1.0.20.bb
>>> # modified: meta/recipes-support/atk/atk.inc
>>> # modified: meta/recipes-support/libcroco/libcroco_0.6.2.bb
>>> # modified: meta/recipes-support/libgcrypt/libgcrypt.inc
>>> # modified: meta/recipes-support/libgpg-error/libgpg-error_1.9.bb
>>>
>>> I also ran into a problem when I added native to atk, I get this error
>>> which makes no sense at all to me:
>>> NOTE: package atk-native-1.32.0-r0: task do_fetch: Started
>>> ERROR: Function 'Fetcher failure for URL:
>>> 'http://download.gnome.org/sources/atk/1.32/atk-native-1.32.0.tar.bz2'.
>>> Unable to fetch URL
>>> http://download.gnome.org/sources/atk/1.32/atk-native-1.32.0.tar.bz2 from
>>> any source.' failed
>>> This seems to be the only package in the set above that wants to fetch a
>>> -native
>>> tarball (there are no such files in the sources repository as far as I can tell)
>>>
>>> Thanks
>>>
>>>
>>> --
>>> ------------------------------------------------------------
>>> Gary Thomas | Consulting for the
>>> MLB Associates | Embedded world
>>> ------------------------------------------------------------
>>> _______________________________________________
>>> poky mailing list
>>> poky@yoctoproject.org
>>> https://lists.yoctoproject.org/listinfo/poky
>

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------


^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Problems adding native support packages
  2011-03-11 12:13     ` Gary Thomas
@ 2011-03-11 16:23       ` Joshua Lock
  2011-03-12  0:09       ` Tian, Kevin
  1 sibling, 0 replies; 14+ messages in thread
From: Joshua Lock @ 2011-03-11 16:23 UTC (permalink / raw)
  To: poky

On Fri, 2011-03-11 at 05:13 -0700, Gary Thomas wrote:
> On 03/11/2011 04:19 AM, Gary Thomas wrote:
> > On 03/10/2011 09:57 PM, Tian, Kevin wrote:
> >>> From: Gary Thomas
> >>> Sent: Friday, March 11, 2011 11:29 AM
> >>>
> >>> I'm trying to import a native package from OE for which the
> >>> main package depends on libiconv. This seems to imply that
> >>> when I extend to the native package using BBCLASSEXTEND, the
> >>> native package depends on virtual/libiconv-native
> >>>
> >>> I can't figure out how to provide this. Any clues?
> >>
> >> I'm not sure about the problem here. do you want virtual/libiconv-native dependency
> >> or not? If target recipe already has a DEPENDS = "libiconv", then with BBCLASSEXTEND
> >> you have libiconv-native automatically.
> >>
> >> Or if you only want to add libiconv-native for native recipe exclusively, then:
> >>
> >> DEPENDS_virtclass-native = "virtual/libiconv-native"
> >
> > Actually, the problem is that such a dependency was added automatically by BBCLASSEXTEND.
> > virtual/libiconv is provided by eglibc package, but it's not clear if it can provide
> > virtual/libiconv-native
> 
> It comes from this dependency which seems very hard to satisfy:
>    meta/recipes-graphics/pango/pango.inc:DEPENDS = "glib-2.0 fontconfig freetype zlib virtual/libiconv virtual/libx11 libxft gtk-doc-native cairo"

virtual/libiconv is set in the *libc.conf included by the distro:
meta/conf/distro/include/poky-eglibc.inc:PREFERRED_PROVIDER_virtual/libiconv ?= "eglibc"
meta/conf/distro/include/poky-eglibc.inc:PREFERRED_PROVIDER_virtual/libiconv-nativesdk ?= "eglibc-nativesdk"

I guess we need a PREFERRED_PROVIDER_virtual/libiconv-natives ?=
"eglibc-native" entry in this file?

Cheers,
Joshua
-- 
Joshua Lock
        Yocto Build System Monkey
        Intel Open Source Technology Centre



^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Problems adding native support packages
  2011-03-11  5:52         ` Tian, Kevin
@ 2011-03-11 22:25           ` Richard Purdie
  2011-03-13 22:26             ` Gary Thomas
  0 siblings, 1 reply; 14+ messages in thread
From: Richard Purdie @ 2011-03-11 22:25 UTC (permalink / raw)
  To: Tian, Kevin; +Cc: Poky

On Fri, 2011-03-11 at 13:52 +0800, Tian, Kevin wrote:
> From: Xu, Dongxiao:
> > Tian, Kevin wrote:
> > >>
> > >> atk's SRC_URI is assigned like:
> > >>
> > >> SRC_URI =
> > >> "http://download.gnome.org/sources/atk/1.32/${PN}-${PV}.tar.bz2"
> > >>
> > >> After introducing native to atk, PN is changed to atk-native, thus
> > >> no resouce is found in the repo.
> > >>
> > >> I will make a fix to that. But for your quick workaournd, you can
> > >> change the atk's SRC_URI to:
> > >>
> > >> SRC_URI =
> > >> "http://download.gnome.org/sources/atk/1.32/atk-${PV}.tar.bz2"
> > >>
> > >
> > > use ${BPN}-${PV} instead.
> > 
> > Yes. This is the right approach.
> > 
> > I checked in current poky meta recipes, there are about 67 recipes which
> > directly uses ${PN} in the SRC_URI line.
> > 
> > Do we need to change all of them to ${BPN}?
> > 
> 
> I think it's a cleaner way to use BPN, or even simple BP. This would avoid an error
> alarm when extending some recipes to native. :-)

This is exactly the use case for the BPN variable so yes, making
standardised use of that would be good.

Cheers,

Richard



^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Problems adding native support packages
  2011-03-11 12:13     ` Gary Thomas
  2011-03-11 16:23       ` Joshua Lock
@ 2011-03-12  0:09       ` Tian, Kevin
  1 sibling, 0 replies; 14+ messages in thread
From: Tian, Kevin @ 2011-03-12  0:09 UTC (permalink / raw)
  To: Gary Thomas; +Cc: Poky

> From: Gary Thomas [mailto:gary@mlbassoc.com]
> Sent: Friday, March 11, 2011 8:14 PM
> 
> On 03/11/2011 04:19 AM, Gary Thomas wrote:
> > On 03/10/2011 09:57 PM, Tian, Kevin wrote:
> >>> From: Gary Thomas
> >>> Sent: Friday, March 11, 2011 11:29 AM
> >>>
> >>> I'm trying to import a native package from OE for which the
> >>> main package depends on libiconv. This seems to imply that
> >>> when I extend to the native package using BBCLASSEXTEND, the
> >>> native package depends on virtual/libiconv-native
> >>>
> >>> I can't figure out how to provide this. Any clues?
> >>
> >> I'm not sure about the problem here. do you want virtual/libiconv-native
> dependency
> >> or not? If target recipe already has a DEPENDS = "libiconv", then with
> BBCLASSEXTEND
> >> you have libiconv-native automatically.
> >>
> >> Or if you only want to add libiconv-native for native recipe exclusively, then:
> >>
> >> DEPENDS_virtclass-native = "virtual/libiconv-native"
> >
> > Actually, the problem is that such a dependency was added automatically by
> BBCLASSEXTEND.
> > virtual/libiconv is provided by eglibc package, but it's not clear if it can provide
> > virtual/libiconv-native
> 
> It comes from this dependency which seems very hard to satisfy:
>    meta/recipes-graphics/pango/pango.inc:DEPENDS = "glib-2.0 fontconfig
> freetype zlib virtual/libiconv virtual/libx11 libxft gtk-doc-native cairo"
> 
> It looks like I can side-step this by adding
>    ASSUME_PROVIDED += " virtual/libiconv-native "
> 

the other alternative is to use DEPENDS_virtclass-native to list all dependencies 
you think the native recipe requires instead of implicitly sharing same DEPENDS
from target recipe.

Thanks
Kevin


^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: Problems adding native support packages
  2011-03-11 22:25           ` Richard Purdie
@ 2011-03-13 22:26             ` Gary Thomas
  0 siblings, 0 replies; 14+ messages in thread
From: Gary Thomas @ 2011-03-13 22:26 UTC (permalink / raw)
  To: Richard Purdie; +Cc: Poky

On 03/11/2011 03:25 PM, Richard Purdie wrote:
> On Fri, 2011-03-11 at 13:52 +0800, Tian, Kevin wrote:
>> From: Xu, Dongxiao:
>>> Tian, Kevin wrote:
>>>>>
>>>>> atk's SRC_URI is assigned like:
>>>>>
>>>>> SRC_URI =
>>>>> "http://download.gnome.org/sources/atk/1.32/${PN}-${PV}.tar.bz2"
>>>>>
>>>>> After introducing native to atk, PN is changed to atk-native, thus
>>>>> no resouce is found in the repo.
>>>>>
>>>>> I will make a fix to that. But for your quick workaournd, you can
>>>>> change the atk's SRC_URI to:
>>>>>
>>>>> SRC_URI =
>>>>> "http://download.gnome.org/sources/atk/1.32/atk-${PV}.tar.bz2"
>>>>>
>>>>
>>>> use ${BPN}-${PV} instead.
>>>
>>> Yes. This is the right approach.
>>>
>>> I checked in current poky meta recipes, there are about 67 recipes which
>>> directly uses ${PN} in the SRC_URI line.
>>>
>>> Do we need to change all of them to ${BPN}?
>>>
>>
>> I think it's a cleaner way to use BPN, or even simple BP. This would avoid an error
>> alarm when extending some recipes to native. :-)
>
> This is exactly the use case for the BPN variable so yes, making
> standardised use of that would be good.

I filed this as bug #860 so the problem is not forgotten.

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------


^ permalink raw reply	[flat|nested] 14+ messages in thread

end of thread, other threads:[~2011-03-13 22:26 UTC | newest]

Thread overview: 14+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2011-03-11  3:28 Problems adding native support packages Gary Thomas
2011-03-11  4:57 ` Tian, Kevin
2011-03-11  5:09   ` Xu, Dongxiao
2011-03-11  5:15     ` Tian, Kevin
2011-03-11  5:18       ` Xu, Dongxiao
2011-03-11  5:52         ` Tian, Kevin
2011-03-11 22:25           ` Richard Purdie
2011-03-13 22:26             ` Gary Thomas
2011-03-11 11:29         ` Gary Thomas
2011-03-11  8:21     ` Khem Raj
2011-03-11 11:19   ` Gary Thomas
2011-03-11 12:13     ` Gary Thomas
2011-03-11 16:23       ` Joshua Lock
2011-03-12  0:09       ` Tian, Kevin

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.