Re: List of dependent packages

Re: List of dependent packages

[Christopher Lang]

Joaquim,

I find "ipkg list" on the running target device very helpful. It lists all 
packages an image consists of.

Also "ipkg info" on the target device produces some output. Here you can see 
all packages and their dependencies.

This only works if you have an image already running on the target device.

I hope this helps.

Chris
  


Am Dienstag, 26. September 2006 13:22 schrieb Joaquim Duran:
> Dear all,
>
> Is there any way to know the set of packages to be included in an
> image? Or more generally, how can I list the set of packages (with
> recursion) that are needed for one specified package?
>
> This should be done once processed the config file and updated the cache
> and before the compilation of packages.
>
> Thanks and Best Regards,
> Joaquim Duran
>
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel

List of dependent packages

[Joaquim Duran]

Dear all,

Is there any way to know the set of packages to be included in an
image? Or more generally, how can I list the set of packages (with
recursion) that are needed for one specified package?

This should be done once processed the config file and updated the cache 
and before the compilation of packages.

Thanks and Best Regards,
Joaquim Duran

Re: List of dependent packages

[Paul Sokolovsky]

Hello Joaquim,

Tuesday, September 26, 2006, 2:22:00 PM, you wrote:

> Dear all,

> Is there any way to know the set of packages to be included in an
> image? Or more generally, how can I list the set of packages (with
> recursion) that are needed for one specified package?

> This should be done once processed the config file and updated the cache
> and before the compilation of packages.

  bitbake --help would the first place to consult. --dry-run,
--verbose, --graphviz swicthes would be of primary interest. And yes,
bitbake still doesn't provide enough insight into its internal
functioning. Patches to improve that (given they cover broad usecases)
would be welcome by Bitbake maintainers, I guess.

> Thanks and Best Regards,
> Joaquim Duran


-- 
Best regards,
 Paul                            mailto:pmiscml@gmail.com

Re: List of dependent packages

[Joaquim Duran]

Hello Chris,

This helps but it's not my idea. The main difference between the two 
procedures is the time needed to generate the image ;-) .

Anyway, thanks for your help.

Thanks and Best Regards,
Joaquim Duran


En/na Christopher Lang ha escrit:
> Joaquim,
> 
> I find "ipkg list" on the running target device very helpful. It lists all 
> packages an image consists of.
> 
> Also "ipkg info" on the target device produces some output. Here you can see 
> all packages and their dependencies.
> 
> This only works if you have an image already running on the target device.
> 
> I hope this helps.
> 
> Chris
>   
> 
> 
> Am Dienstag, 26. September 2006 13:22 schrieb Joaquim Duran:
>> Dear all,
>>
>> Is there any way to know the set of packages to be included in an
>> image? Or more generally, how can I list the set of packages (with
>> recursion) that are needed for one specified package?
>>
>> This should be done once processed the config file and updated the cache
>> and before the compilation of packages.
>>
>> Thanks and Best Regards,
>> Joaquim Duran
>>
>>
>> _______________________________________________
>> Openembedded-devel mailing list
>> Openembedded-devel@lists.openembedded.org
>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
> 

Re: List of dependent packages

[Richard Purdie]

On Tue, 2006-09-26 at 15:01 +0300, Paul Sokolovsky wrote:
> > Is there any way to know the set of packages to be included in an
> > image? Or more generally, how can I list the set of packages (with
> > recursion) that are needed for one specified package?
> 
> > This should be done once processed the config file and updated the cache
> > and before the compilation of packages.
> 
>   bitbake --help would the first place to consult. --dry-run,
> --verbose, --graphviz swicthes would be of primary interest. And yes,
> bitbake still doesn't provide enough insight into its internal
> functioning. Patches to improve that (given they cover broad usecases)
> would be welcome by Bitbake maintainers, I guess.

The bitbake maintainers would certainly welcome patches and its not the
first time I've seen a request for this feature :)

I'd also be happy to discuss a roadmap for bitbake. Your comments in #oe
have highlighted the fact that whilst I and perhaps some others know
where things are going, a lot of things are in my head which isn't
perhaps the best place for them.

See a follow up email I'll send later today...

Regards,

Richard

Re: List of dependent packages

[pHilipp Zabel]

On 9/26/06, Joaquim Duran <joaquinduran@adtelecom.es> wrote:
> Hello,
>
> Thanks for your answer. This is closer that I was looking for.
>
> I've tested both options (--dry-run) and (--graphviz).
>
> Using the first one with bootstrap image, the following output has been
> shown (it shown that several packages should be used and I should choose
> one):
>
> OE Build Configuration:
> BB_VERSION     = "1.6.1"
> OE_REVISION    = "57f56983ed32783fae7cfa0440e1f3a7cfc2280c"
> TARGET_ARCH    = "arm"
> TARGET_OS      = "linux"
> MACHINE        = "colibri"
> DISTRO         = "colibrioe"
> DISTRO_VERSION = "1.0"
> TARGET_FPU     = ""
>
> NOTE: multiple providers are available (task-bootstrap-unionroot,
> task-bootstrap);
> NOTE: consider defining PREFERRED_PROVIDER_task-bootstrap
> NOTE: package bootstrap-image-1.0: started
> NOTE: package bootstrap-image-1.0: completed
> NOTE: build 200609261620: completed

I wonder if this NOTE should only be shown if there is no provider foo providing
foo itself. If there is, PREFERRED_PROVIDER_foo ?= "foo" would then have
to be set internally.
It looks like now, every time somebody decides to provide an alternative to
some existing package, everybody has to add PREFERRED_PROVIDER
entries for this or live with the NOTEs.

> The simple question is: how can I define
> PREFERRED_PROVIDER_task-bootstrap line the local.conf file?

PREFERRED_PROVIDER_task-bootstrap = "task-bootstrap"

regards
Philipp

Re: List of dependent packages

[Richard Purdie]

On Tue, 2006-09-26 at 16:57 +0200, pHilipp Zabel wrote:
> > NOTE: multiple providers are available (task-bootstrap-unionroot,
> > task-bootstrap);
> > NOTE: consider defining PREFERRED_PROVIDER_task-bootstrap
> > NOTE: package bootstrap-image-1.0: started
> > NOTE: package bootstrap-image-1.0: completed
> > NOTE: build 200609261620: completed
> 
> I wonder if this NOTE should only be shown if there is no provider foo providing
> foo itself. If there is, PREFERRED_PROVIDER_foo ?= "foo" would then have
> to be set internally.
> It looks like now, every time somebody decides to provide an alternative to
> some existing package, everybody has to add PREFERRED_PROVIDER
> entries for this or live with the NOTEs.

Bitbake's behaviour in that regard is flawed. Its also dangerous as the
order it prints those options is significant and it will choose
task-bootstrap-unionroot in this case unless instructed otherwise.
Basically, the names have no significance to bitbake and it will choose
one, effectively at random :-/. When I remember, I will address this in
bitbake...

Richard

Re: List of dependent packages

[Joaquim Duran]

Hello,

Thanks for your answer. This is closer that I was looking for.

I've tested both options (--dry-run) and (--graphviz).

Using the first one with bootstrap image, the following output has been 
shown (it shown that several packages should be used and I should choose 
one):

OE Build Configuration:
BB_VERSION     = "1.6.1"
OE_REVISION    = "57f56983ed32783fae7cfa0440e1f3a7cfc2280c"
TARGET_ARCH    = "arm"
TARGET_OS      = "linux"
MACHINE        = "colibri"
DISTRO         = "colibrioe"
DISTRO_VERSION = "1.0"
TARGET_FPU     = ""

NOTE: multiple providers are available (task-bootstrap-unionroot, 
task-bootstrap);
NOTE: consider defining PREFERRED_PROVIDER_task-bootstrap
NOTE: package bootstrap-image-1.0: started
NOTE: package bootstrap-image-1.0: completed
NOTE: build 200609261620: completed


The simple question is: how can I define 
PREFERRED_PROVIDER_task-bootstrap line the local.conf file?


The execution of the second option has finished with an error of 
bitbake. I'll send the error to bitbake page.


Thanks and Best Regards,
Joaquim Duran



En/na Paul Sokolovsky ha escrit:
> Hello Joaquim,
> 
> Tuesday, September 26, 2006, 2:22:00 PM, you wrote:
> 
>> Dear all,
> 
>> Is there any way to know the set of packages to be included in an
>> image? Or more generally, how can I list the set of packages (with
>> recursion) that are needed for one specified package?
> 
>> This should be done once processed the config file and updated the cache
>> and before the compilation of packages.
> 
>   bitbake --help would the first place to consult. --dry-run,
> --verbose, --graphviz swicthes would be of primary interest. And yes,
> bitbake still doesn't provide enough insight into its internal
> functioning. Patches to improve that (given they cover broad usecases)
> would be welcome by Bitbake maintainers, I guess.
> 
>> Thanks and Best Regards,
>> Joaquim Duran
> 
> 

Re: List of dependent packages

[Joaquim Duran]

Thanks.

Joaquim Duran

En/na pHilipp Zabel ha escrit:
> On 9/26/06, Joaquim Duran <joaquinduran@adtelecom.es> wrote:
>> Hello,
>>
>> Thanks for your answer. This is closer that I was looking for.
>>
>> I've tested both options (--dry-run) and (--graphviz).
>>
>> Using the first one with bootstrap image, the following output has been
>> shown (it shown that several packages should be used and I should choose
>> one):
>>
>> OE Build Configuration:
>> BB_VERSION     = "1.6.1"
>> OE_REVISION    = "57f56983ed32783fae7cfa0440e1f3a7cfc2280c"
>> TARGET_ARCH    = "arm"
>> TARGET_OS      = "linux"
>> MACHINE        = "colibri"
>> DISTRO         = "colibrioe"
>> DISTRO_VERSION = "1.0"
>> TARGET_FPU     = ""
>>
>> NOTE: multiple providers are available (task-bootstrap-unionroot,
>> task-bootstrap);
>> NOTE: consider defining PREFERRED_PROVIDER_task-bootstrap
>> NOTE: package bootstrap-image-1.0: started
>> NOTE: package bootstrap-image-1.0: completed
>> NOTE: build 200609261620: completed
> 
> I wonder if this NOTE should only be shown if there is no provider foo providing
> foo itself. If there is, PREFERRED_PROVIDER_foo ?= "foo" would then have
> to be set internally.
> It looks like now, every time somebody decides to provide an alternative to
> some existing package, everybody has to add PREFERRED_PROVIDER
> entries for this or live with the NOTEs.
> 
>> The simple question is: how can I define
>> PREFERRED_PROVIDER_task-bootstrap line the local.conf file?
> 
> PREFERRED_PROVIDER_task-bootstrap = "task-bootstrap"
> 
> regards
> Philipp
> 
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
> 

Re: List of dependent packages

[Joaquim Duran]

Hello,

As I've the impression that Bitbake is very related to OE. I post the 
bug here.

I execute: bitbake -g boostrap-image.
Output:

NOTE: Parsing finished. 3962 cached, 0 parsed, 139 skipped, 27 masked.

Traceback (most recent call last):
   File "/home/qduran/oe/bitbake/bin/bitbake", line 1161, in ?
     main()
   File "/home/qduran/oe/bitbake/bin/bitbake", line 1156, in main
     cooker.cook( BBConfiguration( options ), args[1:] )
   File "/home/qduran/oe/bitbake/bin/bitbake", line 962, in cook
     self.generateDotGraph( pkgs_to_build, 
self.configuration.ignored_dot_deps )
   File "/home/qduran/oe/bitbake/bin/bitbake", line 544, in generateDotGraph
     add_depends( pkgs_to_build )
   File "/home/qduran/oe/bitbake/bin/bitbake", line 467, in add_depends
     fn = myFilterProvider(providers, package)[0]
   File "/home/qduran/oe/bitbake/bin/bitbake", line 413, in myFilterProvider
     preferred_versions[pn] = bb.providers.findBestProvider(pn, pkg_pn)[2:4]
TypeError: findBestProvider() takes at least 3 arguments (2 given)

Hope this helps.


Thanks and Best Regards,
Joaquim Duran


En/na Joaquim Duran ha escrit:
> Hello,
> 
> Thanks for your answer. This is closer that I was looking for.
> 
> I've tested both options (--dry-run) and (--graphviz).
> 
> Using the first one with bootstrap image, the following output has been 
> shown (it shown that several packages should be used and I should choose 
> one):
> 
> OE Build Configuration:
> BB_VERSION     = "1.6.1"
> OE_REVISION    = "57f56983ed32783fae7cfa0440e1f3a7cfc2280c"
> TARGET_ARCH    = "arm"
> TARGET_OS      = "linux"
> MACHINE        = "colibri"
> DISTRO         = "colibrioe"
> DISTRO_VERSION = "1.0"
> TARGET_FPU     = ""
> 
> NOTE: multiple providers are available (task-bootstrap-unionroot, 
> task-bootstrap);
> NOTE: consider defining PREFERRED_PROVIDER_task-bootstrap
> NOTE: package bootstrap-image-1.0: started
> NOTE: package bootstrap-image-1.0: completed
> NOTE: build 200609261620: completed
> 
> 
> The simple question is: how can I define 
> PREFERRED_PROVIDER_task-bootstrap line the local.conf file?
> 
> 
> The execution of the second option has finished with an error of 
> bitbake. I'll send the error to bitbake page.
> 
> 
> Thanks and Best Regards,
> Joaquim Duran
> 
> 
> 
> En/na Paul Sokolovsky ha escrit:
>> Hello Joaquim,
>>
>> Tuesday, September 26, 2006, 2:22:00 PM, you wrote:
>>
>>> Dear all,
>>> Is there any way to know the set of packages to be included in an
>>> image? Or more generally, how can I list the set of packages (with
>>> recursion) that are needed for one specified package?
>>> This should be done once processed the config file and updated the cache
>>> and before the compilation of packages.
>>   bitbake --help would the first place to consult. --dry-run,
>> --verbose, --graphviz swicthes would be of primary interest. And yes,
>> bitbake still doesn't provide enough insight into its internal
>> functioning. Patches to improve that (given they cover broad usecases)
>> would be welcome by Bitbake maintainers, I guess.
>>
>>> Thanks and Best Regards,
>>> Joaquim Duran
>>
> 
> 
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
> 

Re: List of dependent packages

[Ray Lehtiniemi]

On Wednesday 27 September 2006 01:36, Joaquim Duran wrote:
> Hello,
>
> As I've the impression that Bitbake is very related to OE. I post the
> bug here.
>
> I execute: bitbake -g boostrap-image.
> Output:
>
> NOTE: Parsing finished. 3962 cached, 0 parsed, 139 skipped, 27 masked.
>
> Traceback (most recent call last):
>    File "/home/qduran/oe/bitbake/bin/bitbake", line 1161, in ?
>      main()
>    File "/home/qduran/oe/bitbake/bin/bitbake", line 1156, in main
>      cooker.cook( BBConfiguration( options ), args[1:] )
>    File "/home/qduran/oe/bitbake/bin/bitbake", line 962, in cook
>      self.generateDotGraph( pkgs_to_build,
> self.configuration.ignored_dot_deps )
>    File "/home/qduran/oe/bitbake/bin/bitbake", line 544, in
> generateDotGraph add_depends( pkgs_to_build )
>    File "/home/qduran/oe/bitbake/bin/bitbake", line 467, in add_depends
>      fn = myFilterProvider(providers, package)[0]
>    File "/home/qduran/oe/bitbake/bin/bitbake", line 413, in
> myFilterProvider preferred_versions[pn] = bb.providers.findBestProvider(pn,
> pkg_pn)[2:4] TypeError: findBestProvider() takes at least 3 arguments (2
> given)
>

i've found that there are several files under lib/bb/ with this problem.

this patch is cut and pasted, so is probably whitespace mangled....

Index: lib/bb/shell.py
===================================================================
--- lib/bb/shell.py     (revision 612)
+++ lib/bb/shell.py     (working copy)
@@ -57,6 +57,8 @@
 except NameError:
     from sets import Set as set
 import sys, os, readline, socket, httplib, urllib, commands, popen2, copy, 
shlex, Queue, fnmatch
+
+import bb
 from bb import data, parse, build, fatal

 __version__ = "0.5.3.1"
Index: lib/bb/providers.py
===================================================================
--- lib/bb/providers.py (revision 612)
+++ lib/bb/providers.py (working copy)
@@ -23,8 +23,8 @@
 # Place, Suite 330, Boston, MA 02111-1307 USA.

 import os, re
+import bb
 from bb import data, utils
-import bb

 class NoProvider(Exception):
     """Exception raised when no provider can be found"""




hope it helps

ray

Re: List of dependent packages

[Ray Lehtiniemi]

On Wednesday 27 September 2006 07:45, Ray Lehtiniemi wrote:
> On Wednesday 27 September 2006 01:36, Joaquim Duran wrote:

> > myFilterProvider preferred_versions[pn] =
> > bb.providers.findBestProvider(pn, pkg_pn)[2:4] TypeError:
> > findBestProvider() takes at least 3 arguments (2 given)
>
> i've found that there are several files under lib/bb/ with this problem.
>
> this patch is cut and pasted, so is probably whitespace mangled....

whoops, ignore that last patch.  upon closer inspection, i was actually seeing 
a different error with bb.providers.findBestProvider than you are...  mine 
looked like this:


Traceback (most recent call last):
  File "/opt/oe/bitbake/bin/bitbake", line 1161, in ?
    main()
  File "/opt/oe/bitbake/bin/bitbake", line 1156, in main
    cooker.cook( BBConfiguration( options ), args[1:] )
  File "/opt/oe/bitbake/bin/bitbake", line 888, in cook
    self.interactiveMode()
  File "/opt/oe/bitbake/bin/bitbake", line 793, in interactiveMode
    shell.start( self )
  File "/opt/oe/bitbake/lib/bb/shell.py", line 804, in start
    bbshell.main()
  File "/opt/oe/bitbake/lib/bb/shell.py", line 779, in main
    self.processCommand( tokens[0], tokens[1:] or "" )
  File "/opt/oe/bitbake/lib/bb/shell.py", line 736, in processCommand
    result = function( self.commands, params )
  File "/opt/oe/bitbake/lib/bb/shell.py", line 532, in which
    lv, lf, pv, pf = bb.providers.findBestProvider(preferred, 
cooker.configuration.data, cooker.status, cooker.build_cache_fail)
NameError: global name 'bb' is not defined



ray

Re: List of dependent packages

[Paul Sokolovsky]

Hello Joaquim,

Wednesday, September 27, 2006, 10:36:10 AM, you wrote:

> Hello,

> As I've the impression that Bitbake is very related to OE. I post the 
> bug here.

> I execute: bitbake -g boostrap-image.

  Have to say I didn't try -g myself yet. --dry-run --verbose what I
usually use, as was suggested on this last before. And I just tried
that it actuially works without any packages built. Specifically:

bitbake --dry-run --verbose gpe-image|grep "current path"

NOTE: current path: gpe-image (gpe-image)
NOTE: current path: gpe-image (gpe-image) -> ipkg-native (ipkg-native)
NOTE: current path: gpe-image (gpe-image) -> ipkg-native (ipkg-native) -> pkgconfig-native (pkgconfig-native)
NOTE: current path: gpe-image (gpe-image) -> ipkg-native (ipkg-native) -> pkgconfig-native (pkgconfig-native) -> autoconf-nati
NOTE: current path: gpe-image (gpe-image) -> ipkg-native (ipkg-native) -> pkgconfig-native (pkgconfig-native) -> autoconf-nati
NOTE: current path: gpe-image (gpe-image) -> ipkg-native (ipkg-native) -> pkgconfig-native (pkgconfig-native) -> autoconf-nati
NOTE: current path: gpe-image (gpe-image) -> ipkg-native (ipkg-native) -> pkgconfig-native (pkgconfig-native) -> autoconf-nati
NOTE: current path: gpe-image (gpe-image) -> ipkg-native (ipkg-native) -> pkgconfig-native (pkgconfig-native) -> automake-nati
NOTE: current path: gpe-image (gpe-image) -> ipkg-native (ipkg-native) -> pkgconfig-native (pkgconfig-native) -> libtool-nativ
NOTE: current path: gpe-image (gpe-image) -> ipkg-utils-native (ipkg-utils-native)
NOTE: current path: gpe-image (gpe-image) -> fakeroot-native (fakeroot-native)
NOTE: current path: gpe-image (gpe-image) -> file-native (file-native)

Just in case, I'm using bitbake 1.6.1 (from SVN).


> Output:

> NOTE: Parsing finished. 3962 cached, 0 parsed, 139 skipped, 27 masked.

> Traceback (most recent call last):
>    File "/home/qduran/oe/bitbake/bin/bitbake", line 1161, in ?
>      main()
>    File "/home/qduran/oe/bitbake/bin/bitbake", line 1156, in main
>      cooker.cook( BBConfiguration( options ), args[1:] )
>    File "/home/qduran/oe/bitbake/bin/bitbake", line 962, in cook
>      self.generateDotGraph( pkgs_to_build, 
> self.configuration.ignored_dot_deps )
>    File "/home/qduran/oe/bitbake/bin/bitbake", line 544, in generateDotGraph
>      add_depends( pkgs_to_build )
>    File "/home/qduran/oe/bitbake/bin/bitbake", line 467, in add_depends
>      fn = myFilterProvider(providers, package)[0]
>    File "/home/qduran/oe/bitbake/bin/bitbake", line 413, in myFilterProvider
>      preferred_versions[pn] = bb.providers.findBestProvider(pn, pkg_pn)[2:4]
> TypeError: findBestProvider() takes at least 3 arguments (2 given)

  Needs to be fixed, sure. Worth a bugreport at
http://bugs.openembedded.org .

> Hope this helps.



-- 
Best regards,
 Paul                            mailto:pmiscml@gmail.com

Re: List of dependent packages

[Joaquim Duran]

Hello,

Changing the filter I get interesting results:

$bitbake -n -v bootstrap-image|grep "Selecting"

NOTE: Selecting already-staged ipkg-native (0.99.163-r1) to satisfy 
ipkg-native
NOTE: Selecting already-staged pkgconfig-native (0.15.0-r2) to satisfy 
pkgconfig-native
NOTE: Selecting already-staged autoconf-native (2.59-r5) to satisfy 
autoconf-native
NOTE: Selecting already-staged m4-native (1.4.2-r0) to satisfy m4-native
NOTE: Selecting already-staged gnu-config-native (0.1+cvs20050701-r4) to 
satisfy gnu-config-native
NOTE: Selecting already-staged automake-native (1.9.3-r5) to satisfy 
automake-native
NOTE: Selecting already-staged libtool-native (1.5.10-r4) to satisfy 
libtool-native
[...]

It displays the list of packages selected with its version.


$bitbake -n -v bootstrap-image|grep "[Ss]electing"

NOTE: Selecting already-staged file-native (4.16-r1) to satisfy file-native
NOTE: Selecting already-staged gcc-cross (3.3.2-r1) to satisfy 
virtual/arm-linux-gcc
NOTE: selecting gcc-cross to satisfy virtual/arm-linux-gcc due to 
PREFERRED_PROVIDERS
NOTE: Selecting already-staged binutils-cross (2.14.90.driscoll-r0) to 
satisfy virtual/arm-linux-binutils
NOTE: selecting binutils-cross to satisfy virtual/arm-linux-binutils due 
to PREFERRED_PROVIDERS

It displays the list of packages selected with its version and indicates 
which packages has been selected by configuration settings.


Thanks for your comment.


Thanks and Best Regards,
Joaquim Duran



En/na Paul Sokolovsky ha escrit:
> Hello Joaquim,
> 
> Wednesday, September 27, 2006, 10:36:10 AM, you wrote:
> 
>> Hello,
> 
>> As I've the impression that Bitbake is very related to OE. I post the 
>> bug here.
> 
>> I execute: bitbake -g boostrap-image.
> 
>   Have to say I didn't try -g myself yet. --dry-run --verbose what I
> usually use, as was suggested on this last before. And I just tried
> that it actuially works without any packages built. Specifically:
> 
> bitbake --dry-run --verbose gpe-image|grep "current path"
> 
> NOTE: current path: gpe-image (gpe-image)
> NOTE: current path: gpe-image (gpe-image) -> ipkg-native (ipkg-native)
> NOTE: current path: gpe-image (gpe-image) -> ipkg-native (ipkg-native) -> pkgconfig-native (pkgconfig-native)
> NOTE: current path: gpe-image (gpe-image) -> ipkg-native (ipkg-native) -> pkgconfig-native (pkgconfig-native) -> autoconf-nati
> NOTE: current path: gpe-image (gpe-image) -> ipkg-native (ipkg-native) -> pkgconfig-native (pkgconfig-native) -> autoconf-nati
> NOTE: current path: gpe-image (gpe-image) -> ipkg-native (ipkg-native) -> pkgconfig-native (pkgconfig-native) -> autoconf-nati
> NOTE: current path: gpe-image (gpe-image) -> ipkg-native (ipkg-native) -> pkgconfig-native (pkgconfig-native) -> autoconf-nati
> NOTE: current path: gpe-image (gpe-image) -> ipkg-native (ipkg-native) -> pkgconfig-native (pkgconfig-native) -> automake-nati
> NOTE: current path: gpe-image (gpe-image) -> ipkg-native (ipkg-native) -> pkgconfig-native (pkgconfig-native) -> libtool-nativ
> NOTE: current path: gpe-image (gpe-image) -> ipkg-utils-native (ipkg-utils-native)
> NOTE: current path: gpe-image (gpe-image) -> fakeroot-native (fakeroot-native)
> NOTE: current path: gpe-image (gpe-image) -> file-native (file-native)
> 
> Just in case, I'm using bitbake 1.6.1 (from SVN).
> 
> 
>> Output:
> 
>> NOTE: Parsing finished. 3962 cached, 0 parsed, 139 skipped, 27 masked.
> 
>> Traceback (most recent call last):
>>    File "/home/qduran/oe/bitbake/bin/bitbake", line 1161, in ?
>>      main()
>>    File "/home/qduran/oe/bitbake/bin/bitbake", line 1156, in main
>>      cooker.cook( BBConfiguration( options ), args[1:] )
>>    File "/home/qduran/oe/bitbake/bin/bitbake", line 962, in cook
>>      self.generateDotGraph( pkgs_to_build, 
>> self.configuration.ignored_dot_deps )
>>    File "/home/qduran/oe/bitbake/bin/bitbake", line 544, in generateDotGraph
>>      add_depends( pkgs_to_build )
>>    File "/home/qduran/oe/bitbake/bin/bitbake", line 467, in add_depends
>>      fn = myFilterProvider(providers, package)[0]
>>    File "/home/qduran/oe/bitbake/bin/bitbake", line 413, in myFilterProvider
>>      preferred_versions[pn] = bb.providers.findBestProvider(pn, pkg_pn)[2:4]
>> TypeError: findBestProvider() takes at least 3 arguments (2 given)
> 
>   Needs to be fixed, sure. Worth a bugreport at
> http://bugs.openembedded.org .

Done

>> Hope this helps.
> 
> 
>