* Cannot satisfy the following dependencies for task-core-basic: libusb-compat (>= 0.1.3)
@ 2012-02-21 23:50 Brandon Stafford
2012-02-22 12:12 ` Richard Purdie
0 siblings, 1 reply; 7+ messages in thread
From: Brandon Stafford @ 2012-02-21 23:50 UTC (permalink / raw)
To: openembedded-core
[-- Attachment #1: Type: text/plain, Size: 738 bytes --]
Hi all,
In trying to build core-image-basic, it seems that libusb-compat cannot be
found:
| Collected errors:
| * satisfy_dependencies_for: Cannot satisfy the following dependencies
for task-core-basic:
| * libusb-compat (>= 0.1.3) *
| * opkg_install_cmd: Cannot install package task-core-basic.
NOTE: package core-image-basic-1.0-r0: task do_rootfs: Failed
However, it seems like libusb-compat should be findable:
:~/oe-core/build$ ls ../meta/recipes-support/libusb/
libusb1_1.0.8.bb libusb-compat-0.1.3 libusb-compat_0.1.3.bb
Do I need to tell bitbake to look in recipes-support explicitly?
Cheers,
Brandon
--
Brandon Stafford
Rascal Micro: small computers for art and science
Somerville, MA, USA
[-- Attachment #2: Type: text/html, Size: 1137 bytes --]
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Cannot satisfy the following dependencies for task-core-basic: libusb-compat (>= 0.1.3)
2012-02-21 23:50 Cannot satisfy the following dependencies for task-core-basic: libusb-compat (>= 0.1.3) Brandon Stafford
@ 2012-02-22 12:12 ` Richard Purdie
2012-02-22 16:52 ` Brandon Stafford
0 siblings, 1 reply; 7+ messages in thread
From: Richard Purdie @ 2012-02-22 12:12 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
On Tue, 2012-02-21 at 18:50 -0500, Brandon Stafford wrote:
> In trying to build core-image-basic, it seems that libusb-compat
> cannot be found:
>
> | Collected errors:
> | * satisfy_dependencies_for: Cannot satisfy the following
> dependencies for task-core-basic:
> | * libusb-compat (>= 0.1.3) *
> | * opkg_install_cmd: Cannot install package task-core-basic.
> NOTE: package core-image-basic-1.0-r0: task do_rootfs: Failed
>
> However, it seems like libusb-compat should be findable:
>
> :~/oe-core/build$ ls ../meta/recipes-support/libusb/
> libusb1_1.0.8.bb libusb-compat-0.1.3 libusb-compat_0.1.3.bb
>
> Do I need to tell bitbake to look in recipes-support explicitly?
The above error looks like its from the rootfs generation and not from
bitbake itself.
The first question is did it build libusb-compat at all? Are there any
stamps for this in tmp/stamps/*/libusb-compat* or files in
tmp/work/*/libusb-compat* that would suggest that it did?
Secondly, did it place any libusb-compat package into tmp/deploy/ipk/* ?
The answers to the above questions will start to help know where to look
for the problem.
Cheers,
Richard
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Cannot satisfy the following dependencies for task-core-basic: libusb-compat (>= 0.1.3)
2012-02-22 12:12 ` Richard Purdie
@ 2012-02-22 16:52 ` Brandon Stafford
2012-02-22 17:47 ` Richard Purdie
0 siblings, 1 reply; 7+ messages in thread
From: Brandon Stafford @ 2012-02-22 16:52 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
On Wed, Feb 22, 2012 at 7:12 AM, Richard Purdie
<richard.purdie@linuxfoundation.org> wrote:
>
> On Tue, 2012-02-21 at 18:50 -0500, Brandon Stafford wrote:
> > In trying to build core-image-basic, it seems that libusb-compat
> > cannot be found:
> >
> > | Collected errors:
> > | * satisfy_dependencies_for: Cannot satisfy the following
> > dependencies for task-core-basic:
> > | * libusb-compat (>= 0.1.3) *
> > | * opkg_install_cmd: Cannot install package task-core-basic.
> > NOTE: package core-image-basic-1.0-r0: task do_rootfs: Failed
> >
> > However, it seems like libusb-compat should be findable:
> >
> > :~/oe-core/build$ ls ../meta/recipes-support/libusb/
> > libusb1_1.0.8.bb libusb-compat-0.1.3 libusb-compat_0.1.3.bb
> >
> > Do I need to tell bitbake to look in recipes-support explicitly?
>
> The above error looks like its from the rootfs generation and not from
> bitbake itself.
>
> The first question is did it build libusb-compat at all? Are there any
> stamps for this in tmp/stamps/*/libusb-compat* or files in
> tmp/work/*/libusb-compat* that would suggest that it did?
Thanks for the suggestions, Richard. Answers below.
Yes, some stamps exist, but fewer than I would expect. I don't see a
do_compile step.
:~/oe-core/build/tmp-eglibc/stamps$ find . -name libusb-compat*
./armv5te-oe-linux-gnueabi/libusb-compat-1_0.1.3-r3.do_package_write
./armv5te-oe-linux-gnueabi/libusb-compat-1_0.1.3-r3.do_populate_lic_setscene
./armv5te-oe-linux-gnueabi/libusb-compat-1_0.1.3-r3.do_package_setscene.qemuarm
./armv5te-oe-linux-gnueabi/libusb-compat-1_0.1.3-r3.do_package_write_ipk_setscene
./armv5te-oe-linux-gnueabi/libusb-compat-1_0.1.3-r3.do_populate_sysroot_setscene.qemuarm
However, it does look like binaries were created. For example, here is
a 13 kB ELF file:
tmp-eglibc/work/armv5te-oe-linux-gnueabi/libusb-compat-1_0.1.3-r3/packages-split/libusb-compat/lib/libusb-0.1.so.4.4.4
:~/oe-core/build/tmp-eglibc/work/armv5te-oe-linux-gnueabi/libusb-compat-1_0.1.3-r3$
ls -lh packages-split/libusb-compat/lib
total 16K
lrwxrwxrwx 1 rascal rascal 19 2012-02-14 09:03 libusb-0.1.so.4 ->
libusb-0.1.so.4.4.4
-rwxr-xr-x 1 rascal rascal 13K 2012-02-14 09:03 libusb-0.1.so.4.4.4
:~/oe-core/build/tmp-eglibc/work/armv5te-oe-linux-gnueabi/libusb-compat-1_0.1.3-r3$
file packages-split/libusb-compat/lib/libusb-0.1.so.4.4.4
packages-split/libusb-compat/lib/libusb-0.1.so.4.4.4: ELF 32-bit LSB
shared object, ARM, version 1 (SYSV), dynamically linked, stripped
> Secondly, did it place any libusb-compat package into tmp/deploy/ipk/* ?
It did not:
:~/oe-core/build/tmp-eglibc/deploy/ipk$ find . -name libusb-compat*
However, there are a bunch of libusb packages:
:~/oe-core/build/tmp-eglibc/deploy/ipk$ find . -name libusb*
./armv5te/libusb-0.1-dbg_0.1.3-r3_armv5te.ipk
./armv5te/libusb-1.0-0_1.0.8-r3_armv5te.ipk
./armv5te/libusb-1.0-dbg_1.0.8-r3_armv5te.ipk
./armv5te/libusb-1.0-dev_1.0.8-r3_armv5te.ipk
./armv5te/libusb-1.0-staticdev_1.0.8-r3_armv5te.ipk
./armv5te/libusb-0.1-dev_0.1.3-r3_armv5te.ipk
./armv5te/libusb-0.1-4_0.1.3-r3_armv5te.ipk
./armv5te/libusb-0.1-staticdev_0.1.3-r3_armv5te.ipk
If I understand how do_rootfs works from
http://docs.openembedded.org/usermanual/usermanual.html#rootfs_ipkg_class,
it seems like the ipk is not being built correctly, so do_rootfs can't
pull it into the filesystem image.
I'm not sure where to go from here. It looks like at least some code
was compiled, but somehow it's not getting packaged right.
Brandon
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Cannot satisfy the following dependencies for task-core-basic: libusb-compat (>= 0.1.3)
2012-02-22 16:52 ` Brandon Stafford
@ 2012-02-22 17:47 ` Richard Purdie
2012-02-22 18:46 ` Brandon Stafford
0 siblings, 1 reply; 7+ messages in thread
From: Richard Purdie @ 2012-02-22 17:47 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
On Wed, 2012-02-22 at 11:52 -0500, Brandon Stafford wrote:
> On Wed, Feb 22, 2012 at 7:12 AM, Richard Purdie
> <richard.purdie@linuxfoundation.org> wrote:
> >
> > The first question is did it build libusb-compat at all? Are there any
> > stamps for this in tmp/stamps/*/libusb-compat* or files in
> > tmp/work/*/libusb-compat* that would suggest that it did?
>
> Thanks for the suggestions, Richard. Answers below.
>
> Yes, some stamps exist, but fewer than I would expect. I don't see a
> do_compile step.
>
> :~/oe-core/build/tmp-eglibc/stamps$ find . -name libusb-compat*
> ./armv5te-oe-linux-gnueabi/libusb-compat-1_0.1.3-r3.do_package_write
> ./armv5te-oe-linux-gnueabi/libusb-compat-1_0.1.3-r3.do_populate_lic_setscene
> ./armv5te-oe-linux-gnueabi/libusb-compat-1_0.1.3-r3.do_package_setscene.qemuarm
> ./armv5te-oe-linux-gnueabi/libusb-compat-1_0.1.3-r3.do_package_write_ipk_setscene
> ./armv5te-oe-linux-gnueabi/libusb-compat-1_0.1.3-r3.do_populate_sysroot_setscene.qemuarm
What this means is that it build libusb-compat from the sstate cache
rather than building it completely from scratch. The
do_package_write_ipk_setscene in particular means it should have
installed some .ipk files into tmp/deploy/ipk/.
> However, it does look like binaries were created. For example, here is
> a 13 kB ELF file:
> tmp-eglibc/work/armv5te-oe-linux-gnueabi/libusb-compat-1_0.1.3-r3/packages-split/libusb-compat/lib/libusb-0.1.so.4.4.4
>
> :~/oe-core/build/tmp-eglibc/work/armv5te-oe-linux-gnueabi/libusb-compat-1_0.1.3-r3$
> ls -lh packages-split/libusb-compat/lib
> total 16K
> lrwxrwxrwx 1 rascal rascal 19 2012-02-14 09:03 libusb-0.1.so.4 ->
> libusb-0.1.so.4.4.4
> -rwxr-xr-x 1 rascal rascal 13K 2012-02-14 09:03 libusb-0.1.so.4.4.4
> :~/oe-core/build/tmp-eglibc/work/armv5te-oe-linux-gnueabi/libusb-compat-1_0.1.3-r3$
> file packages-split/libusb-compat/lib/libusb-0.1.so.4.4.4
> packages-split/libusb-compat/lib/libusb-0.1.so.4.4.4: ELF 32-bit LSB
> shared object, ARM, version 1 (SYSV), dynamically linked, stripped
>
> > Secondly, did it place any libusb-compat package into tmp/deploy/ipk/* ?
>
> It did not:
>
> :~/oe-core/build/tmp-eglibc/deploy/ipk$ find . -name libusb-compat*
>
> However, there are a bunch of libusb packages:
>
> :~/oe-core/build/tmp-eglibc/deploy/ipk$ find . -name libusb*
> ./armv5te/libusb-0.1-dbg_0.1.3-r3_armv5te.ipk
> ./armv5te/libusb-1.0-0_1.0.8-r3_armv5te.ipk
> ./armv5te/libusb-1.0-dbg_1.0.8-r3_armv5te.ipk
> ./armv5te/libusb-1.0-dev_1.0.8-r3_armv5te.ipk
> ./armv5te/libusb-1.0-staticdev_1.0.8-r3_armv5te.ipk
> ./armv5te/libusb-0.1-dev_0.1.3-r3_armv5te.ipk
> ./armv5te/libusb-0.1-4_0.1.3-r3_armv5te.ipk
> ./armv5te/libusb-0.1-staticdev_0.1.3-r3_armv5te.ipk
I think the library renaming code is renaming "libusb-compat" to a
package called "libusb-0.1" using the 'debian' renaming code. Your
packages are therefore present.
> If I understand how do_rootfs works from
> http://docs.openembedded.org/usermanual/usermanual.html#rootfs_ipkg_class,
> it seems like the ipk is not being built correctly, so do_rootfs can't
> pull it into the filesystem image.
>
> I'm not sure where to go from here. It looks like at least some code
> was compiled, but somehow it's not getting packaged right.
It appears for some reason the system wants a "libusb-compat" when it
should be looking for a "libusb-0.1". This would imply that somewhere,
the renaming failed, either in the dependencies of some package, or at
the rootfs creation point itself.
If you look at the tmp/deploy/ipk/*/Packages index file, you should see
the dependencies of each package listed. It would be interesting to see
if something is depending on "libusb-compat". If there is something I'd
be tempted to try running "bitbake xxx -c cleansstate" and rebuilding
that specific recipe.
If there is nothing listing libusb-compat in index, the problem is in
the rootfs step itself.
Cheers,
Richard
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Cannot satisfy the following dependencies for task-core-basic: libusb-compat (>= 0.1.3)
2012-02-22 17:47 ` Richard Purdie
@ 2012-02-22 18:46 ` Brandon Stafford
2012-02-22 19:31 ` Richard Purdie
0 siblings, 1 reply; 7+ messages in thread
From: Brandon Stafford @ 2012-02-22 18:46 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
On Wed, Feb 22, 2012 at 12:47 PM, Richard Purdie
<richard.purdie@linuxfoundation.org> wrote:
> If you look at the tmp/deploy/ipk/*/Packages index file, you should see
> the dependencies of each package listed. It would be interesting to see
> if something is depending on "libusb-compat". If there is something I'd
> be tempted to try running "bitbake xxx -c cleansstate" and rebuilding
> that specific recipe.
Victory!
Looking at the Packages file, it appears that gnupg depends on libusb-compat.
I then ran this series of commands:
bitbake gnupg -c cleansstate
bitbake -c clean core-image-basic
bitbake core-image-basic
These tasks all completed successfully. Thank you, Richard, for taking
the time to point me in the right direction.
One last question-- somehow, the first build of gnupg was expecting to
find libusb-compat by the wrong name. This was cached in sstate, and a
subsequent build fixed it. Why would it work the second time if the
recipe was unchanged?
Cheers,
Brandon
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Cannot satisfy the following dependencies for task-core-basic: libusb-compat (>= 0.1.3)
2012-02-22 18:46 ` Brandon Stafford
@ 2012-02-22 19:31 ` Richard Purdie
2012-02-22 19:45 ` Brandon Stafford
0 siblings, 1 reply; 7+ messages in thread
From: Richard Purdie @ 2012-02-22 19:31 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
On Wed, 2012-02-22 at 13:46 -0500, Brandon Stafford wrote:
> On Wed, Feb 22, 2012 at 12:47 PM, Richard Purdie
> <richard.purdie@linuxfoundation.org> wrote:
>
> > If you look at the tmp/deploy/ipk/*/Packages index file, you should see
> > the dependencies of each package listed. It would be interesting to see
> > if something is depending on "libusb-compat". If there is something I'd
> > be tempted to try running "bitbake xxx -c cleansstate" and rebuilding
> > that specific recipe.
>
> Victory!
>
> Looking at the Packages file, it appears that gnupg depends on libusb-compat.
>
> I then ran this series of commands:
>
> bitbake gnupg -c cleansstate
> bitbake -c clean core-image-basic
> bitbake core-image-basic
>
> These tasks all completed successfully. Thank you, Richard, for taking
> the time to point me in the right direction.
>
> One last question-- somehow, the first build of gnupg was expecting to
> find libusb-compat by the wrong name. This was cached in sstate, and a
> subsequent build fixed it. Why would it work the second time if the
> recipe was unchanged?
That is a question I'd love to have the answer to. Something went wrong
but I don't know what. If you had the old sstate package, it would have
been interesting to compare the old and new ones but you've probably
deleted that now :(. If you do still have them I'd be very interested in
a copy of the two files.
Was this with master or the 2011-1 release branch (or are you using poky
and one of its release branches)?
Cheers,
Richard
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Cannot satisfy the following dependencies for task-core-basic: libusb-compat (>= 0.1.3)
2012-02-22 19:31 ` Richard Purdie
@ 2012-02-22 19:45 ` Brandon Stafford
0 siblings, 0 replies; 7+ messages in thread
From: Brandon Stafford @ 2012-02-22 19:45 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
On Wed, Feb 22, 2012 at 2:31 PM, Richard Purdie
<richard.purdie@linuxfoundation.org> wrote:
>>
>> One last question-- somehow, the first build of gnupg was expecting to
>> find libusb-compat by the wrong name. This was cached in sstate, and a
>> subsequent build fixed it. Why would it work the second time if the
>> recipe was unchanged?
>
> That is a question I'd love to have the answer to. Something went wrong
> but I don't know what. If you had the old sstate package, it would have
> been interesting to compare the old and new ones but you've probably
> deleted that now :(. If you do still have them I'd be very interested in
> a copy of the two files.
bitbake -c cleansstate would have deleted the old sstate, right?
At some point in the next few weeks, I'll be rebuilding all this from
scratch. If I run into the same error, I'd be happy to try to save
trees before and after the cleansstate/rebuild.
> Was this with master or the 2011-1 release branch (or are you using poky
> and one of its release branches)?
This is master, last pulled Feb 8, 2012, commit
4ef5e70f531f48cef90805402c16ec02ad3f2b92.
Thanks again for the help.
Brandon
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2012-02-22 19:53 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2012-02-21 23:50 Cannot satisfy the following dependencies for task-core-basic: libusb-compat (>= 0.1.3) Brandon Stafford
2012-02-22 12:12 ` Richard Purdie
2012-02-22 16:52 ` Brandon Stafford
2012-02-22 17:47 ` Richard Purdie
2012-02-22 18:46 ` Brandon Stafford
2012-02-22 19:31 ` Richard Purdie
2012-02-22 19:45 ` Brandon Stafford
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.