Re: [yocto] poky/meta/recipes-connectivity/bind

[Dinh Nguyen (dinhn)]

Many thanks for your prompt  response as always Khem.
I was trying to build the bind recipe, but seeing the nslookup has been 
removed. I left my yocto project quite long time ago so I am kind of out of 
date ;-))

Best & thanks again.
  --Dinh

From: Khem Raj 
Date: Thursday, February 14, 2019 at 4:14 PM
To: "Dinh Nguyen (dinhn)" 
Cc: "Burton, Ross" , "yocto@yoctoproject.org" 

Subject: Re: poky/meta/recipes-connectivity/bind



On Thu, Feb 14, 2019 at 3:47 PM Dinh Nguyen (dinhn) 
mailto:di...@cisco.com>> wrote:
Gurus,

What was the main reason why nslookup has been removed from 
Poky/meta/recipes-connectivity/bind/>.bb?


nsloopup is supposed to go away as the upstream maintainers of this has stopped 
maintaining it. using dig or host
utility is suggested.


do_install_append() {





   rm "${D}${bindir}/nslookup"


   rm "${D}${mandir}/man1/nslookup.1"


   rmdir "${D}${localstatedir}/run"


   rmdir --ignore-fail-on-non-empty "${D}${localstatedir}"


   install -d -o bind "${D}${localstatedir}/cache/bind"


   install -d "${D}${sysconfdir}/bind"


   install -d "${D}${sysconfdir}/init.d"


   install -m 644 ${S}/conf/* "${D}${sysconfdir}/bind/"


   install -m 755 "${S}/init.d" "${D}${sysconfdir}/init.d/bind"


if ${@bb.utils.contains('PACKAGECONFIG', 'python3', 'true', 'false', 
d)}; then


  sed -i -e '1s,#!.*python3,#! /usr/bin/python3,' \


  ${D}${sbindir}/dnssec-coverage \


  ${D}${sbindir}/dnssec-checkds \


  ${D}${sbindir}/dnssec-keymgr


   fi


Which yocto now has dig or host for DNS lookup?


you can install bind-utils in image which should
give you dig and host


Thanks,
  --Dinh
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] poky/meta/recipes-connectivity/bind

[Dinh Nguyen (dinhn)]

Gurus,

What was the main reason why nslookup has been removed from 
Poky/meta/recipes-connectivity/bind/>.bb?

do_install_append() {





   rm "${D}${bindir}/nslookup"


   rm "${D}${mandir}/man1/nslookup.1"


   rmdir "${D}${localstatedir}/run"


   rmdir --ignore-fail-on-non-empty "${D}${localstatedir}"


   install -d -o bind "${D}${localstatedir}/cache/bind"


   install -d "${D}${sysconfdir}/bind"


   install -d "${D}${sysconfdir}/init.d"


   install -m 644 ${S}/conf/* "${D}${sysconfdir}/bind/"


   install -m 755 "${S}/init.d" "${D}${sysconfdir}/init.d/bind"


if ${@bb.utils.contains('PACKAGECONFIG', 'python3', 'true', 'false', 
d)}; then


  sed -i -e '1s,#!.*python3,#! /usr/bin/python3,' \


  ${D}${sbindir}/dnssec-coverage \


  ${D}${sbindir}/dnssec-checkds \


  ${D}${sbindir}/dnssec-keymgr


   fi


Which yocto now has dig or host for DNS lookup?

Thanks,
  --Dinh
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] FW: cmake version 3.0.0 or greater

[Dinh Nguyen (dinhn)]

>>> I found  
>>> git://git.openembedded.org/openembedded-core<http://git.openembedded.org/openembedded-core>
>>>  has version  3.6.x
>>> So I tried to pull it in. But this version got a trace back when integrated 
>>> to our SDK Yocto Dizzy.

>Take the recipes from master, copy the changes to dizzy, then fix any problems 
>caused by taking recipes from now and applying them to a two year old release.

Thanks Ross,

I am trying to take the cmake recipe from the master now. Hope it will work.

I was hoping to see if there is any  existing 3.x version for Dizzy. OK,  let 
see how it goes with the latest from the master.

—Dinh

From: "Burton, Ross" <ross.bur...@intel.com<mailto:ross.bur...@intel.com>>
Date: Tuesday, November 8, 2016 at 4:48 AM
To: dinhn <di...@cisco.com<mailto:di...@cisco.com>>
Cc: "yocto@yoctoproject.org<mailto:yocto@yoctoproject.org>" 
<yocto@yoctoproject.org<mailto:yocto@yoctoproject.org>>
Subject: Re: [yocto] FW: cmake version 3.0.0 or greater


On 8 November 2016 at 12:43, Dinh Nguyen (dinhn) 
<di...@cisco.com<mailto:di...@cisco.com>> wrote:
Right, and I am trying to upgrade to 3x version.  Would you please tell me 
which cmake patch or recipe  that I can use to upgrade to 3.x version for Dizzy?

What you said:

> I found  
> git://git.openembedded.org/openembedded-core<http://git.openembedded.org/openembedded-core>
>  has version  3.6.x
> So I tried to pull it in. But this version got a trace back when integrated 
> to our SDK Yocto Dizzy.

Take the recipes from master, copy the changes to dizzy, then fix any problems 
caused by taking recipes from now and applying them to a two year old release.

Ross
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] FW: cmake version 3.0.0 or greater

[Dinh Nguyen (dinhn)]

>> This tells me that you didn't upgrade cmake-native to 3.x.

Right, and I am trying to upgrade to 3x version.  Would you please tell me 
which cmake patch or recipe  that I can use to upgrade to 3.x version for Dizzy?

Thanks,
  —Dinh

From: "Burton, Ross" <ross.bur...@intel.com<mailto:ross.bur...@intel.com>>
Date: Tuesday, November 8, 2016 at 4:34 AM
To: dinhn <di...@cisco.com<mailto:di...@cisco.com>>
Cc: "yocto@yoctoproject.org<mailto:yocto@yoctoproject.org>" 
<yocto@yoctoproject.org<mailto:yocto@yoctoproject.org>>
Subject: Re: [yocto] FW: cmake version 3.0.0 or greater


On 8 November 2016 at 12:23, Dinh Nguyen (dinhn) 
<di...@cisco.com<mailto:di...@cisco.com>> wrote:
Here is the error message when trying to build sdk-dslink-c within Yocto  Dizzy 
version.

| + echo 
/media/raghuram/data/dinhn/ioxDevLatest/ioxsdk/yp64/tmp/work/core2-64-poky-linux/sdk-dslink-c/1.1-r0
| + 
/media/raghuram/data/dinhn/ioxDevLatest/ioxsdk/yp64/tmp/work/core2-64-poky-linux/sdk-dslink-c/1.1-r0/sdk-dslink-c-939fb15c97688276b1234a0e0092e61fdbe65c03/tools/build.sh
| CMake Error at CMakeLists.txt:1 (cmake_minimum_required):
|   CMake 3.0.0 or higher is required.  You are running version 2.8.12.2
|

This tells me that you didn't upgrade cmake-native to 3.x.

Ross
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] FW: cmake version 3.0.0 or greater

[Dinh Nguyen (dinhn)]

Thanks Ross,

Here is the error message when trying to build sdk-dslink-c within Yocto  Dizzy 
version.

| + echo 
/media/raghuram/data/dinhn/ioxDevLatest/ioxsdk/yp64/tmp/work/core2-64-poky-linux/sdk-dslink-c/1.1-r0
| + 
/media/raghuram/data/dinhn/ioxDevLatest/ioxsdk/yp64/tmp/work/core2-64-poky-linux/sdk-dslink-c/1.1-r0/sdk-dslink-c-939fb15c97688276b1234a0e0092e61fdbe65c03/tools/build.sh
| CMake Error at CMakeLists.txt:1 (cmake_minimum_required):
|   CMake 3.0.0 or higher is required.  You are running version 2.8.12.2
|
|
| -- Configuring incomplete, errors occurred!
| See also 
"/media/raghuram/data/dinhn/ioxDevLatest/ioxsdk/yp64/tmp/work/core2-64-poky-linux/sdk-dslink-c/1.1-r0/sdk-dslink-c-939fb15c97688276b1234a0e0092e61fdbe65c03/build/CMakeFiles/CMakeOutput.log".
| See also 
"/media/raghuram/data/dinhn/ioxDevLatest/ioxsdk/yp64/tmp/work/core2-64-poky-linux/sdk-dslink-c/1.1-r0/sdk-dslink-c-939fb15c97688276b1234a0e0092e61fdbe65c03/build/CMakeFiles/CMakeError.log".
| + bb_exit_handler

Here  is part of the CMakeList.txt for sdk-dslink-c that required the minimum 
version:

cmake_minimum_required(VERSION 3.0.0 FATAL_ERROR)
project(sdk_dslink_c C)

option(USE_CCACHE "Enable CCache Support" ON)
option(DSLINK_BUILD_BROKER "Whether to build the broker" OFF)
option(DSLINK_BUILD_EXAMPLES "Whether to build the examples" OFF)
option(DSLINK_TEST "Whether to enable tests" OFF)
option(TOOLCHAIN_DYNAMIC_LINK_ENABLE "Enable Dynamic Linking for Toolchain" ON)

# Configure CMake Modules #

set(CMAKE_MODULE_PATH ${CMAKE_CURRENT_LIST_DIR}/tools/cmake)

include(MacroEnsureOutOfSourceBuild)
ensure_out_of_source_build("Please do not build the C SDK inside the source 
directory.")

# Check Configuration #

if ("${CMAKE_GENERATOR}" STREQUAL "Ninja" AND DSLINK_TEST)
message(WARNING "C SDK Unit Tests are currently not supported under Ninja.")
set(DSLINK_TEST OFF)
endif()
…

Thanks

From: "Burton, Ross" <ross.bur...@intel.com<mailto:ross.bur...@intel.com>>
Date: Tuesday, November 8, 2016 at 2:00 AM
To: dinhn <di...@cisco.com<mailto:di...@cisco.com>>
Cc: "yocto@yoctoproject.org<mailto:yocto@yoctoproject.org>" 
<yocto@yoctoproject.org<mailto:yocto@yoctoproject.org>>
Subject: Re: [yocto] FW: cmake version 3.0.0 or greater


On 8 November 2016 at 04:52, Dinh Nguyen (dinhn) 
<di...@cisco.com<mailto:di...@cisco.com>> wrote:
Our SDK has the Yocto Project 1.7 Dizzy version and it supports cmake 2.8.12 
version as show below:
./meta/recipes-devtools/cmake/cmake_2.8.12.2.bb<http://cmake_2.8.12.2.bb>
./meta/recipes-devtools/cmake/cmake-native_2.8.12.2.bb<http://cmake-native_2.8.12.2.bb>

We need to pulling the cmake 3.x.x version for our sdk-dslink-c recipe build.

I found  
git://git.openembedded.org/openembedded-core<http://git.openembedded.org/openembedded-core>
 has version  3.6.x
So I tried to pull it in. But this version got a trace back when integrated to 
our SDK Yocto Dizzy.

Can you advise which open embedded-core version/git location to pull in to SDK 
Dizzy version for cmake 3.x.x version

There is no official dizzy recipe for cmake 3.  If you share what the error is, 
then we may be able to help backporting the recipe to dizzy.

Ross
cmake_minimum_required(VERSION 3.0.0 FATAL_ERROR)
project(sdk_dslink_c C)

option(USE_CCACHE "Enable CCache Support" ON)
option(DSLINK_BUILD_BROKER "Whether to build the broker" OFF)
option(DSLINK_BUILD_EXAMPLES "Whether to build the examples" OFF)
option(DSLINK_TEST "Whether to enable tests" OFF)
option(TOOLCHAIN_DYNAMIC_LINK_ENABLE "Enable Dynamic Linking for Toolchain" ON)

# Configure CMake Modules #

set(CMAKE_MODULE_PATH ${CMAKE_CURRENT_LIST_DIR}/tools/cmake)

include(MacroEnsureOutOfSourceBuild)
ensure_out_of_source_build("Please do not build the C SDK inside the source 
directory.")

# Check Configuration #

if ("${CMAKE_GENERATOR}" STREQUAL "Ninja" AND DSLINK_TEST)
message(WARNING "C SDK Unit Tests are currently not supported under Ninja.")
set(DSLINK_TEST OFF)
endif()

# Define Macros #

macro(ADD_C_FLAGS flags)
set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} ${flags}")
endmacro()

# Git Version Info 

set(GIT_DIR "${CMAKE_SOURCE_DIR}/.git")
if (EXISTS "${GIT_DIR}" AND IS_DIRECTORY "${GIT_DIR}" AND NOT 
"${GIT_COMMIT_HASH}")
execute_process(
COMMAND git log -1 --format=%H
WORKING_DIRECTORY "${CMAKE_SOURCE_DIR}"
OUTPUT_VARIABLE GIT_COMMIT_HASH
OUTPUT_STRIP_TRAILING_WHITESPACE
)
endif()

# Toolchain Configuration #

ADD_C_FLAGS("${TOOLCHAIN_C_FLAGS}")

if (NOT TOOLCHAIN_DYNAMIC_LINK_ENABLE)
set(CMAKE_SHARED_LIBRARY_LINK_C_FLAG

[yocto] FW: cmake version 3.0.0 or greater

[Dinh Nguyen (dinhn)]

Hi Yocto Gurus

Our SDK has the Yocto Project 1.7 Dizzy version and it supports cmake 2.8.12 
version as show below:
./meta/recipes-devtools/cmake/cmake_2.8.12.2.bb
./meta/recipes-devtools/cmake/cmake-native_2.8.12.2.bb

We need to pulling the cmake 3.x.x version for our sdk-dslink-c recipe build.

I found  git://git.openembedded.org/openembedded-core has version  3.6.x
So I tried to pull it in. But this version got a trace back when integrated to 
our SDK Yocto Dizzy.

Can you advise which open embedded-core version/git location to pull in to SDK 
Dizzy version for cmake 3.x.x version

Thanks,
  —Dinh
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Yocto : QA issue: package qlibc-dbg contains bad RPATH

[Dinh Nguyen (dinhn)]

>> quick fix is in a do_install or do_install_append do

>> chrpath -d ${D}${libdir}/libqlibcext.so

Khem, you are the true Yocto Guru ;-)) 

Thank you. It solved my RPATH issue. 

—Dinh 






On 11/4/16, 10:46 AM, "Khem Raj" <raj.k...@gmail.com> wrote:

>On Fri, Nov 4, 2016 at 8:09 AM, Dinh Nguyen (dinhn) <di...@cisco.com> wrote:
>> Hi Yocto Gurus,
>>
>> ERROR: QA Issue: package qlibc-dbg contains bad RPATH
>
>quick fix is in a do_install or do_install_append do
>
>chrpath -d ${D}${libdir}/libqlibcext.so
>
>ideally, one should fix build system to not emit the wrong rpath in first 
>place.
>
>> /media/raghuram/data/dinhn/ioxDevLatest/ioxsdk/yp_qlibc32/tmp/work/ppce500v2-poky-linux-gnuspe/qlibc/1.0-r0/git/lib
>> in file
>> /media/raghuram/data/dinhn/ioxDevLatest/ioxsdk/yp_qlibc32/tmp/work/ppce500v2-poky-linux-gnuspe/qlibc/1.0-r0/packages-split/qlibc-dbg/usr/lib/libqlibcext.so
>> [rpaths]
>> ERROR: QA run found fatal errors. Please consider fixing them.
>>
>>
>> I am able to compile and build IPK package for qlibc recipe. But it the
>> above QA issue, which indicate package qlibc-dbg has a bad RPATH.
>> Any idea how to solve this?
>>
>> Many thanks in advance
>>   —Dinh
>>
>> --
>> ___
>> yocto mailing list
>> yocto@yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/yocto
>>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Yocto : QA issue: package qlibc-dbg contains bad RPATH

[Dinh Nguyen (dinhn)]

Hi Yocto Gurus,

ERROR: QA Issue: package qlibc-dbg contains bad RPATH 
/media/raghuram/data/dinhn/ioxDevLatest/ioxsdk/yp_qlibc32/tmp/work/ppce500v2-poky-linux-gnuspe/qlibc/1.0-r0/git/lib
 in file 
/media/raghuram/data/dinhn/ioxDevLatest/ioxsdk/yp_qlibc32/tmp/work/ppce500v2-poky-linux-gnuspe/qlibc/1.0-r0/packages-split/qlibc-dbg/usr/lib/libqlibcext.so
 [rpaths]
ERROR: QA run found fatal errors. Please consider fixing them.


I am able to compile and build IPK package for qlibc recipe. But it the above 
QA issue, which indicate package qlibc-dbg has a bad RPATH.
Any idea how to solve this?

Many thanks in advance
  —Dinh
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] LXC container: opkg_install_cmd: Cannot install package cmocka

[Dinh Nguyen (dinhn)]

Thanks — Got it.

—Dinh

From: dinhn >
Date: Wednesday, November 2, 2016 at 6:20 AM
To: "yocto@yoctoproject.org" 
>
Cc: dinhn >
Subject: LXC container: opkg_install_cmd: Cannot install package cmocka


Folks,

I am trying to bring the cmocka recipe our IOX SDK Yocto. Cmocka is a fork for 
Googles cmockery unit testing framework to fix bugs.

I am able to compile and build IPK packages for cmocka without any issue.
But during creating the LXC container which including the cmocka,  
opkg_install_cmd can install and configure other recipes  but can’t install 
package cmocka as shown below in the “red”

There is no details info on why it can’t install the package or what is the 
problem. Have anyone encountered this issue and how to solve it? Many thanks in 
advance.
…
Configuring libmodbus5.
Configuring initscripts.
Configuring libboost-graph1.56.0.
Configuring boost-serialization.
Configuring libboost-program-options1.56.0.
Configuring opkg-collateral.
Configuring boost-test.
Configuring libzlog1.2.
Configuring poky-feed-config-opkg.
Configuring libboost-filesystem1.56.0.
Configuring base-passwd.
Configuring packagegroup-core-boot.
Configuring libboost-signals1.56.0.
Configuring libz1.
Configuring libboost-iostreams1.56.0.
Configuring boost.
Configuring libjansson4.
Configuring libuv1.
Collected errors:
 * opkg_install_cmd: Cannot install package cmocka.

DEBUG: Python function do_rootfs finished
ERROR: Function failed: do_rootfs

Best,
  —Dinh
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] LXC container: opkg_install_cmd: Cannot install package cmocka

[Dinh Nguyen (dinhn)]

Folks,

I am trying to bring the cmocka recipe our IOX SDK Yocto. Cmocka is a fork for 
Googles cmockery unit testing framework to fix bugs.

I am able to compile and build IPK packages for cmocka without any issue.
But during creating the LXC container which including the cmocka,  
opkg_install_cmd can install and configure other recipes  but can’t install 
package cmocka as shown below in the “red”

There is no details info on why it can’t install the package or what is the 
problem. Have anyone encountered this issue and how to solve it? Many thanks in 
advance.
…
Configuring libmodbus5.
Configuring initscripts.
Configuring libboost-graph1.56.0.
Configuring boost-serialization.
Configuring libboost-program-options1.56.0.
Configuring opkg-collateral.
Configuring boost-test.
Configuring libzlog1.2.
Configuring poky-feed-config-opkg.
Configuring libboost-filesystem1.56.0.
Configuring base-passwd.
Configuring packagegroup-core-boot.
Configuring libboost-signals1.56.0.
Configuring libz1.
Configuring libboost-iostreams1.56.0.
Configuring boost.
Configuring libjansson4.
Configuring libuv1.
Collected errors:
 * opkg_install_cmd: Cannot install package cmocka.

DEBUG: Python function do_rootfs finished
ERROR: Function failed: do_rootfs

Best,
  —Dinh
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] recipe for cmocka

[Dinh Nguyen (dinhn)]

https://github.com/clibs/cmocka

Dear Yocto Gurus,

Want to bring it into our SDK Yocto workspace. Is there any existing recipe for 
cmocka ?

Thanks,
  —Dinh
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] qlibc lib for Yocto Dizzy question

[Dinh Nguyen (dinhn)]

Thanks much for prompt response Khem.

Yes,  qLibc is a simple library
https://github.com/wolkykim/qlibc.git

Thanks,
  —Dinh

From: Khem Raj <raj.k...@gmail.com<mailto:raj.k...@gmail.com>>
Date: Thursday, October 27, 2016 at 9:00 PM
To: dinhn <di...@cisco.com<mailto:di...@cisco.com>>
Cc: "yocto@yoctoproject.org<mailto:yocto@yoctoproject.org>" 
<yocto@yoctoproject.org<mailto:yocto@yoctoproject.org>>
Subject: Re: [yocto] qlibc lib for Yocto Dizzy question


On Oct 27, 2016, at 8:19 PM, Dinh Nguyen (dinhn) 
<di...@cisco.com<mailto:di...@cisco.com>> wrote:


Hi Yocto gurus,

I am trying to add the qlibc lib to our Yocto 1.7.2 version.
Able to compile and build IPK packages with out any issue as shown below:

dinhn@rs-bldsrv:/media/raghuram/data/dinhn/ioxDevLatest/ioxsdk/yp_ppc$ find 
tmp/deploy | grep qlibc
tmp/deploy/ipk/ppce500v2/qlibc-dbg_1.0-r0_ppce500v2.ipk
tmp/deploy/ipk/ppce500v2/qlibc-dev_1.0-r0_ppce500v2.ipk
tmp/deploy/licenses/qlibc
tmp/deploy/licenses/qlibc/generic_BSD-2-Clause
tmp/deploy/licenses/qlibc/LICENSE

However, it is not included in the rootfs.manifest for building a LXC container.
I wonder whether I am missing in my recipe qlibc.bb or how to solve this issue?

it seems that main package is empty. Is it just building a static ( .a ) 
library ?


Many thanks,
  —Dinh


--
___
yocto mailing list
yocto@yoctoproject.org<mailto:yocto@yoctoproject.org>
https://lists.yoctoproject.org/listinfo/yocto

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] qlibc lib for Yocto Dizzy question

[Dinh Nguyen (dinhn)]

Hi Yocto gurus,

I am trying to add the qlibc lib to our Yocto 1.7.2 version.
Able to compile and build IPK packages with out any issue as shown below:

dinhn@rs-bldsrv:/media/raghuram/data/dinhn/ioxDevLatest/ioxsdk/yp_ppc$ find 
tmp/deploy | grep qlibc
tmp/deploy/ipk/ppce500v2/qlibc-dbg_1.0-r0_ppce500v2.ipk
tmp/deploy/ipk/ppce500v2/qlibc-dev_1.0-r0_ppce500v2.ipk
tmp/deploy/licenses/qlibc
tmp/deploy/licenses/qlibc/generic_BSD-2-Clause
tmp/deploy/licenses/qlibc/LICENSE

However, it is not included in the rootfs.manifest for building a LXC container.
I wonder whether I am missing in my recipe qlibc.bb or how to solve this issue?

Many thanks,
  —Dinh


-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] ppc-fixplt.patch - ERROR: Function failed patch_do_path()

[Dinh Nguyen (dinhn)]

Thank you.  It works after removing the append in the meta-fsl-ppc*

Best,
  —Dinh

From: "Burton, Ross" <ross.bur...@intel.com<mailto:ross.bur...@intel.com>>
Date: Thursday, October 20, 2016 at 1:18 PM
To: dinhn <di...@cisco.com<mailto:di...@cisco.com>>
Cc: "yocto@yoctoproject.org<mailto:yocto@yoctoproject.org>" 
<yocto@yoctoproject.org<mailto:yocto@yoctoproject.org>>, "Srinivas Yedla 
(sryedla)" <srye...@cisco.com<mailto:srye...@cisco.com>>
Subject: Re: [yocto] ppc-fixplt.patch - ERROR: Function failed patch_do_path()


On 20 October 2016 at 19:41, Dinh Nguyen (dinhn) 
<di...@cisco.com<mailto:di...@cisco.com>> wrote:
I am trying to build the luajit_2.0.3.bb<http://luajit_2.0.3.bb> recipe on our 
Yocto-1.7 base.
It failed to path the ppc-fixplt.patch. Hers is my build configuration.

Looking back in history it's possible that both your BSP and meta-oe are both 
attempting to apply the same patch, so check that your BSP layer 
(meta-fsl-ppc-*) isn't bbappending it at the same time as meta-oe also shipping 
the same patch.

Ross
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] ppc-fixplt.patch - ERROR: Function failed patch_do_path()

[Dinh Nguyen (dinhn)]

Hi Yocto Gurus,

I am trying to build the luajit_2.0.3.bb recipe on our Yocto-1.7 base.
It failed to path the ppc-fixplt.patch. Hers is my build configuration.

Please give me any idea why I got HUNT # failed that ending up causing 
ppc-fixplt.patch error?

Build Configuration:
BB_VERSION= "1.24.0"
BUILD_SYS = "x86_64-linux"
NATIVELSBSTRING   = "Ubuntu-14.04"
TARGET_SYS= "powerpc-poky-linux-gnuspe"
MACHINE   = "isr800-lxc"
DISTRO= "poky"
DISTRO_VERSION= "1.7.2"
TUNE_FEATURES = "m32 spe ppce500v2"
TARGET_FPU= "ppc-efd"
meta-cisco-iox-base
meta-fsl-ppc-dizzy-12.0.2 = ":"
meta-efl
meta-filesystems
meta-xfce
meta-ruby
meta-webserver
meta-systemd
meta-python
meta-perl
meta-networking
meta-multimedia
meta-initramfs
meta-gnome
meta-oe   = "dizzy:70beecb2716bca1b9dfbc7d6a264233e1f05e82b"
meta-cisco-isr800
meta-fsl-ppc-dizzy-12.0.2
meta
meta-yocto
meta-yocto-bsp= ":"

NOTE: Preparing runqueue
NOTE: Executing SetScene Tasks
NOTE: Executing RunQueue Tasks
ERROR: Command Error: exit status: 1  Output:
Applying patch ppc-fixplt.patch
patching file src/host/buildvm.c
Hunk #1 FAILED at 107.
1 out of 1 hunk FAILED -- rejects in file src/host/buildvm.c
patching file src/vm_ppcspe.dasc
Hunk #1 FAILED at 1390.
Hunk #2 FAILED at 1405.
Hunk #3 FAILED at 1437.
Hunk #4 FAILED at 1471.
Hunk #5 FAILED at 1484.
Hunk #6 FAILED at 1503.
Hunk #7 FAILED at 2399.
7 out of 7 hunks FAILED -- rejects in file src/vm_ppcspe.dasc
Patch ppc-fixplt.patch does not apply (enforce with -f)
ERROR: Function failed: patch_do_patch
ERROR: Logfile of failure stored in: 
/media/raghuram/data/dinhn/ioxDevLatest/ioxsdk/yp_ppc/tmp/work/ppce500v2-poky-linux-gnuspe/luajit/2.0.3-r0/temp/log.do_patch.32583
ERROR: Task 1 
(/media/raghuram/data/dinhn/ioxDevLatest/ioxsdk/sys/yocto-1.7/isr800/meta-openembedded/meta-oe/recipes-devtools/luajit/luajit_2.0.3.bb,
 do_patch) failed with exit code '1'
NOTE: Tasks Summary: Attempted 369 tasks of which 366 didn't need to be rerun 
and 1 failed.
No currently running tasks (369 of 379)

Summary: 1 task failed:
  
/media/raghuram/data/dinhn/ioxDevLatest/ioxsdk/sys/yocto-1.7/isr800/meta-openembedded/meta-oe/recipes-devtools/luajit/luajit_2.0.3.bb,
 do_patch
Summary: There were 2 ERROR messages shown, returning a non-zero exit code.


-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Recipe for Turbo.lua ?

[Dinh Nguyen (dinhn)]

> I checked at layers.openembedded.org and it seems there is no recipe for this.



Thanks much Khem, I googled too, but unable to find any.

Best,
  —Dinh 

On 10/19/16, 7:53 PM, "Khem Raj" <raj.k...@gmail.com> wrote:

>On Wed, Oct 19, 2016 at 6:56 PM, Dinh Nguyen (dinhn) <di...@cisco.com> wrote:
>>
>> Hi Yocto Gurus,
>>
>> I am trying to use the Turbo Lua as a framework for building Lua JIT.
>> https://github.com/kernelsauce/turbo.git
>>
>> Is there any existing recipe for “turbo lua” ?
>
>I checked at layers.openembedded.org and it seems there is no recipe for this.
>
>>
>> Many thanks in advance,
>>   —Dinh
>>
>> --
>> ___
>> yocto mailing list
>> yocto@yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/yocto
>>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Recipe for Turbo.lua ?

[Dinh Nguyen (dinhn)]

Hi Yocto Gurus,

I am trying to use the Turbo Lua as a framework for building Lua JIT.
https://github.com/kernelsauce/turbo.git

Is there any existing recipe for “turbo lua” ?

Many thanks in advance,
  —Dinh
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Cross platform compiling/build issue: "Yocto - QA Issue: Architecture did not match (20 to 62) "

[Dinh Nguyen (dinhn)]

Hi folks,

I am trying to have cross platform build with  Yocto/IOX SDK for our c-mlib 
lib. I am able to compile and build IPK packages and LXC container for x86 
target.

Using the same c-mlib.bb recipe, trying to cross compiling and build for a PPC 
32-bit target  on my 64-bit build environment.
Here is the build  configuration

Build Configuration:
BB_VERSION= "1.24.0"
BUILD_SYS = "x86_64-linux"
NATIVELSBSTRING   = "Ubuntu-14.04"
TARGET_SYS= "powerpc-poky-linux-gnuspe"
MACHINE   = "isr800-lxc"
DISTRO= "poky"
DISTRO_VERSION= "1.7.2"
TUNE_FEATURES = "m32 spe ppce500v2"
TARGET_FPU= "ppc-efd"
meta-cisco-iox-base
meta-cisco-isr800
meta-fsl-ppc-dizzy-12.0.2
meta
meta-yocto

And having the following error:
ERROR: QA Issue: Architecture did not match (20 to 62) on 
/work/ppce500v2-poky-linux-gnuspe/c-mlib/1.1-r0/packages-split/c-mlib/usr/bin/xxx
  [arch]
ERROR: QA run found fatal errors. Please consider fixing them.
ERROR: Function failed: do_package_qa

Question is:
How to solve  a cross compiling/build for a PPC 32-bit object on a 64 bit linux 
environment?
Many thanks in advance,
—Dinh

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

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

[Dinh Nguyen (dinhn)]

>> 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) <di...@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@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@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@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.k...@gmail.com> wrote:
>> 
>>> 
>>>> On Oct 5, 2016, at 11:18 AM, Dinh Nguyen (dinhn) <di...@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" <lsore...@csclub.uwaterloo.ca> 
>>>> wrote:
>>>> 
>>>>> On Wed, Oct 05, 2016 at 04:06:25PM +, 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@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 
>>>>>> 

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

[Dinh Nguyen (dinhn)]

>> 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.



dinhn@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@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@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.k...@gmail.com> wrote:

>
>> On Oct 5, 2016, at 11:18 AM, Dinh Nguyen (dinhn) <di...@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" <lsore...@csclub.uwaterloo.ca> wrote:
>> 
>>> On Wed, Oct 05, 2016 at 04:06:25PM +, 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@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@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

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

[Dinh Nguyen (dinhn)]

>> 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.

Thanks,
  —Dinh 




On 10/5/16, 9:30 AM, "Lennart Sorensen" <lsore...@csclub.uwaterloo.ca> wrote:

>On Wed, Oct 05, 2016 at 04:06:25PM +, 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@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@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@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@rs-bldsrv:/media/raghuram/data/dinhn/ioxDevLatest/ioxsdk/yp$ 
>> 
>> C. Image was built as well including binaries and libmlib.so
>> dinhn@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@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@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@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@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@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

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

[Dinh Nguyen (dinhn)]

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@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.k...@gmail.com> wrote:

>On Wed, Oct 5, 2016 at 9:06 AM, Dinh Nguyen (dinhn) <di...@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@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@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@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@rs-bldsrv:/media/raghuram/data/dinhn/ioxDevLatest/ioxsdk/yp$
>>
>> C. Image was built as well including binaries and libmlib.so
>> dinhn@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@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@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 

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

[Dinh Nguyen (dinhn)]

>> Is that doing a compile in the install target?


Yes Len. Compile was done and there is no issue there.

Thanks,
  —Dinh 





On 10/5/16, 9:28 AM, "Lennart Sorensen" <lsore...@csclub.uwaterloo.ca> wrote:

>On Wed, Oct 05, 2016 at 04:10:01PM +, Dinh Nguyen (dinhn) wrote:
>> >>> I wonder why do we want to override default PACKAGES here. If we can 
>> >>> leave that alone things would work out on its own.
>> 
>> I did remove the PACKAGES setting in my .bb — so all default packages were 
>> built. But still having some other issue as stated in other emails.
>> 
>> Thanks Khem.
>>   —Dinh
>> 
>> 
>> 
>> On 10/5/16, 8:34 AM, "Khem Raj" <raj.k...@gmail.com> wrote:
>> 
>> >I wonder why do we want to override default PACKAGES here. If we can leave
>> >that alone things would work out on its own.
>> >
>> >On Tue, Oct 4, 2016 at 11:55 PM, Paul Eggleton
>> ><paul.eggle...@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
>
>Is that doing a compile in the install target?
>
>-- 
>Len Sorensen
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

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

[Dinh Nguyen (dinhn)]

>>> I wonder why do we want to override default PACKAGES here. If we can leave 
>>> that alone things would work out on its own.

I did remove the PACKAGES setting in my .bb — so all default packages were 
built. But still having some other issue as stated in other emails.

Thanks Khem.
  —Dinh



On 10/5/16, 8:34 AM, "Khem Raj"  wrote:

>I wonder why do we want to override default PACKAGES here. If we can leave
>that alone things would work out on its own.
>
>On Tue, Oct 4, 2016 at 11:55 PM, Paul Eggleton
> 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@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@yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/yocto
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

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

[Dinh Nguyen (dinhn)]

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@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@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@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@rs-bldsrv:/media/raghuram/data/dinhn/ioxDevLatest/ioxsdk/yp$ 

C. Image was built as well including binaries and libmlib.so
dinhn@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@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@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@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@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 ;-))

Best,
  —Dinh 





On 10/4/16, 11:55 PM, "Paul Eggleton"  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 \

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

[Dinh Nguyen (dinhn)]

Thank you Len. 

If I specified PACKAGES = “${PN}” as mentioned early, it only built the main 
package.
As you suggested, I removed that line from my c-mlib.bb, it then built the 
main, -dev and -dbg packages as specified in the bitbake.conf - thanks you...

dinhn@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



But running into the other issue, which I replied to Paul’s email few minutes 
ago. Please take a look if you have time. Thx

Thanks again Len.
  —Dinh




On 10/4/16, 2:55 PM, "Lennart Sorensen" <lsore...@csclub.uwaterloo.ca> wrote:

>On Tue, Oct 04, 2016 at 07:47:58PM +, Dinh Nguyen (dinhn) wrote:
>> 
>> Hi Paul, thanks much for prompt response. 
>> 
>> The c-mlib.bb below has the packages var as
>> PACKAGES =+ "${PN}” I also tried PACKAGES = "${PN}” 
>
>Don't do that.
>
>In bitbake.conf you have:
>
>PACKAGES = "${PN}-dbg ${PN}-staticdev ${PN}-dev ${PN}-doc ${PN}-locale 
>${PACKAGE_BEFORE_PN} ${PN}"
>
>So all those package names are implied and always exist.  Don't try to
>add them yourself.
>
>Only do anything with PACKAGES if you want to add any other package
>names or totally override the list of packages (in which case you have
>to use PACKAGES = of course)
>
>For example base-files does override the list completely, as does glibc
>and a few other ones, but most only add to it.
>
>-- 
>Len Sorensen
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

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

[Dinh Nguyen (dinhn)]

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@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
….


Please let me know whether I should start the new email thread instead? Thanks
  —Dinh







On 10/4/16, 12:59 PM, "Paul Eggleton"  wrote:

>On Tue, 04 Oct 2016 19:47:58 Dinh Nguyen wrote:
>> The c-mlib.bb below has the packages var as
>> PACKAGES =+ "${PN}” I also tried PACKAGES = "${PN}” 
>
>PACKAGES = "${PN}" should work (or use bitbake -e recipename | less, search 
>for ^PACKAGES= (with /) and look through the history to see why not).
>
>However, if you do make that work I suspect you'll probably hit other 
>warnings/errors due to unpackaged files or other issues. I guess you are 
>trying to work around the fact that you have a non-symlink .so file that you 
>want to get into the main ${PN} package, is that correct?
>
>Cheers,
>Paul 
>
>-- 
>
>Paul Eggleton
>Intel Open Source Technology Centre
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

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

[Dinh Nguyen (dinhn)]

Hi Paul, thanks much for prompt response. 

The c-mlib.bb below has the packages var as
PACKAGES =+ "${PN}” I also tried PACKAGES = "${PN}” 


The packages were built successful indeed, but the ERROR: QA Issue ...
Any recommendation to change the above PACKAGES variable in the bb?

SUMMARY = "c-mlib cross build environment with IOx SDK"
DESCRIPTION = "c-mlib cross build environment with IOx SDK "
#DEPENDS = "libsdk_dslink_c-static libjansson liblibuv libzlog"
#DEPENDS = "util-linux"
DEPENDS = ""
PROVIDES = ""

#LICENSE = ""
LICENSE = "CLOSED"
SRC_URI = "git://gitlab.cisco.com/ghalwasi/c-mlib.git;protocol=http"
SRCREV = "${AUTOREV}"

SRC_URI[md5sum] = "e896bcd267b3cc1de89b3ac85ee2f28b"
SRC_URI[sha256sum] = 
"7b7be67bcf090dcf9b939cba9705771b9c0503c4b367f7b60af968dc27ec541d"

S = "${WORKDIR}/git"
PV = "1.0.0"

do_install () {
oe_runmake all
install -d  ${D}${libdir}
install -m 0644 ${S}/target/* ${D}${libdir}
}

PACKAGES =+ "${PN}"

FILES_${PN} = "/usr/lib/datamodel_cache \
/usr/lib/invoke \
/usr/lib/invoke_b \
/usr/lib/libmlib.so \
/usr/lib/protocol_infra \
/usr/lib/publisher \
/usr/lib/rpc-register \
/usr/lib/service \
/usr/lib/subscriber \
/usr/lib/test-service \
/usr/lib/properties.json”





Many thanks,
  —Dinh 

On 10/4/16, 12:22 PM, "Paul Eggleton"  wrote:

>Hi Dinh,
>
>On Tue, 04 Oct 2016 16:07:59 Dinh Nguyen wrote:
>> >>> ERROR: QA Issue: c-mlib is listed in PACKAGES multiple times, this leads
>> >>> to packaging errors. [packages-list]
>> Summary: There was 1 ERROR
>> >>> message shown, returning a non-zero exit code.
>> 
>> I got the above ERROR because  my c-mlib_1.0-r0_core2-64.ipk and other
>> packages were listed in different places as shown below:
> 
>> dinhn@rs-bldsrv:/media/raghuram/data/dinhn/ioxDev/ioxsdk$ find . -name
>> c-mlib_1.0-r0_core2-64.ipk
> 
>> ./yp/tmp/deploy/ipk/core2-64/c-mlib_1.0-r0_core2-64.ipk
>> ./yp/tmp/work/core2-64-poky-linux/c-mlib/1.0-r0/deploy-ipks/core2-64/c-mlib_
>> 1.0-r0_core2-64.ipk
>
>That is not what that error means. What it does mean is that there is a
>variable called PACKAGES which is used to control the list of packages
>produced by a recipe, and in the value of that variable for the c-mlib recipe,
>a c-mlib package is listed more than once. You need to look at what you are 
>doing in the
>recipe with the PACKAGES variable and fix it so that that does not occur.
>
>FYI for future reference there's a useful section of the manual describing
>warnings and what to do about them:
>
>  
> http://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#qa-errors-and-warnings
>
>Cheers,
>Paul
>
>-- 
>
>Paul Eggleton
>Intel Open Source Technology Centre
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

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

[Dinh Nguyen (dinhn)]

Hi folks,

>>> ERROR: QA Issue: c-mlib is listed in PACKAGES multiple times, this leads to 
>>> packaging errors. [packages-list]
>>> Summary: There was 1 ERROR message shown, returning a non-zero exit code.

I got the above ERROR because  my c-mlib_1.0-r0_core2-64.ipk and other packages 
were listed in different places as shown below:

dinhn@rs-bldsrv:/media/raghuram/data/dinhn/ioxDev/ioxsdk$ find . -name 
c-mlib_1.0-r0_core2-64.ipk

./yp/tmp/deploy/ipk/core2-64/c-mlib_1.0-r0_core2-64.ipk
./yp/tmp/work/core2-64-poky-linux/c-mlib/1.0-r0/deploy-ipks/core2-64/c-mlib_1.0-r0_core2-64.ipk

Is this an error?

Many thanks,
  —D
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto