[yocto] Question: xxxx listed in PACKAGES multiple times, this leads to packaging errors

Dinh Nguyen (dinhn) dinhn at cisco.com
Thu Oct 6 11:39:14 PDT 2016 

>> yes thats normal when package is re-used from sstate-cache

Many thanks Khem. Got it, so the IPK packages were built early is OK. 
I did a clean all and redo the bitbake, all packages, images were rebuilt.

Thanks again,
  —Dinh 


>
>> On Oct 5, 2016, at 11:43 AM, Dinh Nguyen (dinhn) <dinhn at cisco.com> wrote:
>> 
>> 
>> 
>>>> then it is just going to reuse the build artifacts from last builds and not checkout the sources etc.
>>>> all those tasks will be skipped.
>> 
>>>> why are looking for sources in a build tree ?
>> 
>> 
>> Not only source under
>> .. yp/tmp/work/core2-64-poky-linux/c-mlib/1.1-r0/git
>> 
>> But other data such as such as the yp/tmp/work/core2-64-poky-linux/c-mlib/1.1-r0/image/* was also gone. The following image that I have it in the first place.
>
>yes thats normal when package is re-used from sstate-cache
>> 
>> 
>> 
>> 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
>> 
>> 
>> Thanks,
>>  —Dinh
>> 
>> On 10/5/16, 11:26 AM, "Khem Raj" <raj.khem at gmail.com> wrote:
>> 
>>> 
>>>> On Oct 5, 2016, at 11:18 AM, Dinh Nguyen (dinhn) <dinhn at cisco.com> wrote:
>>>> 
>>>>>> Are the files present in the image/packages?  Maybe it is just the
>>>>>> bitbake cache skipping doing work it already did last time.
>>>> 
>>>> If I don’t do the bitbake clean, and just do bitbake again, then yes.
>>>> 
>>>> 
>>>> But if I do “bitbake -c clean c-mlib” and bitbake again, the is where the problem.
>>> 
>>> 
>>> well its using sstate cache here so when you do clean and rebuild and it notices no changes from previous builds
>>> then it is just going to reuse the build artifacts from last builds and not checkout the sources etc.
>>> all those tasks will be skipped.
>>> 
>>> why are looking for sources in a build tree ?
>>> I ask because if you want to hack on it then I would recommend following devtool workflow.
>>> see
>>> http://www.yoctoproject.org/docs/latest/dev-manual/dev-manual.html#using-devtool-in-your-workflow
>>> 
>>> 
>>>> 
>>>> Thanks,
>>>> —Dinh
>>>> 
>>>> 
>>>> 
>>>> 
>>>> On 10/5/16, 9:30 AM, "Lennart Sorensen" <lsorense at csclub.uwaterloo.ca> wrote:
>>>> 
>>>>> On Wed, Oct 05, 2016 at 04:06:25PM +0000, Dinh Nguyen (dinhn) 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 ;-))
>>>>> 
>>>>> Are the files present in the image/packages?  Maybe it is just the
>>>>> bitbake cache skipping doing work it already did last time.
>>>>> 
>>>>> --
>>>>> Len Sorensen
>>>> --
>>>> _______________________________________________
>>>> yocto mailing list
>>>> yocto at yoctoproject.org
>>>> https://lists.yoctoproject.org/listinfo/yocto
>>> 
>

More information about the yocto mailing list