Trying to add new recipe - getting QA error I don't understand

Trying to add new recipe - getting QA error I don't understand

[Brad Litterell]

[-- Attachment #1: Type: text/plain, Size: 1261 bytes --]

Hi,

I'm new to Yocto, so please let me know if this is the wrong list for questions like this.

I'm trying to add a recipe for a new cmake project (for UCI).  The do_package_qa task reports this problem:

ERROR: QA Issue: uci rdepends on uci-dev
ERROR: QA run found fatal errors. Please consider fixing them.
ERROR: Function failed: do_package_qa

uci-dev appears to be automatically generated package - there is no recipe for it, and I can't find any reference to it in the actual source code for the package.  In other words, it appears as if Yocto itself is generating this dependency somehow.

Does this sound right?  Can anyone point me in the right direction?

My recipe is pretty simple and looks like this:

===

DESCRIPTION = "UCI Configuration Library"

SECTION = "openwrtlib"


LICENSE = "GPLv2+"

LIC_FILES_CHKSUM = "file://uci.h;beginline=1;endline=13;md5=799502a8112fe590aa1664829bfc7c60<file:///uci.h;beginline=1;endline=13;md5=799502a8112fe590aa1664829bfc7c60>"


PV = "2011-07-18.3"

#see https://forum.openwrt.org/viewtopic.php?id=15243 for git

SRC_URI = "file://uci-${PV}.tar.gz<file:///uci-${PV}.tar.gz>"



EXTRA_OECMAKE="-DBUILD_LUA=OFF"


inherit cmake

===


Thanks for any help,

Brad


[-- Attachment #2: Type: text/html, Size: 3824 bytes --]

Re: Trying to add new recipe - getting QA error I don't understand

[Burton, Ross]

Hi Brad,

On 31 July 2013 18:52, Brad Litterell <bradl@taser.com> wrote:
> I'm new to Yocto, so please let me know if this is the wrong list for
> questions like this.

You've got the right list for support question.

> I'm trying to add a recipe for a new cmake project (for UCI).  The
> do_package_qa task reports this problem:
>
> ERROR: QA Issue: uci rdepends on uci-dev
> ERROR: QA run found fatal errors. Please consider fixing them.
> ERROR: Function failed: do_package_qa
>
> uci-dev appears to be automatically generated package - there is no recipe
> for it, and I can't find any reference to it in the actual source code for
> the package.  In other words, it appears as if Yocto itself is generating
> this dependency somehow.

Correct, oe-core will generate a -dev package by default that contains
(typically) /usr/include and /usr/lib/lib*.so.

This warning indicates that the automatic library dependency
generation added a dependency from uci to uci-dev.  It sounds like
that UCI isn't installing versioned libraries (so eg
/usr/lib/libuci.so is the full library, not a symlink) and the main
uci package is shipping a binary that links to it.

If that's the case then basically UCI is doing shared libraries badly,
and you'll have to tweak the packaging.  Adding to FILES_${PN} to
include all of /usr/lib should put all the libraries into "uci".

> PV = "2011-07-18.3"

I think hyphen in PV isn't recommended, but you can avoid setting this
if you embed the version in the filename.

> #see https://forum.openwrt.org/viewtopic.php?id=15243 for git
> SRC_URI = "file://uci-${PV}.tar.gz"

I presume you have a reason to have a local snapshot of the repo and
are not using a git URI in SRC_URI directly?

Ross

Re: Trying to add new recipe - getting QA error I don't understand

[Brad Litterell]

[-- Attachment #1: Type: text/plain, Size: 3065 bytes --]

Hi Ross,


Thanks for your reply.


First, it appears you are correct that UCI is not following the normal pattern.  Here is the image for the package:

.
└── usr
    ├── bin
    │   ├── uci
    │   └── uci-static
    ├── include
    │   ├── uci_config.h
    │   ├── uci.h
    │   └── ucimap.h
    └── lib
        ├── libuci.a
        └── libuci.so


So, I added this:


FILES_${PN} +="/usr/lib/*"

However that doesn't remove the message.  Did I do it right?

Also, in the error message "uci depends on uci-dev" does "uci" refers to the package name or the executable name?

I wasn't able to remove PV, it ran into a different build break since the tar.gz emits the source folder with that name.  I'm using the tar.gz to make sure I'm building the same source as the project for my old board.  That project used a variant of build root, but we're trying to move to Yocto because it seems to have a better supported future.  IOW, using the tar ball is a way to change only one thing at a time until the rest of the build is happy.

Thanks again,
Brad


On Jul 31, 2013, at 11:45 AM, "Burton, Ross" <ross.burton@intel.com<mailto:ross.burton@intel.com>> wrote:

Hi Brad,

On 31 July 2013 18:52, Brad Litterell <bradl@taser.com<mailto:bradl@taser.com>> wrote:
I'm new to Yocto, so please let me know if this is the wrong list for
questions like this.

You've got the right list for support question.

I'm trying to add a recipe for a new cmake project (for UCI).  The
do_package_qa task reports this problem:

ERROR: QA Issue: uci rdepends on uci-dev
ERROR: QA run found fatal errors. Please consider fixing them.
ERROR: Function failed: do_package_qa

uci-dev appears to be automatically generated package - there is no recipe
for it, and I can't find any reference to it in the actual source code for
the package.  In other words, it appears as if Yocto itself is generating
this dependency somehow.

Correct, oe-core will generate a -dev package by default that contains
(typically) /usr/include and /usr/lib/lib*.so.

This warning indicates that the automatic library dependency
generation added a dependency from uci to uci-dev.  It sounds like
that UCI isn't installing versioned libraries (so eg
/usr/lib/libuci.so is the full library, not a symlink) and the main
uci package is shipping a binary that links to it.

If that's the case then basically UCI is doing shared libraries badly,
and you'll have to tweak the packaging.  Adding to FILES_${PN} to
include all of /usr/lib should put all the libraries into "uci".

PV = "2011-07-18.3"

I think hyphen in PV isn't recommended, but you can avoid setting this
if you embed the version in the filename.

#see https://forum.openwrt.org/viewtopic.php?id=15243 for git
SRC_URI = "file://uci-${PV}.tar.gz<file:///uci-${PV}.tar.gz>"

I presume you have a reason to have a local snapshot of the repo and
are not using a git URI in SRC_URI directly?

Ross


[-- Attachment #2: Type: text/html, Size: 4732 bytes --]

Re: Trying to add new recipe - getting QA error I don't understand

[Khem Raj]

[-- Attachment #1: Type: text/plain, Size: 701 bytes --]


On Jul 31, 2013, at 3:39 PM, Brad Litterell <bradl@taser.com> wrote:

>     └── lib
>         ├── libuci.a
>         └── libuci.so
> 
> So, I added this:
> 
> FILES_${PN} +="/usr/lib/*"

Try something like

FILES_${PN} =+ "${libdir}/libuci.so"


> 
> However that doesn't remove the message.  Did I do it right?
> 


usually .so are symlinks which then go into -dev packages via the default package sieve engine
but I am thinking if we find out that file is not a symlink but a normal shared object then probably
we could stop shoving it into -dev package and instead put it into ${PN}

may be you should file an enhancement bug for it in Yocto bugzilla


[-- Attachment #2: Type: text/html, Size: 3824 bytes --]

Re: Trying to add new recipe - getting QA error I don't understand

[Saul Wold]

On 07/31/2013 03:39 PM, Brad Litterell wrote:
> Hi Ross,
>
>
> Thanks for your reply.
>
>
> First, it appears you are correct that UCI is not following the normal pattern.  Here is the image for the package:
>
> .
> └── usr
>      ├── bin
>      │   ├── uci
>      │   └── uci-static
>      ├── include
>      │   ├── uci_config.h
>      │   ├── uci.h
>      │   └── ucimap.h
>      └── lib
>          ├── libuci.a
>          └── libuci.so
>
>
> So, I added this:
>
>
> FILES_${PN}  +="/usr/lib/*"
>
Brad,

This should be using the ${libdir}, which is the variable that defines 
the correct "/usr/lib"
>
> However that doesn't remove the message.  Did I do it right?
>
> Also, in the error message "uci depends on uci-dev" does "uci" refers to
> the package name or the executable name?
>
> I wasn't able to remove PV, it ran into a different build break since
> the tar.gz emits the source folder with that name.  I'm using the tar.gz
> to make sure I'm building the same source as the project for my old
> board.  That project used a variant of build root, but we're trying to
> move to Yocto because it seems to have a better supported future.  IOW,
> using the tar ball is a way to change only one thing at a time until the
> rest of the build is happy.
>
What's the name of your recipe?  Normally the PV is parsed from the 
recipename <recipename>_<version>.bb recipename goes into BPN (PN) and 
version goes into PV.

You can set the a SRCREV to a specific git hash and that will be stable 
also. But you can start this way and then move to using a true git based 
recipe.

Hope this helps.

Sau!


> Thanks again,
> Brad
>
>
> On Jul 31, 2013, at 11:45 AM, "Burton, Ross" <ross.burton@intel.com
> <mailto:ross.burton@intel.com>> wrote:
>
>> Hi Brad,
>>
>> On 31 July 2013 18:52, Brad Litterell <bradl@taser.com
>> <mailto:bradl@taser.com>> wrote:
>>> I'm new to Yocto, so please let me know if this is the wrong list for
>>> questions like this.
>>
>> You've got the right list for support question.
>>
>>> I'm trying to add a recipe for a new cmake project (for UCI).  The
>>> do_package_qa task reports this problem:
>>>
>>> ERROR: QA Issue: uci rdepends on uci-dev
>>> ERROR: QA run found fatal errors. Please consider fixing them.
>>> ERROR: Function failed: do_package_qa
>>>
>>> uci-dev appears to be automatically generated package - there is no
>>> recipe
>>> for it, and I can't find any reference to it in the actual source
>>> code for
>>> the package.  In other words, it appears as if Yocto itself is generating
>>> this dependency somehow.
>>
>> Correct, oe-core will generate a -dev package by default that contains
>> (typically) /usr/include and /usr/lib/lib*.so.
>>
>> This warning indicates that the automatic library dependency
>> generation added a dependency from uci to uci-dev.  It sounds like
>> that UCI isn't installing versioned libraries (so eg
>> /usr/lib/libuci.so is the full library, not a symlink) and the main
>> uci package is shipping a binary that links to it.
>>
>> If that's the case then basically UCI is doing shared libraries badly,
>> and you'll have to tweak the packaging.  Adding to FILES_${PN} to
>> include all of /usr/lib should put all the libraries into "uci".
>>
>>> PV = "2011-07-18.3"
>>
>> I think hyphen in PV isn't recommended, but you can avoid setting this
>> if you embed the version in the filename.
>>
>>> #see https://forum.openwrt.org/viewtopic.php?id=15243 for git
>>> SRC_URI = "file://uci-${PV}.tar.gz <file:///uci-${PV}.tar.gz>"
>>
>> I presume you have a reason to have a local snapshot of the repo and
>> are not using a git URI in SRC_URI directly?
>>
>> Ross
>
>
>
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>

Re: Trying to add new recipe - getting QA error I don't understand

[Brad Litterell]

[-- Attachment #1: Type: text/plain, Size: 1715 bytes --]

Hi,

I tried

FILES_${PN} =+ "${libdir}/libuci.so"

but under package-split, the .so file is still only listed in the -dev package.

Is it possible that the lib*.so files are always forcibly removed from FILES_${PN}?

I was able to hack the CMakeList.txt file as follows.  If I set SOVERSION on the shared library the expected libuci.so.1 file appears with the libuci.so link which solves the problem.  I'm a little concerned I might have problems with other packages that I haven't ported yet that depend on UCI, but I will see.

may be you should file an enhancement bug for it in Yocto bugzilla

I probably should have mentioned this earlier, but I'm using the 1.3 version of Yocto that's embedded in TI's Arago SDK.  Can I safely pull poky on top of that and see if it fixes the problem or might I have conflicts between Arago BSP layers and the 1.4 Poky recipes?

Thanks,
Brad



On Jul 31, 2013, at 3:58 PM, Khem Raj <raj.khem@gmail.com<mailto:raj.khem@gmail.com>> wrote:


On Jul 31, 2013, at 3:39 PM, Brad Litterell <bradl@taser.com<mailto:bradl@taser.com>> wrote:


    └── lib
        ├── libuci.a
        └── libuci.so


So, I added this:


FILES_${PN} +="/usr/lib/*"

Try something like

FILES_${PN} =+ "${libdir}/libuci.so"



However that doesn't remove the message.  Did I do it right?



usually .so are symlinks which then go into -dev packages via the default package sieve engine
but I am thinking if we find out that file is not a symlink but a normal shared object then probably
we could stop shoving it into -dev package and instead put it into ${PN}

may be you should file an enhancement bug for it in Yocto bugzilla



[-- Attachment #2: Type: text/html, Size: 7319 bytes --]

Re: Trying to add new recipe - getting QA error I don't understand

[Khem Raj]

[-- Attachment #1: Type: text/plain, Size: 1989 bytes --]


On Jul 31, 2013, at 5:52 PM, Brad Litterell <bradl@taser.com> wrote:

> Hi,
> 
> I tried 
> 
>> FILES_${PN} =+ "${libdir}/libuci.so"
> 
> but under package-split, the .so file is still only listed in the -dev package.
> 
> Is it possible that the lib*.so files are always forcibly removed from FILES_${PN}?

what is name of your recipe ?

> 
> I was able to hack the CMakeList.txt file as follows.  If I set SOVERSION on the shared library the expected libuci.so.1 file appears with the libuci.so link which solves the problem.  I'm a little concerned I might have problems with other packages that I haven't ported yet that depend on UCI, but I will see.
> 

thats intact correct way to fix it in view of OE's eyes.

>> may be you should file an enhancement bug for it in Yocto bugzilla
> 
> I probably should have mentioned this earlier, but I'm using the 1.3 version of Yocto that's embedded in TI's Arago SDK.  Can I safely pull poky on top of that and see if it fixes the problem or might I have conflicts between Arago BSP layers and the 1.4 Poky recipes?

Doubt that

> 
> Thanks,
> Brad
> 
> 
> 
> On Jul 31, 2013, at 3:58 PM, Khem Raj <raj.khem@gmail.com> wrote:
> 
>> 
>> On Jul 31, 2013, at 3:39 PM, Brad Litterell <bradl@taser.com> wrote:
>> 
>>>     └── lib
>>>         ├── libuci.a
>>>         └── libuci.so
>>> 
>>> So, I added this:
>>> 
>>> FILES_${PN} +="/usr/lib/*"
>> 
>> Try something like
>> 
>> FILES_${PN} =+ "${libdir}/libuci.so"
>> 
>> 
>>> 
>>> However that doesn't remove the message.  Did I do it right?
>>> 
>> 
>> 
>> usually .so are symlinks which then go into -dev packages via the default package sieve engine
>> but I am thinking if we find out that file is not a symlink but a normal shared object then probably
>> we could stop shoving it into -dev package and instead put it into ${PN}
>> 
>> may be you should file an enhancement bug for it in Yocto bugzilla
>> 
> 


[-- Attachment #2: Type: text/html, Size: 8406 bytes --]

Re: Trying to add new recipe - getting QA error I don't understand

[Brad Litterell]

[-- Attachment #1: Type: text/plain, Size: 2191 bytes --]


On Jul 31, 2013, at 9:35 PM, Khem Raj <raj.khem@gmail.com<mailto:raj.khem@gmail.com>> wrote:


On Jul 31, 2013, at 5:52 PM, Brad Litterell <bradl@taser.com<mailto:bradl@taser.com>> wrote:

Hi,

I tried

FILES_${PN} =+ "${libdir}/libuci.so"

but under package-split, the .so file is still only listed in the -dev package.

Is it possible that the lib*.so files are always forcibly removed from FILES_${PN}?

what is name of your recipe ?

uci.bb




I was able to hack the CMakeList.txt file as follows.  If I set SOVERSION on the shared library the expected libuci.so.1 file appears with the libuci.so link which solves the problem.  I'm a little concerned I might have problems with other packages that I haven't ported yet that depend on UCI, but I will see.


thats intact correct way to fix it in view of OE's eyes.

may be you should file an enhancement bug for it in Yocto bugzilla

I probably should have mentioned this earlier, but I'm using the 1.3 version of Yocto that's embedded in TI's Arago SDK.  Can I safely pull poky on top of that and see if it fixes the problem or might I have conflicts between Arago BSP layers and the 1.4 Poky recipes?

Doubt that

Doubting that I can use Poky, or doubting that Poky will conflict with TI's arago?  Or doubting that using 1.3 has any relevance to this issue?



Thanks,
Brad



On Jul 31, 2013, at 3:58 PM, Khem Raj <raj.khem@gmail.com<mailto:raj.khem@gmail.com>> wrote:


On Jul 31, 2013, at 3:39 PM, Brad Litterell <bradl@taser.com<mailto:bradl@taser.com>> wrote:


    └── lib
        ├── libuci.a
        └── libuci.so


So, I added this:


FILES_${PN} +="/usr/lib/*"

Try something like

FILES_${PN} =+ "${libdir}/libuci.so"



However that doesn't remove the message.  Did I do it right?



usually .so are symlinks which then go into -dev packages via the default package sieve engine
but I am thinking if we find out that file is not a symlink but a normal shared object then probably
we could stop shoving it into -dev package and instead put it into ${PN}

may be you should file an enhancement bug for it in Yocto bugzilla





[-- Attachment #2: Type: text/html, Size: 9383 bytes --]