Re: [yocto] [EXTERNAL] Re: Issues adding bare meta toolchain to yocto build

[Westermann, Oliver]

Thanks for all the help so far, I have a working recipe which installs the whole
toolchain to /usr/bin and uses that from another recipe :)

> On Thu, 2019-10-24 at 08:55 +, Richard Purdie wrote:
> You can probably do that by extending SYSROOT_DIRS in the recipe.

I'm still having issues here: I've tried to extend SYSROOOT_DIRS and even used a
path relative to the existing entrys (so I don't get caught by some hidden
extension mechanism), but my files still don't end up in the sysroot.
I've also tried both, SYSROOOT_DIRS and SYSROOT_DIRS_NATIVE, with the same 
result.

A (hopefully) last tip would be appreciated to make a nice recipe from a 
working one.

GCC_ARM_NONE_EXTRA_PATH="/${PN}"
SYSROOOT_DIRS += "${bindir}/../opt"

do_install() {
# old and working to install to /usr/bin/
# install -d ${D}${bindir}${GCC_ARM_NONE_EXTRA_PATH}
# cp -r ${S}/* ${D}${bindir}${GCC_ARM_NONE_EXTRA_PATH}

# new, but no files in the sysroots of recipes using the toolchain
install -d ${D}${bindir}/../opt${GCC_ARM_NONE_EXTRA_PATH}
cp -r ${S}/* ${D}${bindir}/../opt${GCC_ARM_NONE_EXTRA_PATH}
}

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

Re: [yocto] [EXTERNAL] Re: Issues adding bare meta toolchain to yocto build

[Westermann, Oliver]

> On Thu, 2019-10-24 at 04:01 +, Richard Purdie wrote:
> If its a native recipe, there are no packages and therefore FILES
> doesn't make sense.

Oh, I have to admit I'm pretty new to the concept of the native packages.
Where can I find the list of files that are considered to be installed into
a "native" packages sysroot?

An good option for me would be to eg. install the toolchain into the native
sysroots /opt/ dir for usage by other recipes.

> Can you confirm that recipe does work?

For the TI recipe, no, I can't. I found it online and used it as a guide for
my first steps on the topic.


> If you install the binaries into ${bindir} they will. If you place them
> somewhere else which the system doesn't know about, they probably
> won't.
> 
> There are ways to make alternative locations work but I don't see any
> of that in the above recipe.

Can you point me to these ways? :)

> There isn't anything that special about a baremetal compiler except it
> sets some different default flags and is missing the library support.

I agree, though using linaro has the benefit that we would use the same
toolchain in yocto as in "regular development" of the m4 functionality.

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

[yocto] Issues adding bare meta toolchain to yocto build

[Westermann, Oliver]

> On Thu, 2019-10-24 at 04:01 +, Richard Purdie wrote:
> If its a native recipe, there are no packages and therefore FILES
> doesn't make sense.

Oh, I have to admit I'm pretty new to the concept of the native packages.
Where can I find the list of files that are considered to be installed into
a "native" packages sysroot?

An good option for me would be to eg. install the toolchain into the native
sysroots /opt/ dir for usage by other recipes.

> Can you confirm that recipe does work?

For the TI recipe, no, I can't. I found it online and used it as a guide for
my first steps on the topic.


> If you install the binaries into ${bindir} they will. If you place them
> somewhere else which the system doesn't know about, they probably
> won't.
> 
> There are ways to make alternative locations work but I don't see any
> of that in the above recipe.

Can you point me to these ways? :)

> There isn't anything that special about a baremetal compiler except it
> sets some different default flags and is missing the library support.

I agree, though using linaro has the benefit that we would use the same
toolchain in yocto as in "regular development" of the m4 functionality.

Best regards, Olli

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

Re: [yocto] [EXTERNAL] Re: Issues adding bare meta toolchain to yocto build

[Westermann, Oliver]

>On Wed, 2019-10-23 at 15:34 +, Richard Purdie wrote:
>>On Wed, 2019-10-23 at 11:23 +, Westermann, Oliver wrote:
>> Hey,
>> [...]
>> Any suggestions on what I'm doing wrong or how to debug this further?
>Sounds like the sysroot filtering code doesn't know about this
>directory and therefore doesn't pass it through to the recipe sysroot?

Sorry to ask dumb questions, but what do you mean by "this directory"?
The toolchain directory created by the TI recipe? Shouldn't that be handled
by FILES_${PN}?

>The recipe you link to is for an on target compiler, not one in the
>sysroot.

Again, might be a stupid missunderstanding on my side: The recipe I linked
extracts a precompiled toolchain that is suitable only for x86_64 systems and 
allows a "native" package. From my current understanding, a native package is
to be used on the build host, which is what I'm intending to do here.

I managed to sucessfully add a native recipe for the NXP code signing tool
(which is only provided as a precompiled binary as well) which works as 
expected.

>I'm actually a little surprised you can't use our standard cross
>compiler assuming this M4 core is on an ARM chip? It should be a case
>of passing the right options to the compiler to target the M4?

I'm totally up for any infos on how to do this! I did google around for recipes
or examples that build a non-linux binary using yocto, but I couldn't really 
find
anything or any documentation. But maybe my searchterms (along "build baremetal 
arm binary using yocto") were off target. Can you point me at documentation, 
examples,
searchterms..?

>Cheers,
>
>Richard

Thanks for the help!
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Issues adding bare meta toolchain to yocto build

[Westermann, Oliver]

Hey,

I'm having issues adding a build for a bare metal target to my yocto toolchain. 
I've a NXP SoC with a M4 core and I would like to integrate the M4 binary build 
into yocto.
My M4 binary has a CMAKE file that depends on ARMGCC_DIR being set to locate 
the toolchain and everything works fine locally.

I've create a recipe for the toolchain that is heavily inspired by a TI recipe 
for the gcc-arm-none-eabi (available here: 
http://git.yoctoproject.org/cgit/cgit.cgi/meta-ti/tree/recipes-ti/devtools/gcc-arm-none-eabi_7-2018-q2-update.bb?h=master).
I've made sure that GCC_ARM_NONE_TOOLCHAIN_RECIPE is set.

After calling bitbake -cpopulate-sysroot gcc-arm-none-eabi-native the 
image/${GCC_ARM_NONE_TOOLCHAIN_RECIPE} path contains the complete toolchain.

My M4 recipe looks like this (plus SUMMARY, LICENSE, SRC_URI, ...):

inherit pkgconfig cmake
DEPENDS = "gcc-arm-none-eabi-native"

S = "${WORKDIR}/git "

EXTRA_OECMAKE = '-DCMAKE_TOOLCHAIN_FILE="../armgcc.cmake" \
 -G "Unix Makefiles" \
 -DCMAKE_BUILD_TYPE=release'

>From my understanding depending on gcc-arm-none-eabi-native should result in 
>the native toolchain being installed into the m4's recipe-sysroot-native 
>folder.
The sysroot-providers in the recipe-sysroot-native folder does list 
gcc-arm-none-eabi-native, but I don't get the files and therefore have no 
toolchain.

Any suggestions on what I'm doing wrong or how to debug this further?

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

[yocto] Transfer meta-data between recipes

[Westermann, Oliver]

Hey,

I'm trying to implement a bootloader-signing mechanism within yocto for 
extended secure-boot support. The bootloader and it's recipes are provided by 
NXP (in this case it's the imx-boot_*.bb recipe from meta-freescale) and I want 
to use a secondary recipe which I am creating to sign the resulting boot 
binary. My issue is that the NXP code signing tool needs some info about the 
binary to sign. These details are send to stdout by imx-mkimage tool, which is 
called by the imx boot makefile (used here: 
https://github.com/Freescale/meta-freescale/blob/master/recipes-bsp/imx-mkimage/imx-boot_0.2.bb#L104).

I can override the compile step of imx-boot to save stdout into a file, deploy 
this file and later parse it to extract the offset dump, but that feels "ugly" 
and the file is by no means a output of the imx-boot recipe for the target 
system, but for another step. Is there any recommended way to parse such 
variable metadata between recipes?

Olli

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

[yocto] Debugging deployment of kernel image

[Westermann, Oliver]

Hey,

I'm currently in the process of updating our yocto (sumo) with a new kernel 
version from a supplier (NXP) and I'm having some issues, we somehow broke 
deployment of the linux kernel: I get the Image & symlink in my images folder, 
but it does not end up in my rootfs. It SHOULD end up at /boot. My system boots 
u-boot and searches for the kernel (and fails ofc). If I manually place my 
kernel, everything is fine.

I would like to find out where in my recipes this goes south:
I've checked build//tmp/work/-poky-linux/linux-imx/4.14.78-r0/deploy-linux-imx and the kernel and the 
expected kernel Image and symlink is there alongside the .dtb files. The dtb 
files get deployed as expected, but my kernel does not.

I've also checked build//tmp/work/-poky-linux/linux-imx/4.14.78-r0/deploy-rpms// , where I've got a 
kernel-image-image-4.14.78-+-4.14.78-r0..rpm, which contains 
the kernel and the symlink.
Which brings me into an area of yocto I'm not used to, since usually THAT part 
worked for me ;-)

So if a RPM is generated, but not properly installed, where do I continue my 
debugging efforts?
I've already checked the output of bitbake -e linux-imx, but I only used -e 
only to debug my recipes (how stuff expands), so this was more of a "random 
looking at stuff" to figure things out.

Any help appreciated.

- Olli

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

Re: [yocto] Defining group of machines

[Westermann, Oliver]

> > is that what you were after?
> override is the first thing that crossed my mind...   

Thanks both of you, an additional machine override was exactly what we needed.

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

[yocto] Defining group of machines

[Westermann, Oliver]

Hey,

We've a product group with different devices, each having their machine-conf, eg
Device_a
Device_a_mini
Device_b
Device_b_mini <- Upcoming
Device_c <- Upcoming

Since device_a and device_a_mini share a lot of code, for them we use one of 
the machine overrides, describing the processor family, so I use 
RDEPENDS_${PN}_append_device_a if I just need it for device_a and 
RDEPENDS_${PN}_append_am57x for device_a and device_a_mini.

Now I'm in the situation that device_c will use the same CPU as device b, so I 
need something like a "group" of devices for family b.

How can I define a MACHINE_GROUP_device_b_group = "device_b device_b_mini" so I 
can do
RDEPENDS_${PN}_append_device_b_group or do_install_append_device_b_group()?

Best regards, Olli

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

Re: [yocto] Creating a recipe for python3-pillow

[Oliver Westermann]

Am Fr., 6. Juli 2018 um 15:13 Uhr schrieb Burton, Ross <
ross.bur...@intel.com>:

> Move your DEPENDS up, as the inherits are setting up DEPENDS with
> python3-native python3-setuptools-native, and you're overwriting it.
>
> Put the DEPENDS after PYI_PACKAGE but before inherit.
>
> Ross
>

One step further :) It now compiles...and fails. Interestingly it raises an
Exception missing the jpeg library. I found the libjpeg.so and header
files, so i enabled the debug info of setup.py. This reveals some
strange-for-me details:

| [other messages where it searched for libjpeg.h]
| Checking for include file jpeglib.h in /usr/include
| Found jpeglib.h
| Couldn't find library jpeg in
['/data/workspace/yocto-build/build/mysys/tmp/work/aarch64-poky-linux/python3-pillow/5.2.0-r0/recipe-sysroot-native/usr/lib',
'/usr/local/lib', '/usr/lib', '/lib']

So a find | grep jpeg revealed that the library files for jpeg are placed
in recipe-sysroot/usr/lib/, while zlib places librarys
in recipe-sysroot/usr/lib and recipe-sysroot-native/usr/lib.
Some googling didn't provide an answer, just more confusion :O

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

Re: [yocto] Creating a recipe for python3-pillow

[Oliver Westermann]

Of course, thats the reason I'm here ;)

SUMMARY = "Pillow (The friendly PIL fork)"
HOMEPAGE = "http://python-pillow.org/;
LICENSE = "EPLv1"
LIC_FILES_CHKSUM = "file://LICENSE;md5=c6379001ecb47e2a0420c40177fc1125"

SRC_URI[md5sum] = "52d93a34f4180abcff04876f23eaa9b9"

PYPI_PACKAGE = "Pillow"

inherit pypi setuptools3

BBCLASSEXTEND = "native nativesdk"

DEPENDS = "jpeg zlib"

CLEANBROKEN="1"

So the exact same from above, just with the missing libs as dependencies
and the CLEANBROKEN/do_configure line. I've also deleted and rebuild the
build subdir, are there other things to clean manually to be sure?

Olli

Am Fr., 6. Juli 2018 um 14:58 Uhr schrieb Burton, Ross <
ross.bur...@intel.com>:

> What. You've got inherit setuptools3 so it should be using our own
> python3 and have setuptools present. This makes no sense. :/
>
> Can  you share the recipe you're building?
>
> Ross
>
> On 6 July 2018 at 13:56, Oliver Westermann  wrote:
> > Am Fr., 6. Juli 2018 um 14:38 Uhr schrieb Burton, Ross
> > :
> >>
> >> That's very odd.  I'd suggest maybe something really weird happened,
> >> what happens if you bitbake -cclean python3-pillow ; bitbake
> >> python3-pillow?
> >
> >
> > It fails with another error *dudum*
> >
> > ERROR: python3-pillow-5.2.0-r0 do_compile: python3 setup.py build_ext
> > execution failed.
> > ERROR: python3-pillow-5.2.0-r0 do_compile: Function failed: do_compile
> (log
> > file is located at
> >
> /data/workspace/yocto-build/build/mysys/tmp/work/aarch64-poky-linux/python3-pillow/5.2.0-r0/temp/log.do_compile.328)
> > ERROR: Logfile of failure stored in:
> >
> /data/workspace/yocto-build/build/mysys/tmp/work/aarch64-poky-linux/python3-pillow/5.2.0-r0/temp/log.do_compile.328
> > Log data follows:
> > | DEBUG: Executing shell function do_compile
> > | Traceback (most recent call last):
> > |   File "setup.py", line 22, in 
> > | from setuptools import Extension, setup
> > | ImportError: No module named 'setuptools'
> > | ERROR: python3 setup.py build_ext execution failed.
> > | WARNING: exit code 1 from a shell command.
> > | ERROR: Function failed: do_compile (log file is located at
> >
> /data/workspace/yocto-build/build/mysys/tmp/work/aarch64-poky-linux/python3-pillow/5.2.0-r0/temp/log.do_compile.328)
> >
> > Olli
> >
> > Am Fr., 6. Juli 2018 um 14:38 Uhr schrieb Burton, Ross
> > :
> >>
> >> On 6 July 2018 at 13:32, Oliver Westermann 
> wrote:
> >> >  This does not seem to work as expected. With option 1) and 2) it
> fails
> >> > in
> >> > do_compile:
> >> >
> >> > | DEBUG: Executing shell function do_compile
> >> > |
> >> >
> >> >
> /data/workspace/yocto-build/build/mysys/tmp/work/aarch64-poky-linux/python3-pillow/5.2.0-r0/temp/run.do_compile.14093:
> >> > 112:
> >> >
> >> >
> /data/workspace/yocto-build/build/mysys/tmp/work/aarch64-poky-linux/python3-pillow/5.2.0-r0/temp/run.do_compile.14093:
> >> >
> >> >
> /data/workspace/yocto-build/build/mysys/tmp/work/aarch64-poky-linux/python3-pillow/5.2.0-r0/recipe-sysroot-native/usr/bin/python3-native/python3:
> >> > not found
> >> > | ERROR: python3 setup.py build_ext execution failed.
> >> > | WARNING: exit code 1 from a shell command.
> >> > | ERROR: Function failed: do_compile (log file is located at
> >> >
> >> >
> /data/workspace/yocto-build/build/mysys/tmp/work/aarch64-poky-linux/python3-pillow/5.2.0-r0/temp/log.do_compile.14093)
> >>
> >> That's very odd.  I'd suggest maybe something really weird happened,
> >> what happens if you bitbake -cclean python3-pillow ; bitbake
> >> python3-pillow?
> >>
> >> Ross
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Creating a recipe for python3-pillow

[Oliver Westermann]

 Am Fr., 6. Juli 2018 um 14:38 Uhr schrieb Burton, Ross <
ross.bur...@intel.com>:

> That's very odd.  I'd suggest maybe something really weird happened,
> what happens if you bitbake -cclean python3-pillow ; bitbake
> python3-pillow?
>

It fails with another error *dudum*

ERROR: python3-pillow-5.2.0-r0 do_compile: python3 setup.py build_ext
execution failed.
ERROR: python3-pillow-5.2.0-r0 do_compile: Function failed: do_compile (log
file is located at
/data/workspace/yocto-build/build/mysys/tmp/work/aarch64-poky-linux/python3-pillow/5.2.0-r0/temp/log.do_compile.328)
ERROR: Logfile of failure stored in:
/data/workspace/yocto-build/build/mysys/tmp/work/aarch64-poky-linux/python3-pillow/5.2.0-r0/temp/log.do_compile.328
Log data follows:
| DEBUG: Executing shell function do_compile
| Traceback (most recent call last):
|   File "setup.py", line 22, in 
| from setuptools import Extension, setup
| ImportError: No module named 'setuptools'
| ERROR: python3 setup.py build_ext execution failed.
| WARNING: exit code 1 from a shell command.
| ERROR: Function failed: do_compile (log file is located at
/data/workspace/yocto-build/build/mysys/tmp/work/aarch64-poky-linux/python3-pillow/5.2.0-r0/temp/log.do_compile.328)

Olli

Am Fr., 6. Juli 2018 um 14:38 Uhr schrieb Burton, Ross <
ross.bur...@intel.com>:

> On 6 July 2018 at 13:32, Oliver Westermann  wrote:
> >  This does not seem to work as expected. With option 1) and 2) it fails
> in
> > do_compile:
> >
> > | DEBUG: Executing shell function do_compile
> > |
> >
> /data/workspace/yocto-build/build/mysys/tmp/work/aarch64-poky-linux/python3-pillow/5.2.0-r0/temp/run.do_compile.14093:
> > 112:
> >
> /data/workspace/yocto-build/build/mysys/tmp/work/aarch64-poky-linux/python3-pillow/5.2.0-r0/temp/run.do_compile.14093:
> >
> /data/workspace/yocto-build/build/mysys/tmp/work/aarch64-poky-linux/python3-pillow/5.2.0-r0/recipe-sysroot-native/usr/bin/python3-native/python3:
> > not found
> > | ERROR: python3 setup.py build_ext execution failed.
> > | WARNING: exit code 1 from a shell command.
> > | ERROR: Function failed: do_compile (log file is located at
> >
> /data/workspace/yocto-build/build/mysys/tmp/work/aarch64-poky-linux/python3-pillow/5.2.0-r0/temp/log.do_compile.14093)
>
> That's very odd.  I'd suggest maybe something really weird happened,
> what happens if you bitbake -cclean python3-pillow ; bitbake
> python3-pillow?
>
> Ross
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Creating a recipe for python3-pillow

[Oliver Westermann]

Am Do., 5. Juli 2018 um 12:59 Uhr schrieb Burton, Ross <
ross.bur...@intel.com>:

> On 5 July 2018 at 08:26, Oliver Westermann  wrote:
> > I'm fiddeling around with yocto. I want to move some python stuff onto an
> > embedded board and use the nxp mx8 yocto. Everything worked as expected
> > until now, I was able to create yocto recipes for python modules like
> pyv4l2
> > (is there any interest for recipes like these to be commited to
> > meta-python?).
> >
> > Now I wanted to install pillow for some image manipulation, but whereas
> > other python module recipes worked fine, this one fails and I don't
> > understand why.
> >
> > Yocto reports missing setuptools:
> >
> > Log data follows:
> > | DEBUG: Executing shell function do_configure
> > | NOTE: make clean
> > | python setup.py clean
> > | Traceback (most recent call last):
> > |   File "setup.py", line 22, in 
> > | from setuptools import Extension, setup
> > | ImportError: No module named setuptools
> >
> > I've googled around and everything suggests that inherit setuptools3 is
> > missing, but it's present in my recipe. This is my
> python3-pillow_5.2.0.bb:
> >
> > SUMMARY = "Pillow (The friendly PIL fork)"
> > HOMEPAGE = "http://python-pillow.org/;
> > LICENSE = "EPLv1"
> > LIC_FILES_CHKSUM = "file://LICENSE;md5=c6379001ecb47e2a0420c40177fc1125"
> >
> > SRC_URI[md5sum] = "52d93a34f4180abcff04876f23eaa9b9"
> >
> > PYPI_PACKAGE = "Pillow"
> >
> > inherit pypi setuptools3
> >
> > BBCLASSEXTEND = "native nativesdk"
> >
> > Any idea whats missing or what I am doing wrong (other than that the
> license
> > line is incorrect)?
>
> Oh, that's a fun one.
>
> So setuptools/distutils/etc doesn't have the concept of a "configure"
> phase but it also doesn't remove the default implementation.  The
> default implementation will try to do a 'make clean' first to remove
> existing build artifacts.  Normally this does nothing with Python code
> as there's never a Makefile, but pillow has a Makefile.  This makefile
> does 'python setup.py clean', which is running the *host* Python2 and
> you don't have distutils installed.  So, it fails.
>
> Three solutions in order of hackiness (more to less)
> 1) Set CLEANBROKEN="1" in the recipe to stop the clean happening
> 2) Nullify do_configure in the recipe with do_configure[noexec] = "1"
> 3) Override do_configure in distutils3.bbclass to call setup.py
> directly to do a clean in do_configure
>
> I'd say do (1) in your recipe and I'll send a patch for (3) to oe-core.
>
> And yes, this recipe would be very welcome in meta-python.
>
> Ross
>

 This does not seem to work as expected. With option 1) and 2) it fails in
do_compile:

| DEBUG: Executing shell function do_compile
|
/data/workspace/yocto-build/build/mysys/tmp/work/aarch64-poky-linux/python3-pillow/5.2.0-r0/temp/run.do_compile.14093:
112: 
/data/workspace/yocto-build/build/mysys/tmp/work/aarch64-poky-linux/python3-pillow/5.2.0-r0/temp/run.do_compile.14093:
/data/workspace/yocto-build/build/mysys/tmp/work/aarch64-poky-linux/python3-pillow/5.2.0-r0/recipe-sysroot-native/usr/bin/python3-native/python3:
not found
| ERROR: python3 setup.py build_ext execution failed.
| WARNING: exit code 1 from a shell command.
| ERROR: Function failed: do_compile (log file is located at
/data/workspace/yocto-build/build/mysys/tmp/work/aarch64-poky-linux/python3-pillow/5.2.0-r0/temp/log.do_compile.14093)

Option 3 seems to be out of my league right now, I'm still missing some
understanding of what happens when in which context :O

But thanks already for the help :)

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

[yocto] Creating a recipe for python3-pillow

[Oliver Westermann]

 Hey,

I'm fiddeling around with yocto. I want to move some python stuff onto an
embedded board and use the nxp mx8 yocto. Everything worked as expected
until now, I was able to create yocto recipes for python modules like
pyv4l2 (is there any interest for recipes like these to be commited to
meta-python?).

Now I wanted to install pillow for some image manipulation, but whereas
other python module recipes worked fine, this one fails and I don't
understand why.

Yocto reports missing setuptools:

Log data follows:
| DEBUG: Executing shell function do_configure
| NOTE: make clean
| python setup.py clean
| Traceback (most recent call last):
|   File "setup.py", line 22, in 
| from setuptools import Extension, setup
| ImportError: No module named setuptools

I've googled around and everything suggests that inherit setuptools3 is
missing, but it's present in my recipe. This is my python3-pillow_5.2.0.bb:

SUMMARY = "Pillow (The friendly PIL fork)"
HOMEPAGE = "http://python-pillow.org/;
LICENSE = "EPLv1"
LIC_FILES_CHKSUM = "file://LICENSE;md5=c6379001ecb47e2a0420c40177fc1125"

SRC_URI[md5sum] = "52d93a34f4180abcff04876f23eaa9b9"

PYPI_PACKAGE = "Pillow"

inherit pypi setuptools3

BBCLASSEXTEND = "native nativesdk"

Any idea whats missing or what I am doing wrong (other than that the
license line is incorrect)?

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

Re: [yocto] yocto jethro failed on gettext-native

[Oliver Graute]

On 26/04/18, Zoran Stojsavljevic wrote:
> > I deleted all the build-imx6ulevk folder and build everything from
> > scratch with only one thread, waited a few hours for compilation and now
> > its working ;)
> 
> Still, I am struggling to understand why??? What is the requirement
> behind this ask?

The requirement was just get our older yocto (jethro) build running on a
PC of a different developer. Often developers have their own flavor of
Ubuntu releases and they update to newer versions while they still
develop on yocto releases which is much older. Because that yocto
release is currently in the field by our costumer. Our product cycle is
not so fast to use the newest yocto releases. We started to develop when
jethro was up to date.

We compiled single threaded just because his PC is a bit unstable on
high load. And it crashed a few times on parallel makes. I know that
this is not ideal for yocto development.

> 
> As we see, it is much longer (one thread only) than on 14.04!?

its takes much longer then with settings

PARALLEL_MAKE = "-j 4"
BB_NUMBER_THREADS = "4"
 
> Could you, please, do it on Ubuntu 17.04, or 17.10 (i bet, you
> can't)??? And why, after all???

currently not im using only Ubuntu LTS Releases.
Perhaps I will try 18.04  LTS which released yesterday ;)

Best regards,

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

Re: [yocto] yocto jethro failed on gettext-native

[Oliver Graute]

On 25/04/18, Andre McCurdy wrote:
> On Wed, Apr 25, 2018 at 8:03 AM, Oliver Graute <oliver.gra...@gmail.com> 
> wrote:
> > Hello list,
> >
> > I try to compile yocto jethro environment which is working
> > on a Ubuntu 14.04 installation. But not on a Kubuntu 16.04.
> >
> > The compilations stops on gettext-native.
> >
> > bitbake -k fsl-image-mfgtool-initramfs
> >
> > | x86_64-linux-libtool:   error: 'libgettextsrc_la-message.lo' is not a 
> > valid libtool object
> 
> libgettextsrc_la-message.lo should be a short text file. Could you
> find it in your build tree and post a copy?
> 

the file was a zero byte file. All other *.lo files in that directory
was zero byte too. I assume because of a system crash I had before.

Just a bitbake -c cleansstate and rebuild of gettext-native didn't fixed that.

I deleted all the build-imx6ulevk folder and build everything from
scratch with only one thread, waited a few hours for compilation and now
its working ;)

> > Some ideas whats the cause for this error?
> 
> At a guess, something a little unusual with the setup of your Kubuntu
> system. Combining Ubuntu 16.04 with OE 2.0 isn't so out of the
> ordinary and others would certainly have hit the problem before now if
> it was always seen.
> 
> Did you install all the standard host dependencies?
> 
>   
> https://www.yoctoproject.org/docs/2.0/yocto-project-qs/yocto-project-qs.html#packages
> 

yes but thanks for the link as reference.

Best regards,

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

Re: [yocto] yocto jethro failed on gettext-native

[Oliver Graute]

On 25/04/18, Zoran Stojsavljevic wrote:
> > I try to compile yocto jethro environment which is working
> > on a Ubuntu 14.04 installation. But not on a Kubuntu 16.04 .
> 
> What would be the benefit for the successful compiling of YOCTO Jethro on
> Kubuntu 16.04 over Ubuntu 14.04???

I tried to get my Yocto compiled on a PC of a colleague and his
installation was a Kubuntu 16.04. I've made the experience that often
only additional packages needs to be installed to step over these
compile issues. Sometimes its clear from the debug output but in this
case I have no Idea which packages is missing. On my develop PC and our
Buildserver with Ubuntu 14.04 everything is fine. But I'am afraid that I
can get similar trouble if I update to a newer ubuntu release there too.

Best regards,

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

[yocto] yocto jethro failed on gettext-native

[Oliver Graute]

Hello list,

I try to compile yocto jethro environment which is working
on a Ubuntu 14.04 installation. But not on a Kubuntu 16.04.

The compilations stops on gettext-native.

bitbake -k fsl-image-mfgtool-initramfs
 
 make[5]: Entering directory 
'/home/us/build-imx6ulevk-mfgtool/tmp/work/x86_64-linux/gettext-native/0.19.4-r0/build/gettext-tools/src'
| ../x86_64-linux-libtool  --tag=CC   --mode=link gcc   
-isystem/home/us/build-imx6ulevk-mfgtool/tmp/sysroots/x86_64-linux/usr/include 
-O2 -pipe -release 0.19.4 ../gnulib-lib/libgettextlib.la  -lc -no-undefined  
-L/home/us/build-imx6ulevk-mfgtool/tmp/sysroots/x86_64-linux/usr/lib 
-L/home/us/build-imx6ulevk-mfgtool/tmp/sysroots/x86_64-linux/lib 
-Wl,-rpath-link,/home/us/build-imx6ulevk-mfgtool/tmp/sysroots/x86_64-linux/usr/lib
 -Wl,-rpath-link,/home/us/build-imx6ulevk-mfgtool/tmp/sysroots/x86_64-linux/lib 
-Wl,-rpath,/home/us/build-imx6ulevk-mfgtool/tmp/sysroots/x86_64-linux/usr/lib 
-Wl,-rpath,/home/us/build-imx6ulevk-mfgtool/tmp/sysroots/x86_64-linux/lib 
-Wl,-O1 -o libgettextsrc.la -rpath 
/home/us/build-imx6ulevk-mfgtool/tmp/sysroots/x86_64-linux/usr/lib 
libgettextsrc_la-message.lo libgettextsrc_la-po-error.lo 
libgettextsrc_la-po-xerror.lo libgettextsrc_la-read-catalog-abstract.lo 
libgettextsrc_la-po-lex.lo libgettextsrc_la-po-gram-gen.lo 
libgettextsrc_la-po-charset.lo libgettex
 tsrc_la-read-po.lo libgettextsrc_la-read-properties.lo 
libgettextsrc_la-read-stringtable.lo libgettextsrc_la-open-catalog.lo 
libgettextsrc_la-dir-list.lo libgettextsrc_la-str-list.lo 
libgettextsrc_la-read-catalog.lo libgettextsrc_la-color.lo 
libgettextsrc_la-write-catalog.lo libgettextsrc_la-write-properties.lo 
libgettextsrc_la-write-stringtable.lo libgettextsrc_la-write-po.lo 
libgettextsrc_la-msgl-ascii.lo libgettextsrc_la-msgl-iconv.lo 
libgettextsrc_la-msgl-equal.lo libgettextsrc_la-msgl-cat.lo 
libgettextsrc_la-msgl-header.lo libgettextsrc_la-msgl-english.lo 
libgettextsrc_la-msgl-check.lo libgettextsrc_la-file-list.lo 
libgettextsrc_la-msgl-charset.lo libgettextsrc_la-po-time.lo 
libgettextsrc_la-plural-exp.lo libgettextsrc_la-plural-eval.lo 
libgettextsrc_la-plural-table.lo libgettextsrc_la-format.lo 
libgettextsrc_la-format-c.lo libgettextsrc_la-format-sh.lo 
libgettextsrc_la-format-python.lo libgettextsrc_la-format-python-brace.lo 
libgettextsrc_la-format-lisp.lo libgettextsr
 c_la-format-elisp.lo libgettextsrc_la-format-librep.lo 
libgettextsrc_la-format-scheme.lo libgettextsrc_la-format-java.lo 
libgettextsrc_la-format-csharp.lo libgettextsrc_la-format-awk.lo 
libgettextsrc_la-format-pascal.lo libgettextsrc_la-format-ycp.lo 
libgettextsrc_la-format-tcl.lo libgettextsrc_la-format-perl.lo 
libgettextsrc_la-format-perl-brace.lo libgettextsrc_la-format-php.lo 
libgettextsrc_la-format-gcc-internal.lo libgettextsrc_la-format-gfc-internal.lo 
libgettextsrc_la-format-qt.lo libgettextsrc_la-format-qt-plural.lo 
libgettextsrc_la-format-kde.lo libgettextsrc_la-format-boost.lo 
libgettextsrc_la-format-lua.lo libgettextsrc_la-format-javascript.lo 
libgettextsrc_la-read-desktop.lo
| x86_64-linux-libtool:   error: 'libgettextsrc_la-message.lo' is not a valid 
libtool object
| Makefile:2285: recipe for target 'libgettextsrc.la' failed
| make[5]: *** [libgettextsrc.la] Error 1
| make[5]: Leaving directory 
'/home/us/build-imx6ulevk-mfgtool/tmp/work/x86_64-linux/gettext-native/0.19.4-r0/build/gettext-tools/src'
| Makefile:2206: recipe for target 'all' failed
| make[4]: *** [all] Error 2
| make[4]: Leaving directory 
'/home/us/build-imx6ulevk-mfgtool/tmp/work/x86_64-linux/gettext-native/0.19.4-r0/build/gettext-tools/src'
| Makefile:1698: recipe for target 'all-recursive' failed
| make[3]: *** [all-recursive] Error 1
| make[3]: Leaving directory 
'/home/us/build-imx6ulevk-mfgtool/tmp/work/x86_64-linux/gettext-native/0.19.4-r0/build/gettext-tools'
| Makefile:1564: recipe for target 'all' failed
| make[2]: *** [all] Error 2
| make[2]: Leaving directory 
'/home/us/build-imx6ulevk-mfgtool/tmp/work/x86_64-linux/gettext-native/0.19.4-r0/build/gettext-tools'
| Makefile:380: recipe for target 'all-recursive' failed
| make[1]: *** [all-recursive] Error 1
| make[1]: Leaving directory 
'/home/us/build-imx6ulevk-mfgtool/tmp/work/x86_64-linux/gettext-native/0.19.4-r0/build'
| Makefile:336: recipe for target 'all' failed
| make: *** [all] Error 2
| ERROR: oe_runmake failed
| ERROR: Function failed: do_compile (log file is located at 
/home/us/build-imx6ulevk-mfgtool/tmp/work/x86_64-linux/gettext-native/0.19.4-r0/temp/log.do_compile.5336)
ERROR: Task 531 
(virtual:native:/home/us/build/os-poky/meta/recipes-core/gettext/gettext_0.19.4.bb,
 do_compile) failed with exit code '1'


I already tried to reinstall libtool but without success.

Some ideas whats the cause for this error?

Best regards,

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

[yocto] [RFC][PATCH 1/1] kernel.bbclass: Do not overwrite pre/postinst

[Oliver Stäbler]

If a recipe sets a custom pre/postinst function for kernel-image, this
function gets discarded, which means there is no possibility to set a
custom pre/postinst function.

We check if there is a custom pre/postinst function and only set the
default function if nothing is set.

Signed-off-by: Oliver Stäbler <oliver.staeb...@bytesatwork.ch>
---
 meta/classes/kernel.bbclass | 10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index 2a765547ac..e553460566 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -66,11 +66,13 @@ python __anonymous () {
 d.setVar('ALLOW_EMPTY_kernel-image-' + typelower, '1')
 
 priority = d.getVar('KERNEL_PRIORITY')
-postinst = '#!/bin/sh\n' + 'update-alternatives --install /' + 
imagedest + '/' + type + ' ' + type + ' ' + type + '-${KERNEL_VERSION_NAME} ' + 
priority + ' || true' + '\n'
-d.setVar('pkg_postinst_kernel-image-' + typelower, postinst)
+if not d.getVar('pkg_postinst_kernel-image-' + typelower):
+postinst = '#!/bin/sh\n' + 'update-alternatives --install /' + 
imagedest + '/' + type + ' ' + type + ' ' + type + '-${KERNEL_VERSION_NAME} ' + 
priority + ' || true' + '\n'
+d.setVar('pkg_postinst_kernel-image-' + typelower, postinst)
 
-postrm = '#!/bin/sh\n' + 'update-alternatives --remove' + ' ' + type + 
' ' + type + '-${KERNEL_VERSION_NAME} || true' + '\n'
-d.setVar('pkg_postrm_kernel-image-' + typelower, postrm)
+if not d.getVar('pkg_postrm_kernel-image-' + typelower):
+postrm = '#!/bin/sh\n' + 'update-alternatives --remove' + ' ' 
+ type + ' ' + type + '-${KERNEL_VERSION_NAME} || true' + '\n'
+d.setVar('pkg_postrm_kernel-image-' + typelower, postrm)
 
 image = d.getVar('INITRAMFS_IMAGE')
 if image:
-- 
2.13.5

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

[yocto] [RFC][PATCH 0/1] kernel.bbclass overwrites custom variables

[Oliver Stäbler]

Hi

It seems that it's not possible to set a custom pre/postinst function for a
kernel recipe.
kernel.bbclass overwrites the necessary variables without checking its content.

My patch does fix this.
However, I'm not sure how to handle similar variables which get overwritten by
kernel.bbclass, therefore a RFC.

What about FILES_kernel_image?
A custom recipe should be able to add other files into the kernel package,
right?

What about PKG_kernel_image?
I'm not really sure what this variable is used for.

Oliver Stäbler (1):
  kernel.bbclass: Do not overwrite pre/postinst

 meta/classes/kernel.bbclass | 10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

-- 
2.13.5

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

[yocto] Setting directories permissions

[Oliver Graute]

Hello List,

I try to define a directory permission for a folder to 0775 instead of
0755 in my recipe. But somewhere in the install and packaging process
this is overwritten.

in my receipe I do this:

do_install() {
install -m 0775 -d ${D}${sysconfdir}/folder1/folder2/


I expect this on the target:

root@box:/etc/folder1# ls -la
drwxrwxr-x2 root webgrp 512 Jan  1  1970 folder2

but I get only this permissions:

root@box:/etc/folder1# ls -la
drwxr-xr-x2 root webgrp 512 Jan  1  1970 folder2


I also tried to define it in the fs-perms.txt file. But this didn't work
either.

/etc/folder1/folder2   0775rootwebgrp  false - - -

some clue how to handle such directory permissions the yocto way?


Best Regards,

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

[yocto] bitbake -c menuconfig linux-fslc in a tmux window

[Oliver Graute]

Hello list,

if I start the following command in a tmux window it doesn't work.

bitbake -c menuconfig linux-fslc

if I start this command in a extra gnome-terminal a new gnome-terminal
pops-up and I can configure my kernel related stuff.

in the poky /os-poky/meta/lib/oe/terminal.py there is some code that
indicate that it could be possible that a new tmux-pane should open here.

Some clue why bitbake does not open an extra tmux-pane for me?

I'am using yocto jethro 2.0.2.

Best Regards,

Oliver

NOTE: Executing RunQueue Tasks
ERROR: Error executing a python function in 
/home/graute/5411_IBIS/yocto/os-meta-fsl-arm/recipes-kernel/linux/linux-fslc_4.4.bb:

The stack trace of python calls that resulted in this exception/failure was:
File: 'do_menuconfig', lineno: 25, function: 
 0021:bb.note("Configuration changed, recompile will be forced")
 0022:bb.build.write_taint('do_compile', d)
 0023:
 0024:
 *** 0025:do_menuconfig(d)
 0026:
File: 'do_menuconfig', lineno: 11, function: do_menuconfig
 0007:shutil.copy(".config", ".config.orig")
 0008:except OSError:
 0009:mtime = 0
 0010:
 *** 0011:oe_terminal("/bin/bash -c \"make menuconfig; if [ \$? -ne 0 ]; 
then echo 'Command failed.'; printf 'Press any key to continue... '; read r; 
fi\"", 'linux-fslc Configuration', d)
 0012:
 0013:# FIXME this check can be removed when the minimum bitbake 
version has been bumped
 0014:if hasattr(bb.build, 'write_taint'):
 0015:try:
File: 'terminal.bbclass', lineno: 55, function: oe_terminal
 0051:except oe.terminal.ExecutionError as exc:
 0052:bb.fatal('Unable to spawn terminal %s: %s' % (terminal, 
exc))
 0053:
 0054:try:
 *** 0055:oe.terminal.spawn_preferred(command, title, None, d)
 0056:except oe.terminal.NoSupportedTerminals:
 0057:bb.fatal('No valid terminal found, unable to open devshell')
 0058:except oe.terminal.ExecutionError as exc:
 0059:bb.fatal('Unable to spawn terminal %s: %s' % (terminal, exc))
File: '/home/graute/5411_IBIS/yocto/os-poky/meta/lib/oe/terminal.py', lineno: 
199, function: spawn_preferred
 0195:def spawn_preferred(sh_cmd, title=None, env=None, d=None):
 0196:"""Spawn the first supported terminal, by priority"""
 0197:for terminal in prioritized():
 0198:try:
 *** 0199:spawn(terminal.name, sh_cmd, title, env, d)
 0200:break
 0201:except UnsupportedTerminal:
 0202:continue
 0203:else:
File: '/home/graute/5411_IBIS/yocto/os-poky/meta/lib/oe/terminal.py', lineno: 
214, function: spawn
 0210:terminal = Registry.registry[name]
 0211:except KeyError:
 0212:raise UnsupportedTerminal(name)
 0213:
 *** 0214:pipe = terminal(sh_cmd, title, env, d)
 0215:output = pipe.communicate()[0]
 0216:if pipe.returncode != 0:
 0217:raise ExecutionError(sh_cmd, pipe.returncode, output)
 0218:
File: '/home/graute/5411_IBIS/yocto/os-poky/meta/lib/oe/terminal.py', lineno: 
133, function: __init__
 0129:
 0130:if not os.getenv('TMUX'):
 0131:raise UnsupportedTerminal('tmux is not running')
 0132:
 *** 0133:if not check_tmux_pane_size('tmux'):
 0134:raise UnsupportedTerminal('tmux pane too small')
 0135:
 0136:Terminal.__init__(self, sh_cmd, title, env, d)
 0137:
File: '/home/graute/5411_IBIS/yocto/os-poky/meta/lib/oe/terminal.py', lineno: 
225, function: check_tmux_pane_size
 0221:try:
 0222:p = sub.Popen('%s list-panes -F 
"#{?pane_active,#{pane_height},}"' % tmux,
 0223:shell=True,stdout=sub.PIPE,stderr=sub.PIPE)
 0224:out, err = p.communicate()
 *** 0225:size = int(out.strip())
 0226:except OSError as exc:
 0227:import errno
 0228:if exc.errno == errno.ENOENT:
 0229:return None
Exception: ValueError: invalid literal for int() with base 10: ''

ERROR: Function failed: do_menuconfig
ERROR: Logfile of failure stored in: 
/home/graute/5411_IBIS/yocto/build-imx6ulevk-nand/tmp/work/imx6ulevk-poky-linux-gnueabi/linux-fslc/4.4+gitAUTOINC+4fa9845f9b-r0/temp/log.do_menuconfig.22623
ERROR: Task 4 
(/home/graute/5411_IBIS/yocto/os-meta-fsl-arm/recipes-kernel/linux/linux-fslc_4.4.bb,
 do_menuconfig) failed with exit code '1'

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

Re: [yocto] Use recipes but not whole layer

[Oliver]

>>> In order to success in generate recipeA, I need to extend the boost to
>>> expand some configuration parameters(log).
>>> On the other side someone would like to use recipeB. He/She will
>>> unwillingly inherit the boost modifications.
>>>
>> 
>> The changes to boost would likely count as distro policy, so shouldn't be
>> in the same layer as a generic purpose recipe.

> What boost changes? They may be of interest to others and we could
> update the recipe in oe-core.

This particular change in boost is not relevant in fact, I just used it to 
explain the example. 

But if you like to know the bbappend file just contained the line:
BOOST_LIBS += "log"
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Use recipes but not whole layer

[Oliver]

> As per the Yocto Project guidelines, layers that do this are broken.  A BSP 
> layer should only introduce changes that affect the BSP, distro layers 
> shouldn't contain general purpose recipes, and everything that is 
> distro-specific should be isolated using overrides.
I was talking more generically for any type of layer. I have the feeling that 
many layers in our ecosystem fail to accomplish this.
I believe I understand the guidelines, based on some discussions about not 
including the whitelist.bbclass in OE. 
But I find it not always possible to follow. Let me expose a very simple, and 
commom use case, a layer which contains:
recipeAboost_%.bbappend
recipeB
In order to success in generate recipeA, I need to extend the boost to expand 
some configuration parameters(log).On the other side someone would like to use 
recipeB. He/She will unwillingly inherit the boost modifications.
How should this be correctly done?
Regards







 

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

[yocto] Use recipes but not whole layer

[Oliver]

Hello,
When a layer is included in the build (conf/bblayers.conf), all the bbappends 
and distro configurations, apply to the current build. Is there something 
additional which the build is affected after a layer included?
What is the preferred way if in you are only interested in one specfic recipe 
of the new layer?
a) You could invalidate via BBMASK all the specific pathsb) Could somehow 
modify the BBFILE to remove the undesired "${LAYERDIR}/recipes-*/*/*.bbappend"?
I am not confortable with either ways, what is the official approach?
Regards

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

Re: [yocto] build ntp with openssl support

[Oliver Graute]

On 23/09/16, Lennart Sorensen wrote:
> On Fri, Sep 23, 2016 at 02:19:20PM +0200, Oliver Graute wrote:
> > On 22/09/16, Khem Raj wrote:
> > > On Thu, Sep 22, 2016 at 12:16 AM, Oliver Graute <oliver.gra...@gmail.com> 
> > > wrote:
> > > > On 19/09/16, Oliver Graute wrote:
> > > >> On 16/09/16, Andre McCurdy wrote:
> > > >> > On Fri, Sep 16, 2016 at 1:24 AM, Oliver Graute 
> > > >> > <oliver.gra...@gmail.com> wrote:
> > > >> > > Hello,
> > > >> > >
> > > >> > > how can I build ntp with openssl support?
> > > >> > >
> > > >> > > I already created a ntp_%.bbappend file to extend the recipe 
> > > >> > > ntp_4.2.8p4.bb.
> > > >> > >
> > > >> > > FILESEXTRAPATHS_prepend := "${THISDIR}/files:"
> > > >> >
> > > >> > You don't really need this line unless you are adding a file to
> > > >> > SRC_URI or replacing a file already in SRC_URI with your own version.
> > > >> >
> > > >> > > PACKAGECONFIG += "openssl"
> > > >> >
> > > >> > This will enable openssl, but it will also disable all the default
> > > >> > PACKAGECONFIG options (cap, debug and refclocks) which is probably 
> > > >> > not
> > > >> > what you want. Try this instead:
> > > >> >
> > > >> >   PACKAGECONFIG_append = " openssl"
> > > >> >
> > > >> > Note the space between " and openssl. It's required.
> > > >>
> > > >> ok now I see the right configure script options during the 
> > > >> configuration
> > > >> of the ntp build.
> > > >>
> > > >> --with-openssl-libdir=/home/graute/5411_IBIS/yocto/build-imx6ulevk-nand/tmp/sysroots/imx6ulevk/usr/lib
> > > >> --with-openssl-incdir=/home/graute/5411_IBIS/yocto/build-imx6ulevk-nand/tmp/sysroots/imx6ulevk/usr/include
> > > >> --with-crypto
> > > >>
> > > >> But ntp is still build without openssl support. The configure scripts
> > > >> can't find the relevant openssl stuff.
> > > >>
> > > >> configure:34762: checking for openssl library directory
> > > >> configure:34802: result: no
> > > >> configure:34807: WARNING: libcrypto and libssl not found in any of 
> > > >> /home/graute/5411_IBIS/yocto/build-imx6ulevk-nand/tmp/sysroots/imx6ulevk/usr/lib
> > > >> configure:34811: checking for openssl include directory
> > > >> configure:34833: result: 
> > > >> /home/graute/5411_IBIS/yocto/build-imx6ulevk-nand/tmp/sysroots/imx6ulevk/usr/include
> > > >> configure:34877: checking if we will use crypto
> > > >> configure:34879: result: no
> > > >> configure:35109: checking if we want to use OpenSSL's crypto random 
> > > >> (if available)
> > > >> configure:35119: result: yes
> > > >>
> > > >> some clue whats wrong here?
> > > >
> > > > in my sysroots/imx6ulevk/usr/lib I have
> > > >
> > > > ls -la libssl*
> > > >
> > > > libssl3.so
> > > > libssl.a
> > > > libssl.so -> libssl.so.1.0.0
> > > > libssl.so.1.0.0
> > > >
> > > > ls -la libcrypt*
> > > >
> > > > libcrypt.a
> > > > libcrypt_pic.a
> > > > libcrypt_pic.map
> > > > libcrypt.so -> ../../lib/libcrypt.so.1
> > > >
> > > >
> > > > but no libcrypto.so. I guess thats the reason why my ntp configure
> > > > script is complaining.
> > > >
> > > > Some ideas how to get libcrypto.so in my /usr/lib folder in the yocto
> > > > sysroot?
> > > >
> > > 
> > > It seems your openssl is not being compiled correctly. Can you go into
> > > builddir or openssl
> > > and see if libcrypto.so.1.0.0 is built ? if not then you have to do
> > > some digging why its not
> > > configuring to build libcrypto
> > 
> > libcrypto is build by openssl
> > 
> > openssl/1.0.2d-r0/openssl-1.0.2d$ ls -la  libcrypt*
> > libcrypto.a
> > libcrypto.pc
> > libcrypto.so -> libcrypto.so.1.0.0
> > libcrypto.so.1.0.0
> > 
> > but in my sysroot libcrypto is located in lib NO

Re: [yocto] build ntp with openssl support

[Oliver Graute]

On 22/09/16, Khem Raj wrote:
> On Thu, Sep 22, 2016 at 12:16 AM, Oliver Graute <oliver.gra...@gmail.com> 
> wrote:
> > On 19/09/16, Oliver Graute wrote:
> >> On 16/09/16, Andre McCurdy wrote:
> >> > On Fri, Sep 16, 2016 at 1:24 AM, Oliver Graute <oliver.gra...@gmail.com> 
> >> > wrote:
> >> > > Hello,
> >> > >
> >> > > how can I build ntp with openssl support?
> >> > >
> >> > > I already created a ntp_%.bbappend file to extend the recipe 
> >> > > ntp_4.2.8p4.bb.
> >> > >
> >> > > FILESEXTRAPATHS_prepend := "${THISDIR}/files:"
> >> >
> >> > You don't really need this line unless you are adding a file to
> >> > SRC_URI or replacing a file already in SRC_URI with your own version.
> >> >
> >> > > PACKAGECONFIG += "openssl"
> >> >
> >> > This will enable openssl, but it will also disable all the default
> >> > PACKAGECONFIG options (cap, debug and refclocks) which is probably not
> >> > what you want. Try this instead:
> >> >
> >> >   PACKAGECONFIG_append = " openssl"
> >> >
> >> > Note the space between " and openssl. It's required.
> >>
> >> ok now I see the right configure script options during the configuration
> >> of the ntp build.
> >>
> >> --with-openssl-libdir=/home/graute/5411_IBIS/yocto/build-imx6ulevk-nand/tmp/sysroots/imx6ulevk/usr/lib
> >> --with-openssl-incdir=/home/graute/5411_IBIS/yocto/build-imx6ulevk-nand/tmp/sysroots/imx6ulevk/usr/include
> >> --with-crypto
> >>
> >> But ntp is still build without openssl support. The configure scripts
> >> can't find the relevant openssl stuff.
> >>
> >> configure:34762: checking for openssl library directory
> >> configure:34802: result: no
> >> configure:34807: WARNING: libcrypto and libssl not found in any of 
> >> /home/graute/5411_IBIS/yocto/build-imx6ulevk-nand/tmp/sysroots/imx6ulevk/usr/lib
> >> configure:34811: checking for openssl include directory
> >> configure:34833: result: 
> >> /home/graute/5411_IBIS/yocto/build-imx6ulevk-nand/tmp/sysroots/imx6ulevk/usr/include
> >> configure:34877: checking if we will use crypto
> >> configure:34879: result: no
> >> configure:35109: checking if we want to use OpenSSL's crypto random (if 
> >> available)
> >> configure:35119: result: yes
> >>
> >> some clue whats wrong here?
> >
> > in my sysroots/imx6ulevk/usr/lib I have
> >
> > ls -la libssl*
> >
> > libssl3.so
> > libssl.a
> > libssl.so -> libssl.so.1.0.0
> > libssl.so.1.0.0
> >
> > ls -la libcrypt*
> >
> > libcrypt.a
> > libcrypt_pic.a
> > libcrypt_pic.map
> > libcrypt.so -> ../../lib/libcrypt.so.1
> >
> >
> > but no libcrypto.so. I guess thats the reason why my ntp configure
> > script is complaining.
> >
> > Some ideas how to get libcrypto.so in my /usr/lib folder in the yocto
> > sysroot?
> >
> 
> It seems your openssl is not being compiled correctly. Can you go into
> builddir or openssl
> and see if libcrypto.so.1.0.0 is built ? if not then you have to do
> some digging why its not
> configuring to build libcrypto

libcrypto is build by openssl

openssl/1.0.2d-r0/openssl-1.0.2d$ ls -la  libcrypt*
libcrypto.a
libcrypto.pc
libcrypto.so -> libcrypto.so.1.0.0
libcrypto.so.1.0.0

but in my sysroot libcrypto is located in lib NOT in usr/lib

the ntp recipe in 
meta-openembedded/meta-networking/recipes-support/ntp/ntp_4.2.8p4.bb
defines:

 --with-openssl-libdir=${STAGING_LIBDIR}

I assume I need ${STAGING_BASELIBDIR} here instead. But currently I fail
with overwriting this in my bbappend file.

If I use EXTRA_OECONF to overwrite it in my bbappend I see two 
--with-openssl-libdir
statements while configuring. The first with /lib the second one with /usr/lib. 

EXTRA_OECONF  += "\
--with-openssl \
--with-openssl-libdir=${STAGING_BASELIBDIR} \
--with-openssl-incdir=${STAGING_INCDIR} \
--with-crypto \
"

Best Regards,

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

Re: [yocto] build ntp with openssl support

[Oliver Graute]

On 19/09/16, Oliver Graute wrote:
> On 16/09/16, Andre McCurdy wrote:
> > On Fri, Sep 16, 2016 at 1:24 AM, Oliver Graute <oliver.gra...@gmail.com> 
> > wrote:
> > > Hello,
> > >
> > > how can I build ntp with openssl support?
> > >
> > > I already created a ntp_%.bbappend file to extend the recipe 
> > > ntp_4.2.8p4.bb.
> > >
> > > FILESEXTRAPATHS_prepend := "${THISDIR}/files:"
> > 
> > You don't really need this line unless you are adding a file to
> > SRC_URI or replacing a file already in SRC_URI with your own version.
> > 
> > > PACKAGECONFIG += "openssl"
> > 
> > This will enable openssl, but it will also disable all the default
> > PACKAGECONFIG options (cap, debug and refclocks) which is probably not
> > what you want. Try this instead:
> > 
> >   PACKAGECONFIG_append = " openssl"
> > 
> > Note the space between " and openssl. It's required.
> 
> ok now I see the right configure script options during the configuration
> of the ntp build.
> 
> --with-openssl-libdir=/home/graute/5411_IBIS/yocto/build-imx6ulevk-nand/tmp/sysroots/imx6ulevk/usr/lib
> --with-openssl-incdir=/home/graute/5411_IBIS/yocto/build-imx6ulevk-nand/tmp/sysroots/imx6ulevk/usr/include
> --with-crypto
> 
> But ntp is still build without openssl support. The configure scripts
> can't find the relevant openssl stuff.
> 
> configure:34762: checking for openssl library directory
> configure:34802: result: no
> configure:34807: WARNING: libcrypto and libssl not found in any of 
> /home/graute/5411_IBIS/yocto/build-imx6ulevk-nand/tmp/sysroots/imx6ulevk/usr/lib
> configure:34811: checking for openssl include directory
> configure:34833: result: 
> /home/graute/5411_IBIS/yocto/build-imx6ulevk-nand/tmp/sysroots/imx6ulevk/usr/include
> configure:34877: checking if we will use crypto
> configure:34879: result: no
> configure:35109: checking if we want to use OpenSSL's crypto random (if 
> available)
> configure:35119: result: yes
> 
> some clue whats wrong here?

in my sysroots/imx6ulevk/usr/lib I have

ls -la libssl*

libssl3.so
libssl.a
libssl.so -> libssl.so.1.0.0
libssl.so.1.0.0

ls -la libcrypt*

libcrypt.a
libcrypt_pic.a
libcrypt_pic.map
libcrypt.so -> ../../lib/libcrypt.so.1


but no libcrypto.so. I guess thats the reason why my ntp configure
script is complaining.

Some ideas how to get libcrypto.so in my /usr/lib folder in the yocto
sysroot?

some explenation whats the difference between libcrypt.so and libcrypto.so?

Best Regards,

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

Re: [yocto] build ntp with openssl support

[Oliver Graute]

On 16/09/16, Andre McCurdy wrote:
> On Fri, Sep 16, 2016 at 1:24 AM, Oliver Graute <oliver.gra...@gmail.com> 
> wrote:
> > Hello,
> >
> > how can I build ntp with openssl support?
> >
> > I already created a ntp_%.bbappend file to extend the recipe ntp_4.2.8p4.bb.
> >
> > FILESEXTRAPATHS_prepend := "${THISDIR}/files:"
> 
> You don't really need this line unless you are adding a file to
> SRC_URI or replacing a file already in SRC_URI with your own version.
> 
> > PACKAGECONFIG += "openssl"
> 
> This will enable openssl, but it will also disable all the default
> PACKAGECONFIG options (cap, debug and refclocks) which is probably not
> what you want. Try this instead:
> 
>   PACKAGECONFIG_append = " openssl"
> 
> Note the space between " and openssl. It's required.

ok now I see the right configure script options during the configuration
of the ntp build.

--with-openssl-libdir=/home/graute/5411_IBIS/yocto/build-imx6ulevk-nand/tmp/sysroots/imx6ulevk/usr/lib
--with-openssl-incdir=/home/graute/5411_IBIS/yocto/build-imx6ulevk-nand/tmp/sysroots/imx6ulevk/usr/include
--with-crypto

But ntp is still build without openssl support. The configure scripts
can't find the relevant openssl stuff.

configure:34762: checking for openssl library directory
configure:34802: result: no
configure:34807: WARNING: libcrypto and libssl not found in any of 
/home/graute/5411_IBIS/yocto/build-imx6ulevk-nand/tmp/sysroots/imx6ulevk/usr/lib
configure:34811: checking for openssl include directory
configure:34833: result: 
/home/graute/5411_IBIS/yocto/build-imx6ulevk-nand/tmp/sysroots/imx6ulevk/usr/include
configure:34877: checking if we will use crypto
configure:34879: result: no
configure:35109: checking if we want to use OpenSSL's crypto random (if 
available)
configure:35119: result: yes

some clue whats wrong here?

Best regards,

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

[yocto] build ntp with openssl support

[Oliver Graute]

Hello,

how can I build ntp with openssl support?

I already created a ntp_%.bbappend file to extend the recipe ntp_4.2.8p4.bb.

FILESEXTRAPATHS_prepend := "${THISDIR}/files:"
PACKAGECONFIG += "openssl"

is this sufficant to enable openssl?

How can I determine if ntp supports sha1?

Best regards,

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

Re: [yocto] Can't replace login.defs with shadow-sysroot bbappend

[Oliver Graute]

On 28/07/16, Zhenhua Luo wrote:
> Hi Oliver, 
> 
> The following line in shadow-sysroot.bb disables the final binary packages 
> generation. You can try to add bbappend for shadow to do the customization. 
> 
> # don't create any packages
> # otherwise: dbus-dev depends on shadow-sysroot-dev which depends on 
> shadow-sysroot
> # and this has another copy of /etc/login.defs already provided by shadow
> PACKAGES = ""

thx for this usefull note. It works for me with shadow_%.bbappend.

FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"

SRC_URI += "file://login.defs"

do_install_append() {
install -m 644 ${WORKDIR}/login.defs ${D}${sysconfdir}/login.defs
}

FILES_${PN} += "${sysconfdir}/login.defs"

Best regards,

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

[yocto] Can't replace login.defs with shadow-sysroot bbappend

[Oliver Graute]

Hello list,

i'm trying to replace /etc/login.defs on the target with my own one. So
I created a shadow-sysroot_%.bbappend file with this content:

FILESEXTRAPATHS_prepend := "${THISDIR}/${BPN}:"

# As we're overriding login.defs_shadow-sysroot we have to readd the checksum 
for it here
# as it's containing the license for this component
LIC_FILES_CHKSUM = 
"file://login.defs_shadow-sysroot;md5=286ba0946b3b8a300da3893d7b3af060"

SRC_URI_append = " file://login.defs_shadow-sysroot "

S = "${WORKDIR}"

do_install_append() {
install -d ${D}${sysconfdir}
install -p -m 755 ${S}/login.defs_shadow-sysroot 
${D}${sysconfdir}/login.defs
}

FILES_${PN} = "${D}${sysconfdir}/login.defs"


If I run "bitbake shadow-sysroot" everything seems fine. But on the target
there is no package shadow-sysroot after a complete image build. Just these:

opkg list  | grep shadow
shadow - 4.2.1-r0
shadow-base - 4.2.1-r0
shadow-securetty - 4.2.1-r3

If I explicit added shadow-sysroot to my fsl-image.bb where I put all my
other packages for the target in I get this error.

bitbake fsl-image

Collected errors:
 * opkg_prepare_url_for_install: Couldn't find anything to satisfy 
'shadow-sysroot'.

ERROR: Function failed: do_rootfs


Some clue what is wrong here? I'am on jethro yocto branch.

Best regards,

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

Re: [yocto] Howto change the default shell in yocto?

[Oliver Graute]

On 05/03/16, Burton, Ross wrote:
> On 5 March 2016 at 11:48, Oliver Graute <oliver.gra...@gmail.com> wrote:
> 
> > first the default *system* shell (/bin/sh) is this possible? or does this
> > affect
> > to much of the yoco system itself, if I change /bin/sh to /bin/dash?
> >
> 
> bash is only the default shell (ie symlink from /bin/sh) if you install it,
> so if you don't want bash to be sh then one option is to not install bash.
> 
> If you do want to keep bash installed but change the sh link, then that is
> managed with update-alternatives.

> 
ok thx, if I do

update-alternatives  --install /bin/sh sh /bin/dash 100

on the target it works.

Best Regards,

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

Re: [yocto] Howto change the default shell in yocto?

[Oliver Graute]

On 04/03/16, Christopher Larson wrote:
> The default *system* shell (/bin/sh) or the default shell for users, or for
> root? Folks often conflate them, but they're not the same.

first the default *system* shell (/bin/sh) is this possible? or does this affect
to much of the yoco system itself, if I change /bin/sh to /bin/dash?

the alternative for me is to just change the default shell for normal
users and the root user. I assume its done via /etc/passwd. But how I adapt
these the yocto way? 

Best regards,

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

[yocto] Howto change the default shell in yocto?

[Oliver Graute]

Hello,

how can I change the default shell on the yocto target from bash to
another shell like dash?

is there a variable for local.conf? or do I need to adapt my passwd for
every user?

Best Regards,

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

Re: [yocto] Source for recipe on local drive

[Oliver]

Additionally, I use the following sentence to get directly the location where 
these sources are:

bitbake  -e | grep "^WORKDIR="

 

El Viernes 26 de febrero de 2016 16:00, "Burton, Ross" 
 escribió:
 

 


On 26 February 2016 at 14:55, Marius Liebenberg  wrote:

How do I get all the source code for a specific recipe onto my local drive. 
That is without sifting through all the config files to try and get url's


"bitbake [recipe] -c fetch" will just run the fetch task. 
Ross
-- 
___
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] [meta-chip][PATCH] added md5 for ntc's modified u-boot Licences/README file.

[Oliver]

Not yet @Valentin, This is in my TODO list. I did spend an afternoon checking 
for their scripts inside the SDK at least to retrieve a backup copy of the 
oficial firmware. I guess this is the starting point to work out something 
within yocto:
https://github.com/NextThingCo/CHIP-tools/blob/chip/stable/chip-update-firmware.sh


 

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

Re: [yocto] Post Generation of debug information

[Oliver]

In this special case the tool is Lauterbach's Trace32. 

If I understand properly each piece of output I would eventually need, I would 
need to modify its origin recipes to ensure they deploy the such files in 
DEPLOY_DIR_IMAGE/SOME_WHERE. There I could proceed in a similar way as the 
image_types classes.
Paths are the first motivation, but physical addresses, offsets configurations 
which might could only be fetched from grepping the code could be next. Ideally 
I would not like to modify others recipes.
In a more generic way, is there a way a recipe accesses variables of other 
recipes?


El Lunes 22 de febrero de 2016 19:46, Khem Raj <raj.k...@gmail.com> 
escribió:
 

 On Mon, Feb 22, 2016 at 7:41 AM, Oliver <urne...@yahoo.es> wrote:
> I have the need to generate some scripts for a debugger tool. As a first
> approach, these generated scripts could contain paths on where specific
> binary files are stored on the file system.
>
> Such purpose has been partially fulfilled with a recipe implementing the
> do_compile task to generate those files, assuming not implementing the
> deploying tasks, nothing gets integrated in the final image.
>
> Therefore the debugger tool could go to build/work/temp/…/myrecipe/…
> (WORKDIR of the recipe) as a startpoint for such scripts.
>
> 2 Questions:
>
> -          There would be a better solution for this task?
> -          The task has not been as successfully as expected. Ideally I
> would access variables of other recipes to know where they are their
> output/intermediate files. E.g. location of an elf file for u-boot. Is there
> any way around this?
>

There are ways implemented e.g. you can generate an image tarball in two pieces
1. binaries
2. Associated debug info and symbols

The untar both in same place.

Point your cross gdb to this location via setting appropriate sysroot
in .gdbinit
and that will be it.

However its not clear if thats what you are looking for. If you want to point to
components build directory instead of a full rootfs then you have to enhacne
the .gdbinit a bit more.

I am assuming that gdb is the debugging tool you are trying to use

> Regards
>
> --
> ___
> 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] Post Generation of debug information

[Oliver]

I have the need to generate some scripts for a debuggertool. As a first 
approach, these generated scripts could contain paths on wherespecific binary 
files are stored on the file system. 


 
Such purpose has been partially fulfilled with a recipe implementingthe 
do_compile task to generate those files, assuming not implementing thedeploying 
tasks, nothing gets integrated in the final image. 


 
Therefore the debugger tool could go to build/work/temp/…/myrecipe/… (WORKDIR 
of the recipe) as a startpointfor such scripts.


 
2 Questions:


 
- There would be a better solution for this task?

- The task has not been as successfully asexpected. Ideally I would 
access variables of other recipes to know where theyare their 
output/intermediate files. E.g. location of an elf file for u-boot.Is there any 
way around this?


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

Re: [yocto] [meta-chip][PATCH] added md5 for ntc's modified u-boot Licences/README file.

[Oliver]

I faced the same problem locally, the u-boot.inc tends to check the in a file 
which is not present anymore in the repository of Next Thing Co.
Though I just check for the header of the file:
+LIC_FILES_CHKSUM = 
"file://README;beginline=1;endline=22;md5=2687c5ebfd9cb284491c3204b726ea29"

    
 

El Domingo 21 de febrero de 2016 13:30, Valentin Le bescond 
 escribió:
 

 

Hi, sorry it was my first (tiny) try at a contribution ... Should I have 
explained more in the title ?

Next Thing Co changed the Licences/README file in their repo.
And in the u-boot.inc file used by u-boot-chip, this file is chekced with 
LIC_FILES_CHKSUM. And so it doesn't build without a modification of the md5.
That's it !


Le sam. 20 févr. 2016 à 20:09, Khem Raj  a écrit :

On Sat, Feb 20, 2016 at 8:25 AM, Valentin LE BESCOND
 wrote:
> From: Nitnelav 
>
> Signed-off-by: Nitnelav 
> ---
>  recipes-bsp/u-boot/u-boot-chip_git.bb | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/recipes-bsp/u-boot/u-boot-chip_git.bb 
> b/recipes-bsp/u-boot/u-boot-chip_git.bb
> index 2342478..0b9032f 100644
> --- a/recipes-bsp/u-boot/u-boot-chip_git.bb
> +++ b/recipes-bsp/u-boot/u-boot-chip_git.bb
> @@ -8,6 +8,8 @@ PROVIDES += "u-boot"
>  UBOOT_VERSION ?= "2015.07"
>  PV = "${UBOOT_VERSION}+git${SRCPV}"
>
> +LIC_FILES_CHKSUM = 
> "file://Licenses/README;md5=0507cd7da8e7ad6d6701926ec9b84c95"
> +

while checksumming more is merrier, it would be good to know why we
should check for this one ?

>  SRCREV ?= "854d5fcc641d8d8914c03a69d7172815d5b81a99"
>  BRANCH ?= "chip/stable"
>  SRC_URI = "git://github.com/NextThingCo/CHIP-u-boot.git;branch=${BRANCH}"
> --
> 1.9.1
>
> --
> ___
> 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 mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] dtb filename mismatch prevents booting

[Oliver Graute]

Hello list,

if I try to boot from my yocto generated SD-card image my u-boot can't
start the kernel because the imx6ul-14x14-evk.dtb is missing.


reading boot.scr
** Unable to read file boot.scr **
reading zImage
5072288 bytes read in 328 ms (14.7 MiB/s)
Booting from mmc ...
reading imx6ul-14x14-evk.dtb
** Unable to read file imx6ul-14x14-evk.dtb **
Kernel image @ 0x8200 [ 0x00 - 0x4d65a0 ]

Starting kernel ...


In my /boot folder I saw a dtb file, but the filename is a bit different.

zImage-imx6ul-14x14-evk.dtb instead of imx6ul-14x14-evk.dtb

So I changed these filename manually and my Image is booting.

mv zImage-imx6ul-14x14-evk.dtb imx6ul-14x14-evk.dtb
»zImage-imx6ul-14x14-evk.dtb“ -> »imx6ul-14x14-evk.dtb“

What is the right way to define these dtb filename?

I saw the IMAGE_BOOT_FILES in local.conf

#IMAGE_BOOT_FILES = "zImage zImage-imx6ul-14x14-evk.dtb"
IMAGE_BOOT_FILES = "zImage imx6ul-14x14-evk.dtb"

but after I changed it my build fails.

ERROR: Error: The image creation script 
'/home/graute/5411_IBIS/yocto/build-imx6ulevk/tmp/work/imx6ulevk-poky-linux-gnueabi/fsl-image/1.0-r0/temp/create_image.wic'
 returned 1:
Error: exec_cmd: install -m 0644 -D 
/home/graute/5411_IBIS/yocto/build-imx6ulevk/tmp/deploy/images/imx6ulevk/imx6ul-14x14-evk.dtb
 
/home/graute/5411_IBIS/yocto/build-imx6ulevk/tmp/deploy/images/imx6ulevk/fsl-image-imx6ulevk-20160208144228/build/boot/imx6ul-14x14-evk.dtb
 returned '1' instead of 0
Checking basic build environment...
Done.

Creating image(s)...

WARNING: 
/home/graute/5411_IBIS/yocto/build-imx6ulevk/tmp/work/imx6ulevk-poky-linux-gnueabi/fsl-image/1.0-r0/temp/create_image.wic:1
 exit 1 from
  BUILDDIR=/home/graute/5411_IBIS/yocto/build-imx6ulevk wic create $wks --vars 
/home/graute/5411_IBIS/yocto/build-imx6ulevk/tmp/sysroots/imx6ulevk/imgdata/ -e 
fsl-image -o $out/

ERROR: Function failed: do_rootfs
ERROR: Logfile of failure stored in: 
/home/graute/5411_IBIS/yocto/build-imx6ulevk/tmp/work/imx6ulevk-poky-linux-gnueabi/fsl-image/1.0-r0/temp/log.do_rootfs.17681
ERROR: Task 7 
(/home/graute/5411_IBIS/yocto/os-meta-dnt/meta-fsl/recipes-fsl/images/fsl-image.bb,
 do_rootfs) failed with exit code '1'

some ideas whats going wrong here?

Best regards,

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

Re: [yocto] wic adds wrong mount lines to my fstab

[Oliver Graute]

On Wed, Feb 10, 2016 at 11:19 AM, Ed Bartosh <ed.bart...@linux.intel.com> wrote:
> Hi Oliver,
>
> On Tue, Feb 09, 2016 at 09:29:16AM +0100, Oliver Graute wrote:
>> # It uses SPL and u-boot
>> #
>> # The disk layout used is:
>> #  - - - --  - -- 
>> # | | SPL | u-boot  |  /boot1  | /boot2 | rootfs1 | rootfs2  |data|
>> #  - - - --  - -- 
>> # ^ ^ ^ ^ ^  ^
>> # | | | | |  |
>> # 0 1kiB  69kiB 4MiB   4MiB + 20MiB4MiB + 8Mib + rootfs1 + rootfs2 + 
>> data
>> #
>> part SPL --source rawcopy --sourceparams="file=SPL" --ondisk mmcblk 
>> --no-table --align 1
>> part u-boot --source rawcopy --sourceparams="file=u-boot.img" --ondisk 
>> mmcblk --no-table --align 69
>> part /boot --source bootimg-partition --ondisk mmcblk --fstype=vfat --label 
>> boot --active --align 4096 --size 20M --extra-space 0
>> #part /boot2 --source bootimg-partition --ondisk mmcblk --fstype=vfat 
>> --label boot2 --active --align 4096 --size 8M --extra-space 0
>> part / --source rootfs --ondisk mmcblk --fstype=ext3 --label root --align 4 
>> --size 125
>> part /rescue --source rootfs --ondisk mmcblk --fstype=ext3 --label secondary 
>> --align 4 --size 125
>> part /data --ondisk mmcblk --fstype=ext3 --label data --align 4 --size 730
>>
>> Some sugesstions to fix this?
> How exactly wic complains if you use --ondisk mmcblk0 ?
>
> It worked for me with this .wks:
> part /boot --source bootimg-pcbios --ondisk mmcblk0 --label boot --active 
> --align 1024
> part / --source rootfs --ondisk mmcblk0 --fstype=ext3 --label root --align 
> 1024
> part /rescue --source rootfs --ondisk mmcblk0 --fstype=ext3 --label secondary 
> --align 4 --size 125
> part /data --ondisk mmcblk0 --fstype=ext3 --label data --align 4 --size 730
>
> bootloader --timeout=0 --append="rootwait rootfstype=ext3 console=tty0"
>
> and produced these 2 lines in fstab:
> /dev/mmcblk0p3  /rescue ext3defaults0   0
> /dev/mmcblk0p5  /data   ext3defaults0   0
>
> If you provide more info about your setup(layers used?) I can try to
> reproduce it and fix the issue.
> Creating bug in https://bugzilla.yoctoproject.org would be great too.

Hello Ed,

it is working now with --ondisk mmcblk0. I'am not sure why it didn't
worked before. I can't reproduce it anymore. Thx for your help and sorry
for the noise.

best regards,

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

Re: [yocto] dtb filename mismatch prevents booting

[Oliver Graute]

On 10/02/16, Maciej Borzecki wrote:
> 
> > Dnia 10 luty 2016 o 17:16 Oliver Graute <oliver.gra...@gmail.com> 
> > napisał(a):
> >
> >
> > Hello list,
> >
> > if I try to boot from my yocto generated SD-card image my u-boot can't
> > start the kernel because the imx6ul-14x14-evk.dtb is missing.
> >
> >
> > reading boot.scr
> > ** Unable to read file boot.scr **
> > reading zImage
> > 5072288 bytes read in 328 ms (14.7 MiB/s)
> > Booting from mmc ...
> > reading imx6ul-14x14-evk.dtb
> > ** Unable to read file imx6ul-14x14-evk.dtb **
> > Kernel image @ 0x8200 [ 0x00 - 0x4d65a0 ]
> >
> > Starting kernel ...
> >
> >
> > In my /boot folder I saw a dtb file, but the filename is a bit different.
> >
> > zImage-imx6ul-14x14-evk.dtb instead of imx6ul-14x14-evk.dtb
> >
> > So I changed these filename manually and my Image is booting.
> >
> > mv zImage-imx6ul-14x14-evk.dtb imx6ul-14x14-evk.dtb
> > »zImage-imx6ul-14x14-evk.dtb“ -> »imx6ul-14x14-evk.dtb“
> >
> > What is the right way to define these dtb filename?
> >
> > some ideas whats going wrong here?
> >
> 
> IIRC the usual way was to add kernel-devicetree package and let u-boot
> pick the proper dtb during boot.
> 
> As for IMAGE_BOOT_FILES, you can tell wic to automatically rename files
> by passing the desired name after a semicolon like this:
> 
>   IMAGE_BOOT_FILES = "zImage zImage-imx6ul-14x14-evk.dtb;mx6ul-14x14-evk.dtb"

ok that worked for me, I changed it like this

-IMAGE_BOOT_FILES = "zImage zImage-imx6ul-14x14-evk.dtb"
+IMAGE_BOOT_FILES = "zImage zImage-imx6ul-14x14-evk.dtb;imx6ul-14x14-evk.dtb"

now the Image is directly booting without manually renaming.

thx for your help

Best Rgeards,

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

[yocto] wic adds wrong mount lines to my fstab

[Oliver Graute]

Hello list,

I am using wic to generate partitioned yocto images. After I boot such
an Image, I see two added entrys in my /etc/fstab wich are not correct.

cat /etc/fstab
#
# /etc/fstab: static file system information
#
#  

/dev/root   / auto defaults1  1
proc/proc proc defaults0  0
devpts  /dev/pts  devpts   mode=0620,gid=5 0  0
usbdevfs/proc/bus/usb usbdevfs noauto  0  0

/dev/mmcblk0p5  /rwfs auto defaults0  0
#/dev/mmcblk0p3  /rescue   ext3 defaults0  0
/dev/mmcblk0p5  /data ext3 defaults0  0

tmpfs   /run  tmpfsmode=0755,nodev,nosuid,strictatime 0 
 0
tmpfs   /var/volatile tmpfsdefaults0  0
tmpfs   /var/cachetmpfsdefaults0  0
tmpfs   /var/lib  tmpfsdefaults0  0
tmpfs   /var/spooltmpfsdefaults0  0
tmpfs   /var/apache2/logs tmpfsdefaults0  0
/dev/mmcblkp3   /rescue ext3defaults0   0
/dev/mmcblkp5   /data   ext3defaults0   0

the last two lines are added by the wic tool. Here is the 0 missing. If
I add these 0 to my wks --ondisk mmcblk option wic is complaining. So I`am
just using is like in this wks disk layout:

# short-description: Create SD card image with a boot partition
# long-description:
# Create an image that can be written onto a SD card using dd for use
# with i.MX SoC family.
# It uses SPL and u-boot
#
# The disk layout used is:
#  - - - --  - -- 
# | | SPL | u-boot  |  /boot1  | /boot2 | rootfs1 | rootfs2  |data|
#  - - - --  - -- 
# ^ ^ ^ ^ ^  ^
# | | | | |  |
# 0 1kiB  69kiB 4MiB   4MiB + 20MiB4MiB + 8Mib + rootfs1 + rootfs2 + 
data
#
part SPL --source rawcopy --sourceparams="file=SPL" --ondisk mmcblk --no-table 
--align 1
part u-boot --source rawcopy --sourceparams="file=u-boot.img" --ondisk mmcblk 
--no-table --align 69
part /boot --source bootimg-partition --ondisk mmcblk --fstype=vfat --label 
boot --active --align 4096 --size 20M --extra-space 0
#part /boot2 --source bootimg-partition --ondisk mmcblk --fstype=vfat --label 
boot2 --active --align 4096 --size 8M --extra-space 0
part / --source rootfs --ondisk mmcblk --fstype=ext3 --label root --align 4 
--size 125
part /rescue --source rootfs --ondisk mmcblk --fstype=ext3 --label secondary 
--align 4 --size 125
part /data --ondisk mmcblk --fstype=ext3 --label data --align 4 --size 730

Some sugesstions to fix this?

Best regards,

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

[yocto] Kernel config fragments not applied (requiring linux-yocto.inc)

[Oliver]

Hello,
I have a simple recipe intending to change the configuration of the raspberrypi 
kernel(meta-raspberrypi).By requiring 
linux-yocto.inc:http://git.yoctoproject.org/cgit/cgit.cgi/meta-raspberrypi/tree/recipes-kernel/linux/linux.inc#n8I
 understand it will incorporate the fragment kernel features. Which might be my 
first misunderstanding.

My recipe looks like:###FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
SRC_URI += "file://rndis.cfg"
###
and the fragment file rndis.cfg:###FILESEXTRAPATHS_prepend := 
"${THISDIR}/${PN}:"
SRC_URI += "file://rndis.cfg"
###
The configuration does not get into any .config.The only log I could get is the 
following file, it makes me think somehow that at least, it is trying. Recipe & 
fragment file is recognized.
Note that I have tried the same configuration via menuconfig and it works fine, 
so the fragment seems to me valid:
~/raspberry/build-rpi-base/tmp/work/raspberrypi-poky-linux-gnueabi/linux-raspberrypi/3.12.26+gitf0[...]/linux/.meta/cfg/standard/raspberrypi/merge_log.txt#
Using .meta/cfg/linux-raspberrypi/defconfig.sanitized as base
Merging .meta/cfg/linux-raspberrypi/rndis.cfg.sanitized
  HOSTCC  scripts/basic/fixdep
  GEN 
/home/oliver/raspberry/build-rpi-base/tmp/work/raspberrypi-poky-linux-gnueabi/linux-raspberrypi/3.12.26+gitf03cd5e1012d3fe8314a944879308cf0f3d9e29b-r0/linux-raspberrypi-standard-build/Makefile
  HOSTCC  scripts/kconfig/conf.o
  SHIPPED scripts/kconfig/zconf.tab.c
  SHIPPED scripts/kconfig/zconf.lex.c
  SHIPPED scripts/kconfig/zconf.hash.c
  HOSTCC  scripts/kconfig/zconf.tab.o
  HOSTLD  scripts/kconfig/conf
scripts/kconfig/conf --allnoconfig Kconfig
#
# configuration written to .config
#
Value requested for CONFIG_NET_CDCETHER not in final .config
Requested value:  CONFIG_NET_CDCETHER=y
Actual value: 

Value requested for CONFIG_NET_RNDIS_HOST not in final .config
Requested value:  CONFIG_NET_RNDIS_HOST=y
Actual value: 
###

Any hint how can I dig more into this problem?

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

Re: [yocto] recipe removing (some)contents of /etc

[Oliver]

 The recommended way is to use CORE_IMAGE_EXTRA_INSTALL.

Ok, this one worked! thanks


 I have other recipes(not *.bbappend) which end up in the image without 
 adding any explicit statement, just the fact of being part of the layer 
 includes them, is there any explanation?
 Something must cause them to be included, either explicitly or implicitly.


Therefore if it is included implicitly involves dependencies or requirements by 
other recipes.

 What package(s) in particular are you asking about?


Both components were simple recipes created by my own.

I have discovered the root of my confusion, I had a Hello World recipe in my 
layer, which was in the image, hence I thought It was included implicitly. 

But I was wrong, /usr/bin/hello was already in the default image, some other 
layer/recipe adds it.

Whats the experts' way to find out the origin of a deployed file?

Hopefully there is a faster way than searching whole $BUILD/tmp/work

Thanks again

-- 

Gary Thomas |  Consulting for the
MLB Associates  |Embedded world


-- 
___
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 removing (some)contents of /etc

[Oliver]

Hello
I have the below's simple recipe(starting a script in sysV runlevel 2), but 
when I add it to the image with 
IMAGE_INSTALL += canloggerin my local.conf, most of the contents of /etc gets 
removed/overwritten making the system unbootable.

Does someone sees something wrong?

#
DESCRIPTION = Start CAN services logging
SECTION = examples
LICENSE = MIT
LIC_FILES_CHKSUM = 
file://${COMMON_LICENSE_DIR}/MIT;md5=0835ade698e0bcf8506ecda2f7b4f302
PR = r0

SRC_URI += file://canlogger

INITSCRIPT_NAME = canlogger
INITSCRIPT_PARAMS = start 98 2 .

do_install() {
    install -d ${D}${sysconfdir}/init.d/
    install -m 0755 ${WORKDIR}/canlogger ${D}${sysconfdir}/init.d/canlogger
}

inherit update-rc.d
#
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] recipe removing (some)contents of /etc

[Oliver]

 What image are you building?

it is a Freescale iMX6 target, the image name is exactly a fsl-image-qt5 with a 
playground layer

 You should probably use this line instead
CORE_IMAGE_EXTRA_INSTALL = canlogger

 There is CORE_IMAGE_EXTRA_INSTALL though which you can add to with += (since 
 there aren't any default items in it, unlike IMAGE_INSTALL).


My understanding these are the preferred options

   IMAGE_INSTALL_append = “ canlogger”

But would this still do? (just for my self-learning)

I have other recipes(not *.bbappend) which end up in the image without adding 
any explicit statement, just the fact of being part of the layer includes them, 
is there any explanation?

I am still missing something to get the whole picture...

Thanks a lot for the detailed explanations
best Regards
Oliver
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [meta-raspberrypi] meta-ivi meta-raspberrypi

[Oliver]

Hello

I have been working building together the meta-raspberrypi  the meta-ivi 
layers.
I have been stuck with configuration/compilation of weston(from mata-ivi layer):

1)

You can check the intial thread 
http://lists.genivi.org/pipermail/genivi-meta-ivi/2015-April/000508.html


egl provided by userlad is not detected as the *.pc files are not deployed
Someone has faced similar problems:

   
http://git.buildroot.net/buildroot/commit/?id=2282b93f4248a32de84805456efa352f69b28624

2)
With this I am able to reach the do_compile stage but there are errors related 
to the undefined type

PFNEGLQUERYWAYLANDBUFFERWL
Hacked this one forcing the inclusion of weston-egl-ext.h :-S


3)
At linking time the next trouble is:

/home/oliver/raspberry/build-rpi-ivi/tmp/sysroots/i686-linux/usr/libexec/arm-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/4.9.1/ld:
 cannot find -lwayland-egl

IIRC this lib is provided by mesa-gl, but in my build, mesa is 
configured(--disable-egl (is this ok being provided by userlad?)) which might 
be the reason why libwayland-egl is not getting deployed in the image?

Any correction to my statements or hint to go further would be appreciated

Best Regards  thanks for your time

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

[yocto] Mount options for /dev/root

[Oliver Stäbler]

Hi

I'm trying to add some mount options to / (/dev/root) such as
'nobarrier'.

What would be the best way to define this option?

I know two possible ways:
* rootflags boot paramenter, but I'd prefer it to be in userspace
* /etc/fstab, but these options are not passed to mount. The script
/etc/init.d/checkroot.sh does parse fstab and even saves the options
($rootopts), but these options are not passed to the mount command.
Other implementation, such as debians checkroot.sh, do pass these
options to mount. Is this by intention or a bug?

Thanks  Regards,
Oliver

-- 
bytes at work
Technoparkstrasse 7
CH-8406 Winterthur
Switzerland

phone: +41 52 213 79 79
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Recommended Hardware for building

[Oliver Novakovic]

Thanks a lot for all of the information so far. This will give me a good
starting point on configuring a build server or PC.

 

Basically, the image itself is very basic, but it does include the
complete QT5 release including QTWebkit which seems to be the most
demanding to build.

The rest are smaller support packages for connectivity and a QML based
HMI.

 

Thanks again,

Oliver

 

From: Bryan Evenson beven...@melinkcorp.com [mailto:Bryan Evenson
beven...@melinkcorp.com] 
Sent: Freitag, 3. Oktober 2014 14:48
To: Martin Jansa martin.ja...@gmail.com; Chris Tapp
opensou...@keylevel.com; oliver.novako...@alpine.de
oliver.novako...@alpine.de
Cc: yocto@yoctoproject.org yocto@yoctoproject.org
Subject: RE: [yocto] Recommended Hardware for building

 


Oliver, 

 -Original Message- 
 From: yocto-boun...@yoctoproject.org [mailto:yocto- 
 boun...@yoctoproject.org] On Behalf Of Martin Jansa 
 Sent: Thursday, October 02, 2014 3:09 PM 
 To: Chris Tapp 
 Cc: yocto@yoctoproject.org 
 Subject: Re: [yocto] Recommended Hardware for building 
 
 On Thu, Oct 02, 2014 at 05:51:29PM +0100, Chris Tapp wrote: 
  
  On 2 Oct 2014, at 11:04, Burton, Ross wrote: 
  
   On 2 October 2014 10:36, Oliver Novakovic 
 wrote: 
   Can anyone recommend a reasonable performant hardware setup to 
 use ? 
   
   What should be considered ? Are there any pitfalls ? What about 
   bottlenecks in the build system ? 
 
 you should start by saying what you're going to build, my experience
is quite 
 different when building small images like console-image or even
x11-image 
 and big images/feeds which contain whole qt5 stack, 3 webkits and 
 2 chromium builds. 

Agreed, what you are building and what your goals are makes a difference
in what you need. I have a build machine setup that is mainly used to
verify everything builds correctly after committing changes. It's an
Intel i3-3220 with 8GB RAM. The autobuilder is setup on a Linux VM which
is given 4GB RAM and does not recognize the extra Hyper-threaded cores,
meaning it acts as a dual core machine. Rebuild of my console image
typically takes under 20 minutes, and most of that time is
packaging/install. After the initial build, there really isn't much for
my system that needs to get rebuilt between commits. 

So if you are looking for a build machine that is outside your normal
workflow, a $400 PC may be enough for you. If this machine is for your
development build and you have a have a lot of graphic applications that
you need to build, you may want something more in line with what other
people are suggesting. 

Regards, 
Bryan 

 
 In general: bitbake will better utilize all available performance with
bigger 
 image (e.g. build time for console image won't change so much if you
go from 
 8 cores to 24, but building e.g. just webkit alone will be more than
twice 
 faster on 24 cores). 
 
 Regards, 
 
   Specifically: 
   
   How many cores are recommended ? And how much cache is necessary 
 ? 
   How much of the main memory does Yocto really use ? Is 32 GB 
   sufficient or should I go for 64 ? 
   
   Does it make sense to use two SSDs as Raid0 to get builds faster
? 
   
   As much of everything as you can afford. :) The build isn't heavy 
   in any particular metric, so don't sacrifice RAM for SSDs for
example. 
   
   RAID 0 over SSD would be nice and fast, but I prefer having a good
   amount of RAM and a tuned ext4 (no journal, long commit delay) so 
   data doesn't actually hit the disk as frequently. Keeping the
actual 
   build directories on a separate disk is good for performance and
not 
   causing data loss when you lose a disk. 
   
   There are people that have 64GB in machines and then set TMPDIR to
a 
   tmpfs. Surprisingly this isn't that much faster (5% or so), but 
   it's a lot easier on the hardware and power consumption. 
  
  My experience: 
  
  I've got a quad core with hyper-threading (so 8 usable cores)
running at 
 about 3.8 GHz, 16GB of RAM and use multiple SSDs - one to hold the
meta 
 data, downloads and top level build areas (local.conf, etc) and have
the 
 TMPDIR on a second SSD (so, as Ross says, I don't get a surprise when
it 
 wears out!). 
  
  I can build my images (basically an x11 image) in just under 60
minutes 
 (once all the files have been fetched). I run with BB_NUMBER_THREADS
and 
 PARALLEL_MAKE both set to 16 to make sure the cores are fully loaded
as 
 much as possible (other says that should be 8 and 8 to reduce
scheduling 
 overhead). 
  
  During the build the system is CPU bound quite a bit of the time (so
more 
 cores should help), but there are significant periods where the build 
 dependency chain means this isn't the case and only two or three cores
are 
 active. Previously I recall comparing results with someone else and
finding 
 that having lots more cores (24, I think) didn't give a significant
improvement 
 in build time (certainly not for the 3x system build cost). 
  
  I've never seen peak memory usage go much above 9

[yocto] Recommended Hardware for building

[Oliver Novakovic]

Dear all,

 

since we are using Yocto in our projects, I'd like to set up a dedicated
Build PC or server for the Yocto build tasks (including Jenkins).

 

Can anyone recommend a reasonable performant hardware setup to use ?

What should be considered ? Are there any pitfalls ? What about
bottlenecks in the build system ?

 

Specifically:

How many cores are recommended ? And how much cache is necessary ?
How much of the main memory does Yocto really use ? Is 32 GB sufficient
or should I go for 64 ?

Does it make sense to use two SSDs as Raid0  to get builds faster ?

 

Any hints, recommendations or links to further reading will be highly
appreciated.

 

Thanks in advance,

Oliver


Alpine Electronics RD Europe GmbH, Vor dem Lauch 14, 70567 Stuttgart,
Registergericht Stuttgart, HRB 25265
Geschaeftsfuehrer: Toshinori Kobayashi, Shuji Taguchi
Working office: Vor dem Lauch 14, 70567 Stuttgart

ATTENTION: This e-mail and any files transmitted with it may be privileged
and/or confidential, and are intended solely for the use of the individual
or entity to whom this  e-mail is addressed. If you are not one of the
named recipients or otherwise  have reason to believe that you have
received this e-mail in error, please notify  the sender and delete this
message immediately from your computer. We thank you for your cooperation.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto