[yocto] Using dpkg-buildpackage within Yocto image

2018-10-25 Thread Fabian Sturm
Hello,


I would like to be able to build debian packages on yocto itself. This means I 
would call something like this: 


    dpkg-buildpackage -us -uc -rfakeroot


This already does not work, since fakeroot does not exist in the image. It 
seems there was an older recipe for this but I can't find it in newer releases 
(sumo).

If I build without -rfakeroot as root user I get a step further but then I get:


    dpkg-checkbuilddeps: error: Unmet build dependencies: debhelper (>= 9) 
dh-systemd


I unfortunately could not find the right recipes which would provide those 
files. Am I missing something?


Thanks in advance,

Fabian


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


[yocto] Python3 sqlite does not work

2018-09-24 Thread Fabian Sturm
Hi, 

I added python3 to my yocto build and it seems python-sqlite3 is not
working due to a missing file. If I change python3-manifest.json from
here:

  http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/recipes-devt
ools/python/python3/python3-manifest.json?h=sumo

to also include the __init__.py file. Them it seems to be woking fine.


diff --git a/meta/recipes-devtools/python/python3/python3-manifest.json 
b/meta/recipes-devtools/python/python3/python3-manifest.json
index 2491f36..607eb2b 100644
--- a/meta/recipes-devtools/python/python3/python3-manifest.json
+++ b/meta/recipes-devtools/python/python3/python3-manifest.json
@@ -979,12 +979,14 @@
 "cached": [
 "${libdir}/python3.5/sqlite3/__pycache__",
 "${libdir}/python3.5/sqlite3/__pycache__/dbapi2.*.pyc",
-"${libdir}/python3.5/sqlite3/__pycache__/dump.*.pyc"
+"${libdir}/python3.5/sqlite3/__pycache__/dump.*.pyc",
+"${libdir}/python3.5/sqlite3/__pycache__/__init__.pyc"
 ],
 "files": [
 "${libdir}/python3.5/lib-dynload/_sqlite3.*.so",
 "${libdir}/python3.5/sqlite3/dbapi2.py",
-"${libdir}/python3.5/sqlite3/dump.py"
+"${libdir}/python3.5/sqlite3/dump.py",
+"${libdir}/python3.5/sqlite3/__init__.py"
 ],

To test it it is enough to run python3 and do:

  import sqlite3
  help(sqlite3)

You should see many functions like e.g. connect instead of only two.

Is this a bug, or am I doing something wrong?

Kind regards,
Fabian

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


Re: [yocto] Native yocto compile in docker container without cross compile

2018-09-19 Thread Fabian Sturm
Hmm I guess I was way overthinking this. The idea seems to just create
a secong image definition like this it seems:


core-image-minimal-dev.bb:

require core-image-minimal.bb

DESCRIPTION = "A small image just capable of allowing a device to
boot and \
is suitable for development work."

IMAGE_FEATURES += "dev-pkgs tools-sdk"
IMAGE_INSTALL += "cmake"

dev-pkg: selects e.g. all header files for the image packages
tools-sdk: install the toolchain packages into the image
IMAGE_INSTALL += "cmake": here I define any other development tool that
I need in my image

I this correct? At least it seems the created image contains everything
I need!

Kind regards,
Fabian


Am Mittwoch, den 19.09.2018, 18:21 +0100 schrieb Burton, Ross:
> If you're targeting just x86 then you can build an image with the
> tools-sdk IMAGE_FEATURE defined, and use something like systemd-
> nspawn
> (insert your preferred container system) to get a shell in it.
> 
> Ross

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


Re: [yocto] Native yocto compile in docker container without cross compile

2018-09-19 Thread Fabian Sturm
Hi,

no this is not what I am searching for. What I want is gcc cmake and
other tools to be installed inside of the Yocto image, so that I can
compile natively in Yocto without having to hack build scripts to work
with a cross compiler. 
But of course I don'T want to deliver gcc and others with the image on
a device. One solution would be to build a separate image that contains
the tools. But my hope is to use the original image and just add those
tools later on.

Any ideas how to set something like this up best?

Kind regrads,
Fabian

Am Mittwoch, den 19.09.2018, 10:07 +0200 schrieb Alexander Kanavin:
> I think what you are looking for is a Yocto generated SDK for your
> image?
> 
> bitbake -c populate_sdk 
> 
> Alex

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


[yocto] Native yocto compile in docker container without cross compile

2018-09-18 Thread Fabian Sturm
Hi, 

I am wondering, there does not seem to be any information about native
compile of projects in a Yocto docker container. It seems that most of
the people use cross compile even though that imho is not necessary if
your target is x86 too. So here is what I want to do:

- Create a docker container with Yocto Linux, possibly same as the
target image
- Install gcc, cmake, autotools etc. in the docker container
- Run the docker container on a vanilla Ubuntu Linux
- Run build jobs in this docker container directly

Rational. I have several projects with fully functioning build systems,
e.g. make, cmake or autotools which I need to compile for different
platforms, e.g. Windows, Ubuntu Linux and Yocto Linux. I now don't want
to write recipes just for the Yocto cross compile which I need to
additionally maintain and I also don't want to make the original build
systems cross compile aware. This can soon get really hard if the build
system generates intermediate binaries that are called in the build
itself and if it is not prepared for this.
Since my target and host platform are both x86 I do not see the need
for a cross compile anyways. Usually it is necessary since the target
platform might be a very slow ARM system that can't handle all the
builds itself. But I do not have this limitation.

With such a solution my original build systems should still be able to
run unmodified. Within the docker container the environment would be
almost the same as in an Ubuntu Linux. The compiler can be accessed
without any cross compile settings and any intermediate binaries can
also be directly executed etc.

If there are some fundamental reasons why this is a bad idea, I would
like to know. I also would appreciate any tips on how to create such a
docker image. Usually my Yocto image for the target would not contain a
compiler or make tool. So I need a way to add those after the fact.


Thanks a lot!
Fabian

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