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