[yocto] devtool sdk-update question

[Jaewon Lee]

Hi,

I have a question on devtool sdk-update.
We have a requirement that our esdk is extracted in publish mode as it's on an 
nfs mountpoint and bitbake doesnt like nfs.
There used to be two ways to update sstate,
(1)through the install_sstate_objects function which manually copies sstate 
objects (for local updates) and
(2) setting SOURCE_MIRROR in site.conf to the updateserver and running bitbake 
setscene (for remote updates),  after this patch 
https://gitenterprise.xilinx.com/Yocto/poky/commit/02986886fc40c0fcd33359a279ba9520fd5cac2a
the former is no longer supported.

What would be the best way for us to update sstate through sdk-update now? as 
we can't do use bitbake setscene.. seems this is a gap?
Any thoughts here would be appreciated

Thanks,
Jaewon


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

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

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

[Khem Raj]

On Thu, Feb 14, 2019 at 3:47 PM Dinh Nguyen (dinhn)  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] Toolchain , kernel-dev and xenomai

[Khem Raj]

On Wed, Feb 13, 2019 at 2:43 AM Johann Obermayr
 wrote:
>
> Hello,
>
>
>
> At this time we work with 1.3.2 (yes, it’s very old, but we are working to 
> change to v2.5.x)
>
>
>
> We have some trouble with your toolchain.
>
> Kernel/scripts/basic/fixdep   is missing.
>

this looks more like a kernel build error. Which version of kernel are you on?

> If I will compile in the toolchain kernel source directory “make scripts” I 
> get some other errors (see b) )
>
>
>
>b) Xenomai integrates its files as linked. And this links are 
> installed with the toolchain. So the files are not really available.
>
>
>
>
>
> Thanks & Regards
>
>   Johann
>
>
>
> --
> ___
> 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] icecast

[Max Krummenacher]

Hi

Have a look here:
http://www.toradex.com/community/answers/33369/view.html

Max
Am Donnerstag, den 14.02.2019, 12:35 -0800 schrieb Chuck Wolber:
> You have to refactor xslt-config out of the autotools macros and use
> pkg-config instead.
> 
> This recipe is an example:
> 
> meta/recipes-devtools/swig/swig/0001-configure-use-pkg-config
> -for-pcre-detection.patch
> 
> ..Ch:W..
> 
> On Thu, Feb 14, 2019 at 05:57 Leonardo Jose Duarte MendesJunior <
> leodmende...@gmail.com> wrote:
> 
> > I'm trying to compile the package icecast. The package icecast is old. The
> > package depends on xslt.
> > When I compile this package, I had the issue with xslt.
> > How to use pkgconfig if the own source code use him ?
> > --
> > ___
> > 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] npm recipe bad task order

[Jonas Andersson]

My recipe is as following, i have striped down some checksum files and
licenses for packages:
___
SUMMARY = "microServiceBus-node is the node.js based device agent used
together with microServiceBus.com."

DESCRIPTION =  "microServiceBus.com is an integration platform for IoT and
enterprise applications. \
This platform lets you expose microservices from small
devices and large systems using a remote hosting infrastructure. \
These nodes can run on both Linux and Windows using
components built either natively (ARM) or using node.js."

HOMEPAGE = "https://microservicebus.com";

LICENSE = "BSD-3-Clause & Unlicense & Apache-2.0 & \
BSD-2-Clause & ISC & MIT"
LIC_FILES_CHKSUM = "file://LICENSE;md5=75dbbb2f49d90bfc476532dc5861fd26 \

file://node_modules/inherits/LICENSE;md5=5b2ef2247af6d355ae9d9f988092d470 \

file://node_modules/psl/LICENSE;md5=2425d288296fae32e27553694ff40294 \

file://node_modules/rc/LICENSE.MIT;md5=e0f70a42adf526e6f5e605a94d98a420"

SRC_URI = "npm://registry.npmjs.org;name=microservicebus-node;version=${PV}"

NPM_SHRINKWRAP := "${THISDIR}/${PN}/npm-shrinkwrap.json"
NPM_LOCKDOWN := "${THISDIR}/${PN}/lockdown.json"

inherit npm

# Must be set after inherit npm since that itself sets S
S = "${WORKDIR}/npmpkg"
LICENSE_${PN}-app-module-path = "BSD-2-Clause"
LICENSE_${PN}-async-lodash = "MIT"

RDEPENDS_${PN} += " python nodejs-npm"
___

The recipe have worked for some version of sumo, I have tested 2.5.1 with
the same result, the only other thing that I have added is som generic
licenses in the layer:

# Additional license directories.
LICENSE_PATH += "${LAYERDIR}/files/common-licenses"
SPDXLICENSEMAP[Unlicensev1] = "Unlicense"
SPDXLICENSEMAP[WTFPLv1] = "WTFPL"
_

/Jonas

Den tors 14 feb. 2019 kl 21:38 skrev Chuck Wolber :

> Normally the source archive is unpacked first, which contains the license
> file. Is there something different with the source packaging for your
> recipe?
>
> ..Ch:W..
>
> On Thu, Feb 14, 2019 at 02:26 Jonas Andersson 
> wrote:
>
>> Hi,
>>
>> I have some recipes created from npm packages with devtool.
>>
>> do_populate_lic with: WARNING: Could not copy license file
>> and LIC_FILES_CHKSUM points to an invalid file.
>>
>> In my understanding the problem is that do_populate_lic task is running
>> before do_compile:
>>
>> log.task_order
>> ___
>> do_cleansstate (20550): log.do_cleansstate.20550
>> do_cleanall (20551): log.do_cleanall.20551
>> do_fetch (20653): log.do_fetch.20653
>> do_unpack (22861): log.do_unpack.22861
>> do_prepare_recipe_sysroot (22862): log.do_prepare_recipe_sysroot.22862
>> do_patch (23281): log.do_patch.23281
>> do_configure (23283): log.do_configure.23283
>> do_populate_lic (23284): log.do_populate_lic.23284
>> do_compile (23289): log.do_compile.23289
>> ___
>>
>> The recipes npm created with devtool reference license to S
>> (${WORKDIR}/npmpkg):
>>
>> __
>> LIC_FILES_CHKSUM = "file://LICENSE;md5=75dbbb2f49d90bfc476532dc5861fd26 \
>>
>> file://node_modules/inherits/LICENSE;md5=5b2ef2247af6d355ae9d9f988092d470 \
>>
>> file://node_modules/psl/LICENSE;md5=2425d288296fae32e27553694ff40294 \
>>
>> file://node_modules/rc/LICENSE.MIT;md5=e0f70a42adf526e6f5e605a94d98a420"
>>
>> __
>>
>> But as npm_do_compile is the task that populates workdir there is no
>> license files available when do_populate_lic runs.
>>
>> I have tried both sumo and thud but with the same result, is the order
>> something that have change?
>>
>> Best regards
>> Jonas
>>
>> --
>> ___
>> yocto mailing list
>> yocto@yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/yocto
>>
> --
> “I would challenge anyone here to think of a question upon which we once
> had a scientific answer, however inadequate, but for which now the best
> answer is a religious one."  -Sam Harris
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Two recipes install the same file

[Burton, Ross]

On Thu, 14 Feb 2019 at 20:29, Chuck Wolber  wrote:
> I have run across this a few times, particularly with man pages, when 
> including upstream packages into my images.
>
> I have to use a bbappend recipe in my meta layer to remove the lower priority 
> version.

If you've two manpages with the same name that suggests that there are
two binaries with the same name, which presumably are already using
update-alternatives.  The correct fix here is to use
update-alternatives for the manpage too.

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

Re: [yocto] npm recipe bad task order

[Chuck Wolber]

Normally the source archive is unpacked first, which contains the license
file. Is there something different with the source packaging for your
recipe?

..Ch:W..

On Thu, Feb 14, 2019 at 02:26 Jonas Andersson 
wrote:

> Hi,
>
> I have some recipes created from npm packages with devtool.
>
> do_populate_lic with: WARNING: Could not copy license file
> and LIC_FILES_CHKSUM points to an invalid file.
>
> In my understanding the problem is that do_populate_lic task is running
> before do_compile:
>
> log.task_order
> ___
> do_cleansstate (20550): log.do_cleansstate.20550
> do_cleanall (20551): log.do_cleanall.20551
> do_fetch (20653): log.do_fetch.20653
> do_unpack (22861): log.do_unpack.22861
> do_prepare_recipe_sysroot (22862): log.do_prepare_recipe_sysroot.22862
> do_patch (23281): log.do_patch.23281
> do_configure (23283): log.do_configure.23283
> do_populate_lic (23284): log.do_populate_lic.23284
> do_compile (23289): log.do_compile.23289
> ___
>
> The recipes npm created with devtool reference license to S
> (${WORKDIR}/npmpkg):
>
> __
> LIC_FILES_CHKSUM = "file://LICENSE;md5=75dbbb2f49d90bfc476532dc5861fd26 \
>
> file://node_modules/inherits/LICENSE;md5=5b2ef2247af6d355ae9d9f988092d470 \
>
> file://node_modules/psl/LICENSE;md5=2425d288296fae32e27553694ff40294 \
>
> file://node_modules/rc/LICENSE.MIT;md5=e0f70a42adf526e6f5e605a94d98a420"
>
> __
>
> But as npm_do_compile is the task that populates workdir there is no
> license files available when do_populate_lic runs.
>
> I have tried both sumo and thud but with the same result, is the order
> something that have change?
>
> Best regards
> Jonas
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
-- 
“I would challenge anyone here to think of a question upon which we once
had a scientific answer, however inadequate, but for which now the best
answer is a religious one."  -Sam Harris
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] icecast

[Chuck Wolber]

You have to refactor xslt-config out of the autotools macros and use
pkg-config instead.

This recipe is an example:

meta/recipes-devtools/swig/swig/0001-configure-use-pkg-config
-for-pcre-detection.patch

..Ch:W..

On Thu, Feb 14, 2019 at 05:57 Leonardo Jose Duarte MendesJunior <
leodmende...@gmail.com> wrote:

> I'm trying to compile the package icecast. The package icecast is old. The
> package depends on xslt.
> When I compile this package, I had the issue with xslt.
> How to use pkgconfig if the own source code use him ?
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
-- 
“I would challenge anyone here to think of a question upon which we once
had a scientific answer, however inadequate, but for which now the best
answer is a religious one."  -Sam Harris
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Two recipes install the same file

[Chuck Wolber]

I have run across this a few times, particularly with man pages, when
including upstream packages into my images.

I have to use a bbappend recipe in my meta layer to remove the lower
priority version.

I quite like the feature because it ensures that all collisions are known
and dealt with in a clear and formal way.

..Ch:W..

On Thu, Feb 14, 2019 at 08:55 Burton, Ross  wrote:

> Two packages can't install the same file.  In this case I suspect
> you'll need to split up the packaging further.  A common alternative
> for binaries in /bin which want to be installed by both e.g. coreutils
> and busybox is to use update-alternatives.
>
> Ross
>
> On Thu, 14 Feb 2019 at 16:36, madoga  wrote:
> >
> > Hello everyone,
> >
> > I have an issue while I'm trying to overwrite some files that two
> recipes are installing. Task do_rootfs fails and I want to ask about the
> best way to solve this:
> >
> > -
> > Error: Transaction check error:
> >   file /app/econfig.xml conflicts between attempted installs of
> tests-1.0-r0 and error-1.0-r0
> >   file /app/controller.xml conflicts between attempted installs of
> tests-1.0-r0 and controller-1.0-r0
> >   file /app/user_mode.xml conflicts between attempted installs of
> mode-1.0-r0 and tests-1.0-r0
> > Error Summary
> > -
> >  When I launch bitbake with a concrete image this error appears and I
> don't know how I can give "priority" to a recipe. I have found something
> about create .bbappend file...
> >
> > Thank you,
> > Mario
> >
> >
> >
> >
> > --
> > ___
> > yocto mailing list
> > yocto@yoctoproject.org
> > https://lists.yoctoproject.org/listinfo/yocto
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
-- 
“I would challenge anyone here to think of a question upon which we once
had a scientific answer, however inadequate, but for which now the best
answer is a religious one."  -Sam Harris
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Using SDK/ESDK to build images

[Paul Eggleton]

Hi Kristupas,

On Wednesday, 13 February 2019 12:55:57 AM NZDT Kristupas Savickas wrote:
> we're looking into providing our customers with SDK/ESDK packages to 
> develop custom solutions on our boards. We don't want to provide the 
> whole project itself as it would leak our intellectual property, so 
> precompiled packages are a must. Looking around, it seems like both SDK 
> and ESDK are suited to build single packages, rather than complete 
> images. Am I correct about this? Is there some kind of method to allow 
> images be built using SDK packages?

The eSDK can build images, yes, via "devtool build-image". You won't get the 
same ability to customise the OS as with the full build system (unless you 
start editing the software contents or modifying the configuration, which 
isn't really supported) - the purpose is really to allow building an image to 
test one or more components that you're developing with the SDK.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre


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

[yocto] Toolchain , kernel-dev and xenomai

[Johann Obermayr]

Hello,

At this time we work with 1.3.2 (yes, it's very old, but we are working to 
change to v2.5.x)

We have some trouble with your toolchain.

  1.  Kernel/scripts/basic/fixdep   is missing.

If I will compile in the toolchain kernel source directory "make scripts" I get 
some other errors (see b) )


   b) Xenomai integrates its files as linked. And this links are installed 
with the toolchain. So the files are not really available.


Thanks & Regards
  Johann
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Managing multiple builds

[Timothy Froehlich]

Thank you, that looks like a very good idea.

On Thu, Feb 14, 2019 at 8:28 AM Ulf Samuelsson  wrote:

> Den 2019-02-14 kl. 10:00, skrev Alexander Kanavin:
> > On Thu, 14 Feb 2019 at 01:35, Timothy Froehlich 
> wrote:
> >> Hi, I've been struggling a bit with this question. I want to use Yocto
> to build two+ products with separate dev/prod images for each (dev
> including debug-tweaks, etc.). I've ruled out separate image recipes
> because my dev builds need ENABLE_UART on my RaspberryPi and that needs to
> be set at the conf level (I've got it set conditionally in my base dist
> conf). Multiconfig looked promising, but I'm not happy about how long the
> parsing takes to start a build. "--postread" looked nice, but I've barely
> seen it mentioned so I'm worried that it's not well supported.
> >>
> >
> > Which recipes use the ENABLE_UART setting? You might want to write two
> > variants of those, and include them into images accordingly.
> >
> > Alex
> >
>
> Some guys I know solved the problem a little bit differently, and they
> did not mind to share.
> I created a meta-layer with that and some other ideas.
>
> * https://github.com/emagii/meta-map-sheriffco
>
> An example recipe is:
> ==
> SUMMARY = ""
> DESCRIPTION = ""
>
> inherit license-mit
>
> SRC_URI = " \
> file://class/class-recipe.c \
> file://class/Makefile \
> "
>
> EXTRA_OEMAKE_class-development = 'CFLAGS="${CFLAGS} -DDEVELOPMENT"'
> EXTRA_OEMAKE_class-production  = 'CFLAGS="${CFLAGS} -DPRODUCTION"'
> EXTRA_OEMAKE_class-release = 'CFLAGS="${CFLAGS} -DRELEASE"'
>
> do_install-class-development () {
> install -d  ${D}${bindir}
> install -m 0755 class   ${D}${bindir}/development
> }
>
> do_install-class-production () {
> install -d  ${D}${bindir}
> install -m 0755 class   ${D}${bindir}/production
> }
>
> do_install-class-release () {
> install -d  ${D}${bindir}
> install -m 0755 class   ${D}${bindir}/release
> }
>
> BBCLASSEXTEND = "development production release"
> ==
> You now have the same recipe which builds four package variants.
>
> ,
> -development,
> -production,
> -release,
>
> The base package is not included in any image.
> In the development image, you install the -development and so on.
> ==
> Three bbclasses are used, one for each special package.
>
> Here is the development.bbclass
> ==
> # Class for use in BBCLASSEXTEND to make it easier to have a single
> recipe that
> # build and generate packages separately for development and normal images.
> #
> # Usage:
> # BBCLASSEXTEND = "development"
>
> CLASSOVERRIDE .= ":class-development"
>
> python development_virtclass_handler () {
>  # Do nothing if this is inherited, as it's for BBCLASSEXTEND
>  if "development" not in (d.getVar('BBCLASSEXTEND') or ""):
>  bb.error("Don't inherit development, use BBCLASSEXTEND")
>  return
>
>  # Restore BPN
>  bpn = d.getVar('BPN')
>  newbpn = bpn.replace('-development', '')
>  d.setVar('BPN', newbpn)
>
>  # Use default FILESPATH searching for patches and files
>  filespath = d.getVar('FILESPATH')
>  newfilespath = filespath.replace('-development', '')
>  d.setVar('FILESPATH', newfilespath)
> }
>
> addhandler development_virtclass_handler
> development_virtclass_handler[eventmask] = "bb.event.RecipePreFinalise"
>
> ==
>
> --
> Best Regards
> Ulf Samuelsson
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>


-- 
Tim Froehlich
Embedded Linux Engineer
tfroehl...@archsys.io
215-218-8955
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Managing multiple builds

[Timothy Froehlich]

I'm considering that. It's the kernel build (cmdline) and the image build
(RaspberryPi, the config.txt) recipes from the meta-raspberrypi layer.
Setting it in a distro.conf, gated behind a "DEVBUILD=1/0" flag should
work, I think.

Also, please see my response to Mike Looijmans's reply.

On Thu, Feb 14, 2019 at 1:00 AM Alexander Kanavin 
wrote:

> On Thu, 14 Feb 2019 at 01:35, Timothy Froehlich 
> wrote:
> > Hi, I've been struggling a bit with this question. I want to use Yocto
> to build two+ products with separate dev/prod images for each (dev
> including debug-tweaks, etc.). I've ruled out separate image recipes
> because my dev builds need ENABLE_UART on my RaspberryPi and that needs to
> be set at the conf level (I've got it set conditionally in my base dist
> conf). Multiconfig looked promising, but I'm not happy about how long the
> parsing takes to start a build. "--postread" looked nice, but I've barely
> seen it mentioned so I'm worried that it's not well supported.
> >
>
> Which recipes use the ENABLE_UART setting? You might want to write two
> variants of those, and include them into images accordingly.
>
> Alex
>


-- 
Tim Froehlich
Embedded Linux Engineer
tfroehl...@archsys.io
215-218-8955
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Managing multiple builds

[Timothy Froehlich]

It'll be multiple software loads (with different required kernel modules
and things like) over at least two machines. These products will do very
different things but I want to use the same base and take advantage of OE's
sstate, etc.

So I want to be clear, I can figure out how to piece things together with
bash scripts to accomplish what I want, but I feel like there's a "correct"
way to manage multiple builds (that use different distros, machines,
environment variables) that I'm missing. (And perhaps I've already stumbled
on the "correct way" but it's not as elegant as I'd like so I'm not happy
with it yet.) Problem number one is that the build directory doesn't seem
to be something that is intended to be source controlled. I found the
TEMPLATECONF flag last night so that answers my question of how to source
control my sstate mirror locations and etc. I can write instructions that
are basically "git pull poky, git pull the layers, 'TEMPLATECONF=... source
oe_init_build_env', bitbake add_layers" But then what if you want to build
product a or product b?

I think what I may have just settled on is to make sure I've got my distros
set up correctly (one distro per product) and add in my own DEVBUILD flag
to my template local.conf.sample which will do things like turning on
debug_tweaks, ENABLE_UART and adding dropbear/etc. And that'll let me just
configure things by setting DISTRO, MACHINE and DEVBUILD=1/0. I'm ruling
out multiconf. I don't want my builds to take five minutes before I find
out that I have a typo in a recipe and I can get the same behavior by just
controlling the above. I'll probably set the tmpdir to something like
"tmp_DISTRO_MACHINE" to avoid different configs stepping on each other.

Does this seem like the proper way to do things?



On Wed, Feb 13, 2019 at 11:18 PM Mike Looijmans 
wrote:

> Two products sounds like two machines. Just create a machine.conf for each
> product (even if they use similar hardware), then you don't need overrides
> elsewhere.
>
> OE/Yocto is smart enough to figure out what needs to be (re)built. Some OE
> projects build the same image(s) for over 40 machines (and counting)...
>
> On 14-02-19 01:34, Timothy Froehlich wrote:
> >
> > Hi, I've been struggling a bit with this question. I want to use Yocto
> to
> > build two+ products with separate dev/prod images for each (dev
> including
> > debug-tweaks, etc.). I've ruled out separate image recipes because my
> dev
> > builds need ENABLE_UART on my RaspberryPi and that needs to be set at
> the conf
> > level (I've got it set conditionally in my base dist conf). Multiconfig
> looked
> > promising, but I'm not happy about how long the parsing takes to start a
> > build. "--postread" looked nice, but I've barely seen it mentioned so
> I'm
> > worried that it's not well supported.
> >
> > Basically, what do most people do for controlling their builds?
> > Tim Froehlich
> > Embedded Linux Engineer
> > tfroehl...@archsys.io 
> > 215-218-8955
> >
>
>

-- 
Tim Froehlich
Embedded Linux Engineer
tfroehl...@archsys.io
215-218-8955
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Two recipes install the same file

[Burton, Ross]

Two packages can't install the same file.  In this case I suspect
you'll need to split up the packaging further.  A common alternative
for binaries in /bin which want to be installed by both e.g. coreutils
and busybox is to use update-alternatives.

Ross

On Thu, 14 Feb 2019 at 16:36, madoga  wrote:
>
> Hello everyone,
>
> I have an issue while I'm trying to overwrite some files that two recipes are 
> installing. Task do_rootfs fails and I want to ask about the best way to 
> solve this:
>
> -
> Error: Transaction check error:
>   file /app/econfig.xml conflicts between attempted installs of tests-1.0-r0 
> and error-1.0-r0
>   file /app/controller.xml conflicts between attempted installs of 
> tests-1.0-r0 and controller-1.0-r0
>   file /app/user_mode.xml conflicts between attempted installs of mode-1.0-r0 
> and tests-1.0-r0
> Error Summary
> -
>  When I launch bitbake with a concrete image this error appears and I don't 
> know how I can give "priority" to a recipe. I have found something about 
> create .bbappend file...
>
> Thank you,
> Mario
>
>
>
>
> --
> ___
> 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] Two recipes install the same file

[madoga]

Hello everyone,

I have an issue while I'm trying to overwrite some files that two recipes are 
installing. Task do_rootfs fails and I want to ask about the best way to solve 
this:

-
Error: Transaction check error:

  file /app/econfig.xml conflicts between attempted installs of tests-1.0-r0 
and error-1.0-r0

  file /app/controller.xml conflicts between attempted installs of tests-1.0-r0 
and controller-1.0-r0

  file /app/user_mode.xml conflicts between attempted installs of mode-1.0-r0 
and tests-1.0-r0

Error Summary
-
 When I launch bitbake with a concrete image this error appears and I don't 
know how I can give "priority" to a recipe. I have found something about create 
.bbappend file...

Thank you,
Mario-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Managing multiple builds

[Ulf Samuelsson]

Den 2019-02-14 kl. 10:00, skrev Alexander Kanavin:

On Thu, 14 Feb 2019 at 01:35, Timothy Froehlich  wrote:

Hi, I've been struggling a bit with this question. I want to use Yocto to build two+ 
products with separate dev/prod images for each (dev including debug-tweaks, etc.). I've 
ruled out separate image recipes because my dev builds need ENABLE_UART on my RaspberryPi 
and that needs to be set at the conf level (I've got it set conditionally in my base dist 
conf). Multiconfig looked promising, but I'm not happy about how long the parsing takes 
to start a build. "--postread" looked nice, but I've barely seen it mentioned 
so I'm worried that it's not well supported.



Which recipes use the ENABLE_UART setting? You might want to write two
variants of those, and include them into images accordingly.

Alex



Some guys I know solved the problem a little bit differently, and they 
did not mind to share.

I created a meta-layer with that and some other ideas.

* https://github.com/emagii/meta-map-sheriffco

An example recipe is:
==
SUMMARY = ""
DESCRIPTION = ""

inherit license-mit

SRC_URI = " \
file://class/class-recipe.c \
file://class/Makefile \
"

EXTRA_OEMAKE_class-development = 'CFLAGS="${CFLAGS} -DDEVELOPMENT"'
EXTRA_OEMAKE_class-production  = 'CFLAGS="${CFLAGS} -DPRODUCTION"'
EXTRA_OEMAKE_class-release = 'CFLAGS="${CFLAGS} -DRELEASE"'

do_install-class-development () {
install -d  ${D}${bindir}
install -m 0755 class   ${D}${bindir}/development
}

do_install-class-production () {
install -d  ${D}${bindir}
install -m 0755 class   ${D}${bindir}/production
}

do_install-class-release () {
install -d  ${D}${bindir}
install -m 0755 class   ${D}${bindir}/release
}

BBCLASSEXTEND = "development production release"
==
You now have the same recipe which builds four package variants.

,
-development,
-production,
-release,

The base package is not included in any image.
In the development image, you install the -development and so on.
==
Three bbclasses are used, one for each special package.

Here is the development.bbclass
==
# Class for use in BBCLASSEXTEND to make it easier to have a single 
recipe that

# build and generate packages separately for development and normal images.
#
# Usage:
# BBCLASSEXTEND = "development"

CLASSOVERRIDE .= ":class-development"

python development_virtclass_handler () {
# Do nothing if this is inherited, as it's for BBCLASSEXTEND
if "development" not in (d.getVar('BBCLASSEXTEND') or ""):
bb.error("Don't inherit development, use BBCLASSEXTEND")
return

# Restore BPN
bpn = d.getVar('BPN')
newbpn = bpn.replace('-development', '')
d.setVar('BPN', newbpn)

# Use default FILESPATH searching for patches and files
filespath = d.getVar('FILESPATH')
newfilespath = filespath.replace('-development', '')
d.setVar('FILESPATH', newfilespath)
}

addhandler development_virtclass_handler
development_virtclass_handler[eventmask] = "bb.event.RecipePreFinalise"

==

--
Best Regards
Ulf Samuelsson
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Managing multiple builds

[Mike Looijmans]

Two products sounds like two machines. Just create a machine.conf for each 
product (even if they use similar hardware), then you don't need overrides 
elsewhere.

OE/Yocto is smart enough to figure out what needs to be (re)built. Some OE 
projects build the same image(s) for over 40 machines (and counting)...

On 14-02-19 01:34, Timothy Froehlich wrote:
> 
> Hi, I've been struggling a bit with this question. I want to use Yocto to 
> build two+ products with separate dev/prod images for each (dev including 
> debug-tweaks, etc.). I've ruled out separate image recipes because my dev 
> builds need ENABLE_UART on my RaspberryPi and that needs to be set at the 
> conf 
> level (I've got it set conditionally in my base dist conf). Multiconfig 
> looked 
> promising, but I'm not happy about how long the parsing takes to start a 
> build. "--postread" looked nice, but I've barely seen it mentioned so I'm 
> worried that it's not well supported.
> 
> Basically, what do most people do for controlling their builds?
> Tim Froehlich
> Embedded Linux Engineer
> tfroehl...@archsys.io 
> 215-218-8955
> 

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

[yocto] icecast

[Leonardo Jose Duarte MendesJunior]

I'm trying to compile the package icecast. The package icecast is old. The
package depends on xslt.
When I compile this package, I had the issue with xslt.
How to use pkgconfig if the own source code use him ?
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Opusenc e shout2

[Leonardo Jose Duarte MendesJunior]

Thanks!

Em qui, 14 de fev de 2019 às 11:09, Randy MacLeod <
randy.macl...@windriver.com> escreveu:

> On 2/14/19 7:43 AM, Leonardo Jose Duarte MendesJunior wrote:
> > Good morning,
> >
> > I'm compiling the gstreamer1.0 and its plugins, but the plugins:
>
> > opusenc
>
> Seems to be a PACKAGECONIFG:
>
> $ grep opus meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-*bb
> meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad_1.14.4.bb:#
> the opus encoder/decoder elements are now in the -base package,
> meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad_1.14.4.bb:#
> but the opus parser remains in -bad
> meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad_1.14.4.bb:PACKAGECONFIG[opusparse]
>
>= "--enable-opus,--disable-opus,libopus"
> meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-base_1.14.4.bb:PACKAGECONFIG[opus]
>
>  = "--enable-opus,--disable-opus,libopus"
>
>
>
> > and shout2send
>
> That's disabled:
> $ grep shout
> meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-good_1.14.4.bb
>  --disable-shout2 \
>
> You'll have to work on understanding why it was disabled and
> send a patch to fix it.
>
> ../Randy
>
> > are not found in the image.
> > Any idea what can it be?How can I solve this?
> >
> > Thanks.
> >
> >
> >
>
>
> --
> # Randy MacLeod
> # Wind River Linux
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Opusenc e shout2

[Randy MacLeod]

On 2/14/19 7:43 AM, Leonardo Jose Duarte MendesJunior wrote:

Good morning,

I'm compiling the gstreamer1.0 and its plugins, but the plugins:


opusenc 


Seems to be a PACKAGECONIFG:

$ grep opus meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-*bb
meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad_1.14.4.bb:# 
the opus encoder/decoder elements are now in the -base package,
meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad_1.14.4.bb:# 
but the opus parser remains in -bad
meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad_1.14.4.bb:PACKAGECONFIG[opusparse] 
  = "--enable-opus,--disable-opus,libopus"
meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-base_1.14.4.bb:PACKAGECONFIG[opus] 
= "--enable-opus,--disable-opus,libopus"




and shout2send 


That's disabled:
$ grep shout 
meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-good_1.14.4.bb

--disable-shout2 \

You'll have to work on understanding why it was disabled and
send a patch to fix it.

../Randy


are not found in the image.
Any idea what can it be?How can I solve this?

Thanks.






--
# Randy MacLeod
# Wind River Linux
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Opusenc e shout2

[Leonardo Jose Duarte MendesJunior]

Good morning,

I'm compiling the gstreamer1.0 and its plugins, but the plugins opusenc and
shout2send are not found in the image.
Any idea what can it be?How can I solve this?

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

Re: [yocto] Fixing devtool issue with kernel bbhappen do_patch recipe

[Yann CARDAILLAC]

Hi,

A colleague gave a first look to my patch, and gave me advice about how to
improve it.

Here's a new version.

Regards,

On Mon, Feb 11, 2019 at 9:35 AM Yann CARDAILLAC 
wrote:

> Hi,
>
> If you need more details about how to reproduce just ask, or if that's not
> the correct mailing list, I'll be happy to post my message wherever it
> belongs.
>
> Regards,
>
> Yann
>
> On Mon, Jan 28, 2019 at 1:26 PM Yann CARDAILLAC 
> wrote:
>
>> Hi all,
>>
>> We found a possible bug with boucman_work as mentionned in the IRC.
>>
>> It seems that when using the SDK there's an issue with the generated file
>> workspace/appends/linux-yocto_4.18.bbappend (or equivalent depending on
>> kernel and distro).
>>
>> In the do_patch rule, if some script are intended to be applied in
>> another language than python it will fail. I had the case with my BSP
>> (phytec). We had to change the rule with :
>>
>> do_patch[noexec] = "1"
>>
>> so that the rule is not executed which was what was probably intended
>> with the former :
>>
>> do_patch() {
>> :
>> }
>>
>> Here's the patch we would use to fix that. It patch the scipt
>> scripts/lib/devtool/standard.py so that it properly generate the bbappend
>> file. Please, do not hesitate to give me any feedback on my patch.
>>
>> Regards,
>>
>> --
>> [image: SMILE] 
>>
>> 20 rue des Jardins
>> 92600 Asnières-sur-Seine
>> *Yann CARDAILLAC*
>> Ingénieur Linux Embarqué
>>
>> [image: email] yann.cardail...@smile.fr
>> [image: url] http://www.smile.eu
>>
>> [image: Twitter]  [image: Facebook]
>>  [image: LinkedIn]
>>  [image: Github]
>> 
>>
>>
>> [image: eco] Pour la planète, n'imprimez ce mail que si c'est nécessaire
>>
>
>
> --
> [image: SMILE] 
>
> 20 rue des Jardins
> 92600 Asnières-sur-Seine
> *Yann CARDAILLAC*
> Ingénieur Linux Embarqué
>
> [image: email] yann.cardail...@smile.fr
> [image: url] http://www.smile.eu
>
> [image: Twitter]  [image: Facebook]
>  [image: LinkedIn]
>  [image: Github]
> 
>
>
> [image: eco] Pour la planète, n'imprimez ce mail que si c'est nécessaire
>


-- 
[image: SMILE] 

20 rue des Jardins
92600 Asnières-sur-Seine
*Yann CARDAILLAC*
Ingénieur Linux Embarqué

[image: email] yann.cardail...@smile.fr
[image: url] http://www.smile.eu

[image: Twitter]  [image: Facebook]
 [image: LinkedIn]
 [image: Github]



[image: eco] Pour la planète, n'imprimez ce mail que si c'est nécessaire
From 175e2f0c219348296b97129bccbd39823527e411 Mon Sep 17 00:00:00 2001
From: Yann CARDAILLAC 
Date: Thu, 14 Feb 2019 11:39:01 +0100
Subject: [PATCH] correct do_patch for kernel bbappend for sdk

do_patch rule of SDK's workspace/appends/linux-*.bbhappend may fail if script are not written in Python

that was the case with Phytec's BSP, the fix was to replace the do_patch rule with :

do_patch[noexec]="1" when the file was generated in scripts/lib/devtool/standard.py

Signed-off-by: Yann CARDAILLAC 
---
 scripts/lib/devtool/standard.py | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/scripts/lib/devtool/standard.py b/scripts/lib/devtool/standard.py
index d14b7a6..5cb59f3 100644
--- a/scripts/lib/devtool/standard.py
+++ b/scripts/lib/devtool/standard.py
@@ -840,9 +840,7 @@ def modify(args, config, basepath, workspace):
 if bb.data.inherits_class('kernel', rd):
 f.write('SRCTREECOVEREDTASKS = "do_validate_branches do_kernel_checkout '
 'do_fetch do_unpack do_kernel_configme do_kernel_configcheck"\n')
-f.write('\ndo_patch() {\n'
-':\n'
-'}\n')
+f.write('\ndo_patch[noexec] = "1"\n')
 f.write('\ndo_configure_append() {\n'
 'cp ${B}/.config ${S}/.config.baseline\n'
 'ln -sfT ${B}/.config ${S}/.config.new\n'
-- 
2.7.4

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

Re: [yocto] [OE-core] Yocto Project Status WW07'19

[Alexander Kanavin]

I think it looks right now, thanks :)

Alex

On Thu, 14 Feb 2019 at 10:13, Michael Halstead
 wrote:
>
> The regular 3 hour update wasn't installed on the new server. I have
> repaired that and added the RRS updates as well..
>
> The update has been run several times in testing and I'm curious if RRS
> has caught up as expected.
>
> On 2/12/19 5:57 PM, Paul Eggleton wrote:
> > Hi Alex
> >
> > On Wednesday, 13 February 2019 6:22:23 AM NZDT Alexander Kanavin wrote:
> >> On Tue, 12 Feb 2019 at 17:10,  wrote:
> >>> The recipe reporting system integration with the layer index is available
> >>> at: https://layers.openembedded.org/rrs/recipes/OE-Core/2.7/M3/ and the
> >>> historical data has now been imported.
> >> Sadly the new RRS still seems to be suffering from the 'outdated info'
> >> problem. For example glibc, or python3 recipes have been updated to
> >> latest versions, yet RRS still shows that they haven't been.
> > We're reliant upon the layer index updating and it appears that's not 
> > working
> > at the moment. I have asked Michael to look into it. Thanks for the report,
> > I'll reply back here when things are sorted out.
> >
> > Cheers,
> > Paul
> >
> --
> Michael Halstead
> Linux Foundation / SysAdmin
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] npm recipe bad task order

[Jonas Andersson]

Hi,

I have some recipes created from npm packages with devtool.

do_populate_lic with: WARNING: Could not copy license file
and LIC_FILES_CHKSUM points to an invalid file.

In my understanding the problem is that do_populate_lic task is running
before do_compile:

log.task_order
___
do_cleansstate (20550): log.do_cleansstate.20550
do_cleanall (20551): log.do_cleanall.20551
do_fetch (20653): log.do_fetch.20653
do_unpack (22861): log.do_unpack.22861
do_prepare_recipe_sysroot (22862): log.do_prepare_recipe_sysroot.22862
do_patch (23281): log.do_patch.23281
do_configure (23283): log.do_configure.23283
do_populate_lic (23284): log.do_populate_lic.23284
do_compile (23289): log.do_compile.23289
___

The recipes npm created with devtool reference license to S
(${WORKDIR}/npmpkg):
__
LIC_FILES_CHKSUM = "file://LICENSE;md5=75dbbb2f49d90bfc476532dc5861fd26 \

file://node_modules/inherits/LICENSE;md5=5b2ef2247af6d355ae9d9f988092d470 \

file://node_modules/psl/LICENSE;md5=2425d288296fae32e27553694ff40294 \

file://node_modules/rc/LICENSE.MIT;md5=e0f70a42adf526e6f5e605a94d98a420"
__

But as npm_do_compile is the task that populates workdir there is no
license files available when do_populate_lic runs.

I have tried both sumo and thud but with the same result, is the order
something that have change?

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

Re: [yocto] [OE-core] Yocto Project Status WW07'19

[Michael Halstead]

The regular 3 hour update wasn't installed on the new server. I have 
repaired that and added the RRS updates as well..


The update has been run several times in testing and I'm curious if RRS 
has caught up as expected.


On 2/12/19 5:57 PM, Paul Eggleton wrote:

Hi Alex

On Wednesday, 13 February 2019 6:22:23 AM NZDT Alexander Kanavin wrote:

On Tue, 12 Feb 2019 at 17:10,  wrote:

The recipe reporting system integration with the layer index is available
at: https://layers.openembedded.org/rrs/recipes/OE-Core/2.7/M3/ and the
historical data has now been imported.

Sadly the new RRS still seems to be suffering from the 'outdated info'
problem. For example glibc, or python3 recipes have been updated to
latest versions, yet RRS still shows that they haven't been.

We're reliant upon the layer index updating and it appears that's not working
at the moment. I have asked Michael to look into it. Thanks for the report,
I'll reply back here when things are sorted out.

Cheers,
Paul


--
Michael Halstead
Linux Foundation / SysAdmin

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

Re: [yocto] Managing multiple builds

[Alexander Kanavin]

On Thu, 14 Feb 2019 at 01:35, Timothy Froehlich  wrote:
> Hi, I've been struggling a bit with this question. I want to use Yocto to 
> build two+ products with separate dev/prod images for each (dev including 
> debug-tweaks, etc.). I've ruled out separate image recipes because my dev 
> builds need ENABLE_UART on my RaspberryPi and that needs to be set at the 
> conf level (I've got it set conditionally in my base dist conf). Multiconfig 
> looked promising, but I'm not happy about how long the parsing takes to start 
> a build. "--postread" looked nice, but I've barely seen it mentioned so I'm 
> worried that it's not well supported.
>

Which recipes use the ENABLE_UART setting? You might want to write two
variants of those, and include them into images accordingly.

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

Re: [yocto] SDK install w/ CMake

[Eric Schwarz]

Hi Pascal


I don't think your issue has something do to with CMake.


You are right IMHO. We checked again the pugixml installation behaviour 
and it turned out we are experiencing the same issue.


we have got the problem that w/ the Yocto recipe and CMake install 
targets

as below always everything (headers and library or binary
respectively) is installed in the SDK.
The binary also goes into the SDK even though we just add it to
IMAGE_INSTALL based on a XILINX yocto build (rel-v2018.3).


I'm not sure I understand what you are trying to do. If you add 
something to IMAGE_INSTALL it gets installed to the target.

That usually includes binaries and libraries.

If you only want libraries but not binaries it's probably best to split 
them into multiple packages as described in 
https://www.yoctoproject.org/docs/latest/mega-manual/mega-manual.html#package-splitting-dev-environment


This way you can have the binaries in a different package like 
${PN}-tools.




We have not figured out on how to add the build artifacts of the library 
to the the correct FILES_${PN} variables. It seems that the FILES_${PN} 
variables are also kind of overlayed [1].


a) We would like to see the *.so of the library only on the RootFS but 
the headers, the *.so and the *.a in the SDK.
b) We are trying to install a binary via FILES_${PN} but it also ends up 
in the SDK no matter what.


A colleague also posted the question on stackoverflow [2] which 
describes it more verbosely.


The Yocto release is rocko based.

Thanks
Eric

[1] 
https://stackoverflow.com/questions/35090669/bitbake-packaging-strangeness

[2] https://stackoverflow.com/q/54569314/10921299
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto