Re: [yocto] dnf error

2018-02-07 Thread Alexander Kanavin

On 02/08/2018 03:17 AM, Russell Peterson wrote:

core-image-initramfs-1.0-r0 do_rootfs: Could not invoke dnf
Last metadata expiration check: 0:00:00 ago on Thu 08 Feb 2018 12:07:06 
AM UTC.

Error:
  Problem: conflicting requests
   - nothing provides /hosttools/python needed by 
ofa-kernel-4.2-r0.mymachine

ERROR: core-image-initramfs-1.0-r0 do_rootfs: Function failed: do_rootfs




Something in ofa-kernel rpm package is erroneously referring to 
.../hosttools/python. Rpm takes that as a dependency that must be satisfied.


Find out what it is and how it happens.

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


Re: [yocto] Changing gcc version and arch for single yocto recipe

2018-02-07 Thread Alexander Kanavin

On 02/07/2018 08:48 PM, Janez Svetokravsky wrote:
I have just stumbled upon interesting problem, which i do not know how 
to solve. I am using yocto to build image for ARM cortex-A9 CPU. default 
gcc used is version 5.2


Beside ARM cortex-A9 there is cortex-m0plus chip, which is located on 
the same board. From now on i will use abbreviations A9 and M0. 
Occasionally A9 is used to upgrade software on M0, therefor upgrade 
image for M0 is located in rootfs which is accessed by A9. Until now, i 
used different compiler/environment to compile firmware for M0 and 
afterwards copied M0 image to A9 rootfs.


I would like to move compiling of M0 firmware into yocto. gcc version 
used for M0 firmware is different and must not be changed, same goes for 
A9. So my question is: Is it possible to specify different version of 
gcc and different architecture, for single yocto recipe?



You can build any recipe for a different machine in the same build 
directory:


MACHINE=someothermachine bitbake 

You will find the packages in deploy dir.

Or just set up a separate build directory, and build there. Then use any 
suitable way to copy the result over (such as a recipe that pulls the 
ready-built firmware in).


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


Re: [yocto] static libraries missing from sdk

2018-02-07 Thread Robert Berger

Hi,

I played around a bit with my autotooled lib, which produces only a 
static lib.


1) My preferred approach is this:

I add to local.conf:

TOOLCHAIN_TARGET_TASK_append = " libhw-a-staticdev libhw-a-dev"

The recipe looks like this:

https://pastebin.com/YLUvQSSx

2) But your approach works as well:

I add to local.conf:

# we need to add the empty package to the rootfs for
# IMAGE_FEATURES_append to work:
IMAGE_INSTALL_append = " libhw-a"
# add all -dev, -dbg, -staticdev pkgs to the SDK (only):
SDKIMAGE_FEATURES_append = " dev-pkgs dbg-pkgs staticdev-pkgs"

The recipe looks like this:
(needed to slightly modify my original recipe)

https://pastebin.com/VcsqNuMf

On the rootfs there is nothing with respect to this recipe.

In the SDK are:
./opt/poky/2.4/sysroots/armv7a-neon-poky-linux-gnueabi/usr/lib/libhw.a
./opt/poky/2.4/sysroots/armv7a-neon-poky-linux-gnueabi/usr/include/lib_hw.h

Regards,

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


[yocto] Changing gcc version and arch for single yocto recipe

2018-02-07 Thread Janez Svetokravsky
Hello,

I have just stumbled upon interesting problem, which i do not know how to
solve. I am using yocto to build image for ARM cortex-A9 CPU. default gcc
used is version 5.2

Beside ARM cortex-A9 there is cortex-m0plus chip, which is located on the
same board. From now on i will use abbreviations A9 and M0. Occasionally A9
is used to upgrade software on M0, therefor upgrade image for M0 is located
in rootfs which is accessed by A9. Until now, i used different
compiler/environment to compile firmware for M0 and afterwards copied M0
image to A9 rootfs.

I would like to move compiling of M0 firmware into yocto. gcc version used
for M0 firmware is different and must not be changed, same goes for A9. So
my question is: Is it possible to specify different version of gcc and
different architecture, for single yocto recipe?
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto


Re: [yocto] static libraries missing from sdk

2018-02-07 Thread Robert Berger

Hi,

On 2018-02-07 16:01, Mircea Gliga wrote:

With this line you try to add -dev (.so), -dbg and staticdev (.a) for 
**all** packages:



     SDKIMAGE_FEATURES += "dev-pkgs dbg-pkgs staticdev-pkgs"


I am not sure it makes sense to build and add both the static and 
dynamic libs to an SDK.


Do you really want this?

Regards,

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


Re: [yocto] static libraries missing from sdk

2018-02-07 Thread Robert Berger

Hi,

OK I think I understood.

You want a static library and apparently .h and friends as well as the 
.a file should end up in the SDK and nothing on the rootfs.


If you enable staticdev-pkgs in the SDKIMAGE_FEATURES *all* the 
staticdev pkgs should end up in the SDK (I assume), but you need to use 
TOOLCHAIN_TARGET_TASK_append = " fmt-staticdev" for the .a file to show 
up in the SDK.


You use a cmake project and try to build https://github.com/fmtlib/fmt.

Regards,

Robert



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


Re: [yocto] static libraries missing from sdk

2018-02-07 Thread Mircea Gliga

Hi

This is the directory tree from the recipes packages-split/ folder, 
notice the empty main pkg, empty dbg etc


$ /usr/bin/tree
.
├── fmt
├── fmt-dbg
├── fmt-dev
│   └── usr
│   ├── include
│   │   └── fmt
│   │   ├── format.cc
│   │   ├── format.h
│   │   ├── ostream.cc
│   │   ├── ostream.h
│   │   ├── posix.h
│   │   ├── printf.h
│   │   ├── string.h
│   │   └── time.h
│   └── lib
│   └── cmake
│   └── fmt
│   ├── fmt-config.cmake
│   ├── fmt-config-version.cmake
│   ├── fmt-targets.cmake
│   └── fmt-targets-release.cmake
├── fmt-doc
├── fmt-locale
└── fmt-staticdev
    └── usr
    └── lib
    └── libfmt.a

See my notes below:


On 07/02/18 14:12, Robert Berger wrote:

Hi,

On 2018-02-07 09:46, Mircea Gliga wrote:

Thanks for your answer.
I already have the ALLOW_EMPTY_${PN} = "1" in the recipe

What I still don't get is why the -dev gets installed but the 
-staticdev doesn't, even though the dependency is satisfied (the 
empty pkg exists).




Just to understand what you are trying to do:

Would like to have both .a and .so files for your library in your SDK?
I need the headers and the static library in the SDK, fmt-dev, 
fmt-staticdev


What should be on the rootfs? I guess the .so

Nothing regarding this package.


You can check the contents of your packages with:

oe-pkgdata-util list-pkg-files -p 

$ oe-pkgdata-util list-pkg-files -p fmt
fmt:
fmt-dbg:
fmt-dev:
    /usr/include/fmt/format.cc
    /usr/include/fmt/format.h
    /usr/include/fmt/ostream.cc
    /usr/include/fmt/ostream.h
    /usr/include/fmt/posix.h
    /usr/include/fmt/printf.h
    /usr/include/fmt/string.h
    /usr/include/fmt/time.h
    /usr/lib/cmake/fmt/fmt-config-version.cmake
    /usr/lib/cmake/fmt/fmt-config.cmake
    /usr/lib/cmake/fmt/fmt-targets-release.cmake
    /usr/lib/cmake/fmt/fmt-targets.cmake
fmt-staticdev:
    /usr/lib/libfmt.a


How do you build your stuff? autotools?

The pkg is compiled using cmake, hence the inherit cmake:
    FILES_${PN}-dev += "${libdir}/*"

    #we need the empty main pkg, as -dev and -staticdev depend on it = 
> they end up in the SDK

    ALLOW_EMPTY_${PN} = "1"

    inherit cmake

It's a simple recipe, other than that it has the license info, SRC_URI, 
S vars set.




I needed to do the following in my recipe with autotools:

# By default EXTRA_OECONF is set to --disable-static ...
# Let's get rid of this
DISABLE_STATIC = ""
EXTRA_OECONF := "${@oe_filter_out('--disable-static', 
'${EXTRA_OECONF}', d)}"

# enable static and disable shared (for fun)
EXTRA_OECONF += "--enable-static --enable-shared"



I added this to local.conf:

# -->
IMAGE_INSTALL_append = " libhw-so-a"
# add libhw-so-a-dev and libhw-so-a-staticdev to SDK:
TOOLCHAIN_TARGET_TASK_append = " libhw-so-a-staticdev libhw-so-a-dev"
# <--

In my local.conf I have:
    SDKIMAGE_FEATURES += "dev-pkgs dbg-pkgs staticdev-pkgs"
There is *no*  usr/lib/libfmt.a in the SDK (no 
[...]toolchain/sysroots/cortexa5hf-neon-poky-linux-gnueabi/usr/lib/libfmt.a)


If I then add in local.conf also the following line:
    TOOLCHAIN_TARGET_TASK_append = " fmt-staticdev"

then I get the .a file in the SDK:
[...]toolchain/sysroots/cortexa5hf-neon-poky-linux-gnueabi/usr/lib/libfmt.a

Doesn't the staticdev-pkgs in the SDKIMAGE_FEATURES specify to install 
*all* the staticdev pkgs in the SDK ?


That's the content of the packages produced:

libhw-so-a:
    /usr/lib/libhw.so.0
    /usr/lib/libhw.so.0.0.0
libhw-so-a-dbg:
    /usr/lib/debug/usr/lib/libhw.so.0.0.0.debug
/usr/src/debug/libhw-so-a/1.0-r0/libhw-so-a-1.0/lib/lib_hw1.c
/usr/src/debug/libhw-so-a/1.0-r0/libhw-so-a-1.0/lib/lib_hw2.c
libhw-so-a-dev:
    /usr/include/lib_hw.h
    /usr/lib/libhw.so
libhw-so-a-staticdev:
    /usr/lib/libhw.a

in the rootfs:

./usr/lib/libhw.so.0
./usr/lib/libhw.so.0.0.0

in the SDK:

./opt/poky/2.4/sysroots/armv7a-neon-poky-linux-gnueabi/usr/lib/libhw.so
./opt/poky/2.4/sysroots/armv7a-neon-poky-linux-gnueabi/usr/lib/libhw.a
./opt/poky/2.4/sysroots/armv7a-neon-poky-linux-gnueabi/usr/lib/libhw.so.0
./opt/poky/2.4/sysroots/armv7a-neon-poky-linux-gnueabi/usr/lib/libhw.so.0.0.0 

./opt/poky/2.4/sysroots/armv7a-neon-poky-linux-gnueabi/usr/include/lib_hw.h 



Can you cook up an example where we can see/reproduce your problem?

Is the above enough ?




Regards,

Robert




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


[yocto] install qcharts module to yocto sdk

2018-02-07 Thread Pehen Azam
Hi!
I try to cross-compile qt chart examples for a yocto platform. I do
following steps to compile my qt programs:

 - source /opt/myimage/2.1.2/environment-setup-cortexa9hf-
neon-poky-linux-gnueabi
 - qmake -o Makefile areachart.pro
 - make

But When I add `QT += charts` to any project run qmake like `qmake -o
Makefile areachart.pro` I hit this error:
Project ERROR: Unknown module(s) in QT: charts

Here is the output of `qmake -v`:
QMake version 3.0
Using Qt version 5.7.0 in /opt/myimage/2.1.2/sysroots/
cortexa9hf-neon-poky-linux-gnueabi/usr/lib

Should I should add `qtcharts` module my yocto SDK to be able to compile
the example? if yes how?

For some reasons I was able to cross-compiled Qt from source on github
using `qtcreator` and get the binary files for qt examples and qtchart
library itself. I also run the qt examples on my target platform by putting
resulting `libQtCharts.so` and other files manually in `/usr/lib/` and
`/usr/include/` on the target and I was able to draw the charts on target.

However, what I need is to include the charts in my project and run `qmake`
steps as mentioned above. But what I get is the `Project ERROR:  Unknown
module(s) in QT: charts`
I have tried to put `libQtCharts.so` which I got from compiling qt source
manually in 
`/opt/myimage/2.1.2/sysroots/cortexa9hf-neon-poky-linux-gnueabi/usr/lib`
but still not able to get the make file with `qmake -o Makefile
areachart.pro`

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


Re: [yocto] Creating a python recipe with devtool

2018-02-07 Thread Alan Martinovic
Thanks, that worked!

Steps:

# On the build server
devtool create-workspace
devtool add  https://github.com/jruere/multiprocessing-logging
devtool
devtool edit-recipe multiprocessing-logging
# Change for building for python3
   inherit setuptools -> inherit setuptools3
# delete the RDEPENDS that were wrongly detected
devtool build multiprocessing-logging
#Prerequisit: ssh root@10.10.10.100
devtool deploy-target multiprocessing-logging root@10.10.10.100

#On the 10.10.10.100 device
python3
import python3-multiprocessing_logging

#On the build server. Finishing
devtool finish multiprocessing-logging
/home/alan/meta-myproject/recipes-devtools/python

On Wed, Feb 7, 2018 at 1:25 PM, Alexander Kanavin
 wrote:
> On 02/07/2018 02:17 PM, Alan Martinovic wrote:
>>
>>  devtool add
>>
>> https://pypi.python.org/packages/65/eb/1c3db9596eddb2bd1d1f8153dcaf2d9f2c7e144f4832d1b1449f681a0a7a/multiprocessing_logging-0.2.6-py2.py3-none-any.whl#md5=b7783a8c449135e5bb344b3f0caa3522
>
>
> I don't think we support .whl format at the moment. You need to fetch
> sources directly from github.
>
>
> Alex
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto


Re: [yocto] Creating a python recipe with devtool

2018-02-07 Thread Alexander Kanavin

On 02/07/2018 02:17 PM, Alan Martinovic wrote:

 devtool add
https://pypi.python.org/packages/65/eb/1c3db9596eddb2bd1d1f8153dcaf2d9f2c7e144f4832d1b1449f681a0a7a/multiprocessing_logging-0.2.6-py2.py3-none-any.whl#md5=b7783a8c449135e5bb344b3f0caa3522


I don't think we support .whl format at the moment. You need to fetch 
sources directly from github.



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


[yocto] Creating a python recipe with devtool

2018-02-07 Thread Alan Martinovic
Hi,
I need to add a python package available on pypi:
https://pypi.python.org/pypi/multiprocessing-logging/

Instead of manually creating the bb file, I'd like to add
it using the devtool flow.

In my build directory I execute:

devtool create-workspace
devtool build-image my-image
devtool add
https://pypi.python.org/packages/65/eb/1c3db9596eddb2bd1d1f8153dcaf2d9f2c7e144f4832d1b1449f681a0a7a/multiprocessing_logging-0.2.6-py2.py3-none-any.whl#md5=b7783a8c449135e5bb344b3f0caa3522

That is the URL for the sources listed here:
 https://pypi.python.org/pypi/multiprocessing-logging/

That ends up with an error:

NOTE: Tasks Summary: Attempted 2 tasks of which 0 didn't need to
be rerun and all succeeded.
Traceback (most recent call last):
  File "/home/alan/senic-os/oe/scripts/recipetool", line 121, in 
ret = main()
  File "/home/alan/senic-os/oe/scripts/recipetool", line 110, in main
ret = args.func(args)
  File "/home/alan/senic-os/oe/scripts/lib/recipetool/create.py",
line 512, in create_recipe
check_single_file(dirlist[0], fetchuri)
  File "/home/alan/senic-os/oe/scripts/lib/recipetool/create.py",
line 917, in check_single_file
with open(fn, 'r', errors='surrogateescape') as f:
FileNotFoundError: [Errno 2] No such file or directory:
'multiprocessing_logging-0.2.6-py2.py3-none-any.whl'

What am I missing?
Is the correct URL used?
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto


Re: [yocto] static libraries missing from sdk

2018-02-07 Thread Robert Berger

Hi,

On 2018-02-07 09:46, Mircea Gliga wrote:

Thanks for your answer.
I already have the ALLOW_EMPTY_${PN} = "1" in the recipe

What I still don't get is why the -dev gets installed but the -staticdev 
doesn't, even though the dependency is satisfied (the empty pkg exists).




Just to understand what you are trying to do:

Would like to have both .a and .so files for your library in your SDK?

What should be on the rootfs? I guess the .so

You can check the contents of your packages with:

oe-pkgdata-util list-pkg-files -p 

How do you build your stuff? autotools?

I needed to do the following in my recipe with autotools:

# By default EXTRA_OECONF is set to --disable-static ...
# Let's get rid of this
DISABLE_STATIC = ""
EXTRA_OECONF := "${@oe_filter_out('--disable-static', '${EXTRA_OECONF}', 
d)}"

# enable static and disable shared (for fun)
EXTRA_OECONF += "--enable-static --enable-shared"



I added this to local.conf:

# -->
IMAGE_INSTALL_append = " libhw-so-a"
# add libhw-so-a-dev and libhw-so-a-staticdev to SDK:
TOOLCHAIN_TARGET_TASK_append = " libhw-so-a-staticdev libhw-so-a-dev"
# <--

That's the content of the packages produced:

libhw-so-a:
/usr/lib/libhw.so.0
/usr/lib/libhw.so.0.0.0
libhw-so-a-dbg:
/usr/lib/debug/usr/lib/libhw.so.0.0.0.debug
/usr/src/debug/libhw-so-a/1.0-r0/libhw-so-a-1.0/lib/lib_hw1.c
/usr/src/debug/libhw-so-a/1.0-r0/libhw-so-a-1.0/lib/lib_hw2.c
libhw-so-a-dev:
/usr/include/lib_hw.h
/usr/lib/libhw.so
libhw-so-a-staticdev:
/usr/lib/libhw.a

in the rootfs:

./usr/lib/libhw.so.0
./usr/lib/libhw.so.0.0.0

in the SDK:

./opt/poky/2.4/sysroots/armv7a-neon-poky-linux-gnueabi/usr/lib/libhw.so
./opt/poky/2.4/sysroots/armv7a-neon-poky-linux-gnueabi/usr/lib/libhw.a
./opt/poky/2.4/sysroots/armv7a-neon-poky-linux-gnueabi/usr/lib/libhw.so.0
./opt/poky/2.4/sysroots/armv7a-neon-poky-linux-gnueabi/usr/lib/libhw.so.0.0.0
./opt/poky/2.4/sysroots/armv7a-neon-poky-linux-gnueabi/usr/include/lib_hw.h

Can you cook up an example where we can see/reproduce your problem?



Regards,

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