[yocto] Question: xxxx listed in PACKAGES multiple times, this leads to packaging errors
Dinh Nguyen (dinhn)
dinhn at cisco.com
Wed Oct 5 11:12:08 PDT 2016
Thanks Khem
>> I guess its getting renamed as per debian package renaming rules. Just add
>> ALLOW_EMPTY_${PN} = "1"
I added ALLOW_EMPTY_${PN} = “1”
And encountered the same issue as specified in previous mail. For the very first time after adding it, everything went well, including the -dev, -dbg and main ipk packages and image were built. All source files under c-mlib git is there.
Subsequence bitbake -c clean c-mlib and bitbake c-mlib, ipk packages were built, but c-mlib git directory became empty.
dinhn at rs-bldsrv:/media/raghuram/data/dinhn/ioxDevLatest/ioxsdk/yp/tmp/work/core2-64-poky-linux/c-mlib/1.1-r0/git$ ls -ltr
total 0
Thanks much,
—Dinh
On 10/5/16, 9:52 AM, "Khem Raj" <raj.khem at gmail.com> wrote:
>On Wed, Oct 5, 2016 at 9:06 AM, Dinh Nguyen (dinhn) <dinhn at cisco.com> wrote:
>> Many thanks Paul. Your help is greatly appreciated.
>>
>> 1. >>> Like the other responder I would suggest you not set PACKAGES
>>
>> Yes, I did not set the PACKAGES, so -dev, -dbg and main packages were built as shown below:
>>
>> dinhn at rs-bldsrv:/media/raghuram/data/dinhn/ioxDevLatest/ioxsdk/yp$ find tmp/deploy | grep c-mlibtmp/deploy/ipk/core2-64/c-mlib-dbg_1.1-r0_core2-64.ipk
>> tmp/deploy/ipk/core2-64/c-mlib-dev_1.1-r0_core2-64.ipk
>> tmp/deploy/ipk/core2-64/c-mlib_1.1-r0_core2-64.ipk
>> tmp/deploy/licenses/c-mlib
>>
>> 2. >>> FILES_${PN}-dev = "${includedir}”
>>
>> I added that to .bb as you suggested so .so file doesn't end up in the ${PN}-dev
>> Package — No longer see the error mentioned in previous mail. Thx
>>
>> 3. >>> This is what I suspected would happen - these files would normally be part of
>> the ${PN}-dbg package, but since you've removed that from PACKAGES, they are
>> ending up unpackaged and that is not allowed.
>>
>> Did you mean the "install -m 0644 xxx yyy” to remove those files from the PACKAGES? How do I copy .so and binaries from my target to the libdir or bindir?
>>
>> After changing the .bb to remove the PACKAGES setting and FILES_${PN}-dev = "${includedir}”
>> For the very first time, packages were built find, image were created under image directory and c-mlib source is still in the yp workspace as shown below:
>>
>> A.Packages were built
>> dinhn at rs-bldsrv:/media/raghuram/data/dinhn/ioxDevLatest/ioxsdk/yp$ find tmp/deploy | grep c-mlib
>> tmp/deploy/ipk/core2-64/c-mlib-dbg_1.1-r0_core2-64.ipk
>> tmp/deploy/ipk/core2-64/c-mlib-dev_1.1-r0_core2-64.ipk
>> tmp/deploy/ipk/core2-64/c-mlib_1.1-r0_core2-64.ipk
>> tmp/deploy/licenses/c-mlib
>>
>> B. Source files and the c-mlib git directory still have all the sources (e.g just grep the mlib_api.c)
>> dinhn at rs-bldsrv:/media/raghuram/data/dinhn/ioxDevLatest/ioxsdk/yp$ find . -name "mlib_api.c"
>> ./tmp/work/core2-64-poky-linux/c-mlib/1.1-r0/git/src/mlib_api.c
>> ./tmp/work/core2-64-poky-linux/c-mlib/1.1-r0/packages-split/c-mlib-dbg/usr/src/debug/c-mlib/1.1-r0/git/src/mlib_api.c
>> ./tmp/work/core2-64-poky-linux/c-mlib/1.1-r0/package/usr/src/debug/c-mlib/1.1-r0/git/src/mlib_api.c
>> dinhn at rs-bldsrv:/media/raghuram/data/dinhn/ioxDevLatest/ioxsdk/yp$
>>
>> C. Image was built as well including binaries and libmlib.so
>> dinhn at rs-bldsrv:/media/raghuram/data/dinhn/ioxDevLatest/ioxsdk/yp/tmp/work/core2-64-poky-linux/c-mlib/1.1-r0/image/usr/bin$ ls -ltr
>> total 1424
>> -rw-r--r-- 1 dinhn dinhn 171701 Oct 5 01:17 datamodel_cache
>> -rw-r--r-- 1 dinhn dinhn 187434 Oct 5 01:17 invoke
>> -rw-r--r-- 1 dinhn dinhn 184961 Oct 5 01:17 invoke_b
>> -rw-r--r-- 1 dinhn dinhn 171701 Oct 5 01:17 protocol_infra
>> -rw-r--r-- 1 dinhn dinhn 191362 Oct 5 01:17 publisher
>> -rw-r--r-- 1 dinhn dinhn 187084 Oct 5 01:17 rpc-register
>> -rw-r--r-- 1 dinhn dinhn 179648 Oct 5 01:17 service
>> -rw-r--r-- 1 dinhn dinhn 174518 Oct 5 01:17 subscriber
>>
>> dinhn at rs-bldsrv:/media/raghuram/data/dinhn/ioxDevLatest/ioxsdk/yp/tmp/work/core2-64-poky-linux/c-mlib/1.1-r0/image/usr/bin$ cd ../lib
>> dinhn at rs-bldsrv:/media/raghuram/data/dinhn/ioxDevLatest/ioxsdk/yp/tmp/work/core2-64-poky-linux/c-mlib/1.1-r0/image/usr/lib$ ls -ltr
>> total 856
>> -rw-r--r-- 3 dinhn dinhn 872657 Oct 5 01:17 libmlib.so
>>
>> So it is all good for the first time, but thereafter that, if I do clean “bitbake -c clean c-mlib” and “bitbake c-mlib” again.
>> All packages were build successful, but all data under c-mlib got was gone. Nothing there including .c/h files, image directory etc...
>>
>> dinhn at rs-bldsrv:/media/raghuram/data/dinhn/ioxDevLatest/ioxsdk/yp/tmp/work/core2-64-poky-linux/c-mlib/1.1-r0/git$ ls -ltr
>> total 0
>> dinhn at rs-bldsrv:/media/raghuram/data/dinhn/ioxDevLatest/ioxsdk/yp/tmp/work/core2-64-poky-linux/c-mlib/1.1-r0/git$
>>
>> Please give me an idea why how to solve this? Sorry for a long email ;-))
>
>I guess its getting renamed as per debian package renaming rules. Just add
>
>ALLOW_EMPTY_${PN} = "1"
>
>and see if you get the ipk
>
>>
>> Best,
>> —Dinh
>>
>>
>>
>>
>>
>> On 10/4/16, 11:55 PM, "Paul Eggleton" <paul.eggleton at linux.intel.com> wrote:
>>
>>>On Wed, 05 Oct 2016 05:12:27 Dinh Nguyen wrote:
>>>> Thanks much Paul.
>>>>
>>>> >>>> PACKAGES = "${PN}" should work
>>>>
>>>> It solved the early error “ c-mlib listed in PACKAGES multiple times, this
>>>> leads to packaging errors” — Thanks again.
>>>>
>>>>
>>>> But running into other issue. Below is my do_install
>>>>
>>>> do_install () {
>>>> oe_runmake all
>>>> install -d ${D}${libdir}
>>>> install -d ${D}${bindir}
>>>> install -m 0644 ${S}/target/libmlib.so ${D}${libdir}
>>>> install -m 0644 ${S}/target/datamodel_cache ${D}${bindir}
>>>> install -m 0644 ${S}/target/invoke ${D}${bindir}
>>>> install -m 0644 ${S}/target/invoke_b ${D}${bindir}
>>>> install -m 0644 ${S}/target/protocol_infra ${D}${bindir}
>>>> install -m 0644 ${S}/target/publisher ${D}${bindir}
>>>> install -m 0644 ${S}/target/rpc-register ${D}${bindir}
>>>> install -m 0644 ${S}/target/service ${D}${bindir}
>>>> install -m 0644 ${S}/target/subscriber ${D}${bindir}
>>>> }
>>>>
>>>> PACKAGES = "${PN}"
>>>> FILES_${PN} = "/usr/bin/datamodel_cache \
>>>> /usr/bin/invoke \
>>>> /usr/bin/invoke_b \
>>>> /usr/lib/libmlib.so \
>>>> /usr/bin/protocol_infra \
>>>> /usr/bin/publisher \
>>>> /usr/bin/rpc-register \
>>>> /usr/bin/service \
>>>> /usr/bin/subscriber"
>>>>
>>>>
>>>>
>>>> And under ${S}/target, it has the libmlib.so and other binaries built,
>>>> And I intended to copy the .so to ${D}${libdir} and binarires to
>>>> ${D}${bindir}. I am able to build the c-mlib package as shown below:
>>>
>>>> dinhn at rs-bldsrv:/media/raghuram/data/dinhn/ioxDevLatest/ioxsdk/yp$ find
>>>> tmp/deploy | grep c-mlib
>>>> tmp/deploy/ipk/core2-64/c-mlib_1.1-r0_core2-64.ipk
>>>>
>>>>
>>>> The problem is that, after "bitbake c-mlib”, it moved all sources under ${S}
>>>> to /usr/src/debug etc..
>>>> I googled but unable to find the root cause.
>>>> Would you and other can help to identify the issue?
>>>> NOTE: Executing RunQueue Tasks
>>>> ERROR: QA Issue: c-mlib: Files/directories were installed but not shipped
>>>> /usr/src
>>>> /usr/lib/.debug
>>>> /usr/lib/.debug/libmlib.so
>>>> /usr/src/debug
>>>> /usr/src/debug/c-mlib
>>>> /usr/src/debug/c-mlib/1.1-r0
>>>> /usr/src/debug/c-mlib/1.1-r0/git
>>>> /usr/src/debug/c-mlib/1.1-r0/git/src
>>>> /usr/src/debug/c-mlib/1.1-r0/git/include
>>>> /usr/src/debug/c-mlib/1.1-r0/git/deps
>>>> /usr/src/debug/c-mlib/1.1-r0/git/src/mlib_api.c
>>>> /usr/src/debug/c-mlib/1.1-r0/git/src/mlib_metrics.c
>>>> /usr/src/debug/c-mlib/1.1-r0/git/src/mlib_util.c
>>>> /usr/src/debug/c-mlib/1.1-r0/git/src/mlib_local_metrics.c
>>>> /usr/src/debug/c-mlib/1.1-r0/git/src/dslink_bindings
>>>> /usr/src/debug/c-mlib/1.1-r0/git/src/utils
>>>> /usr/src/debug/c-mlib/1.1-r0/git/src/service_sdk
>>>> /usr/src/debug/c-mlib/1.1-r0/git/src/dslink_bindings/mlib_service_cache.c
>>>> /usr/src/debug/c-mlib/1.1-r0/git/src/dslink_bindings/mlib_wrapper.c
>>>> /usr/src/debug/c-mlib/1.1-r0/git/src/dslink_bindings/mlib_dsa.c
>>>> /usr/src/debug/c-mlib/1.1-r0/git/src/dslink_bindings/include
>>>> ….
>>>
>>>This is what I suspected would happen - these files would normally be part of
>>>the ${PN}-dbg package, but since you've removed that from PACKAGES, they are
>>>ending up unpackaged and that is not allowed.
>>>
>>>Like the other responder I would suggest you not set PACKAGES - instead you
>>>just need to take steps so that the .so file doesn't end up in the ${PN}-dev
>>>package. You could do something like this:
>>>
>>>FILES_${PN}-dev = "${includedir}"
>>>
>>>Cheers,
>>>Paul
>>>
>>>--
>>>
>>>Paul Eggleton
>>>Intel Open Source Technology Centre
>> --
>> _______________________________________________
>> yocto mailing list
>> yocto at yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/yocto
More information about the yocto
mailing list