* 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.