[yocto] How to generate SPDX Information

[Christian Ege]

Hello,

due to the fact there is a license troll who actively sue German
companies. I did some research to comply ith the need to provide the
copyright information within my YOCTO builds. My research ended up
with the spdx.class which includes support for the fossology tool. But
the current version of fossology does not support the spdx plugin used
in the spdx.class anymore [1] This plugin is not updated since 4
years. As an alternative there is the DoSOCSv2 tool [2] for which a
Patch by Lei Maohui exists which was not accepted and Lei ended up in
a separate layer called meta-spdxscanner [3].

So my specific question is, what are the recommended actions to comply
to provide copyright information with the sourcecode/binary? What is
the state of the art at the moment and how do the users of oe/yocto
solve this requirement.

Thanks in advance,
Christian

-- 
[1] https://github.com/FOSSology-SPDX/fossology-spdx
[2] https://github.com/DoSOCSv2/DoSOCSv2
[3] 
https://layers.openembedded.org/layerindex/branch/master/layer/meta-spdxscanner/
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] any pointers to a yocto-based image to use as a live install utility?

[Christian Ege]

Hi Robert

2016-05-25 12:18 GMT+02:00 Robert P. J. Day :
>
>   specifically in the context of powerpc systems, are there any
> suggestions for an image that could be used to boot an older powerpc
> system, running completely out of ram, and using that as an install
> utility which would then be responsible for detecting/formatting a
> hard drive, creating/formatting filesystems, downloading/installing
> the OS, post-install configuration and so on?
>
>   i realize that's a spectacularly imprecise request -- in a general
> sense, it involves just starting with a regular image, then adding
> utilities that run around doing all of the above, but if there's
> anything that already takes one most of the way there, that'd be
> great.
>
>   thoughts?
Maybe https://github.com/sbabic/swupdate is what you are looking for.
It has full OE support and is not tied to any architecture. You can extend
swupdate by scripting which will provide you with a lot of flexibility.

Regards,
Christian


>
> rday
>
> --
>
> 
> Robert P. J. Day Ottawa, Ontario, CANADA
> http://crashcourse.ca
>
> Twitter:   http://twitter.com/rpjday
> LinkedIn:   http://ca.linkedin.com/in/rpjday
> 
>
>
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto



-- 
http://ch.ege.io/
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] calibrator fails to run

[Christian Ege]

Hello Frederick,

> Goal: Run a cross compiled executable called calibrator from 
> git://git.ti.com/wilink8-wlan/18xx-ti-utils.git
>
> Here's my build script:
>
> export NFSROOT=/srv/imx/CS65X-dev
> export 
> CROSS_COMPILE=/opt/prickle/1.7.2/sysroots/x86_64-pricklesdk-linux/usr/bin/arm-prickle-linux-gnueabi/arm-prickle-lin
> ux-gnueabi-
> export NLVER=3
> export CFLAGS="-mfloat-abi=hard 
> -I/opt/prickle/1.7.2/sysroots/cortexa9hf-vfp-neon-prickle-linux-gnueabi/usr/include/libnl3
> "
>
> make
Maybe better use
source /opt/prickle/1.7.2/environment-setup-armv7ahf-vfp-neon-poky-linux-gnueabi

and after this you can use
export CROSS_COMPILE=arm-prickle-linux-gnueabi-

BTW I am using this recipe to compile the TI tools for my UDOO meta layer
https://github.com/graugans/meta-udoo/blob/krogoth/recipes-bsp/wl18xx-conf/wl18xx-conf.bb

Maybe this is an option for you too


>From the output it looks like hardfp/softfp missmatch..

Regards,
Christian
> sudo make install NFSROOT=/srv/imx/CS65X-dev
>
> 
>
> This will build the library and install it onto my system.
>
> However, when I run it, I get:
>
> root@yocto:~# /usr/bin/calibrator
> -sh: /usr/bin/calibrator: No such file or directory
>
> But the file does exist, and it even looks like the proper type of executable:
>
> root@yocto:~# file /usr/bin/calibrator
>
> /usr/bin/calibrator: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), 
> dynamically linked (uses shared libs), for GNU/Li
> nux 2.6.32, BuildID[sha1]=96e4d113a9e1a0e90fd60d8d0a59e19323457b5d, stripped
>
> Here's my hardware info:
>
> root@yocto:~# cat /proc/cpuinfo
> processor   : 0
> model name  : ARMv7 Processor rev 10 (v7l)
> BogoMIPS: 1988.29
> Features: swp half thumb fastmult vfp edsp neon vfpv3 tls
> CPU implementer : 0x41
> CPU architecture: 7
> CPU variant : 0x2
> CPU part: 0xc09
> CPU revision: 10
>
> Hardware: Freescale i.MX6 Quad/DualLite (Device Tree)
> Revision: 
> Serial  : 
>
> Any ideas on where to start?
>
> Thanks.
>
> Frederick
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto



-- 
http://ch.ege.io/
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] how to install a kernel module

[Christian Ege]

Hi,


Hej

I created a recipe for a own modul. It's similar to the example given at:

http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta-skeleton/recipes-kernel/hello-mod

I checked the bitbake process. A "kernel-module-" package is
created and filled with the ko-file.


Not sure what you already tried. You can check this as a example:

https://github.com/graugans/meta-udoo/blob/master/conf/machine/udooneo.conf

I do use autoload  and recommends to add modules to the image.

Regards,
Christian
>

Actually I am failing to bring the module into my image and run it. Are
there a special command for the "local.conf" or so?

How and where to include the module?

Regards!

Stefan Jaritz


ESA Elektroschaltanlagen Grimma GmbH
Broner Ring 30
04668 Grimma
Telefon: +49 3437 9211 176
Telefax: +49 3437 9211 26
E-Mail: s.jar...@esa-grimma.de
Internet: www.esa-grimma.de


Geschäftsführer:
Dipl.-Ing. Jörg Gaitzsch
Jörg Reinker

Sitz der Gesellschaft: Grimma
Ust.-ID: DE 141784437
Amtsgericht: Leipzig, HRB 5159
Steuernummer: 238/108/00755


Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte
Informationen.
Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich
erhalten
haben, informieren Sie bitte sofort den Absender und löschen Sie diese
Nachricht. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser
Mail
ist nicht gestattet.

This e-mail may contain confidential and/or privileged information. If you
are
not the intended recipient (or have received this e-mail in error) please
notify the sender immediately and destroy this e-mail. Any unauthorized
copying, disclosure or distribution of the material in this e-mail is
strictly
forbidden.


--
--
___
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] Kernel 3.14.28 (imx duallite) will compile under 1.7, but not under 2.0-2.1

[Christian Ege]

Hi,

> Maybe it has something to do with a different make version in the newer
> versions of Yocto? Maybe this link is relevant?
> https://github.com/zanezam/boeffla-kernel-cm-bacon/commit/ef4fea130eeb70eff4f3a549fd3f6e9b11437550
>
This is most probably because of the newer GCC version used in the
different versions of yocto.
I guess the kernel you are using does not contain those patches:
https://github.com/graugans/meta-udoo/blob/jethro/recipes-kernel/linux/linux-seco-3.14.28/0001-ARM-8158-1-LLVMLinux-use-static-inline-in-ARM-ftrace.patch
https://github.com/graugans/meta-udoo/blob/jethro/recipes-kernel/linux/linux-seco-3.14.28/0002-ARM-LLVMLinux-Change-extern-inline-to-static-inline-.patch

Regrads,
Christian

> On Tue, May 10, 2016 at 10:22 PM Paul Knopf  wrote:
>>
>> I am trying to update my BSP to work with the latest releases of Yocto,
>> however, I can't even compile the kernel with the same
>> defconfig/commit/repo.
>>
>> It works on 1.7, but not under 2.0. Here are the do_compile run and log
>> for each version of yocto.
>> https://gist.github.com/anonymous/3222e0a10ba1bca1f7a7316879d1704d
>>
>> ---
>> make[3]: *** [arch/arm/mm/built-in.o] Error 1
>> make[2]: *** [arch/arm/mm] Error 2
>>   AS  arch/arm/kernel/sigreturn_codes.o
>>   CC  arch/arm/kernel/stacktrace.o
>>
>> /home/pknopf/Git/recipes/build/tmp/work-shared/seco-uq7-dl-256mbx4/kernel-source/arch/arm/kernel/return_address.c:63:2:
>> warning: #warning "TODO: return_address should use unwind tables" [-Wcpp]
>>  #warning "TODO: return_address should use unwind tables"
>>   ^
>>
>> /home/pknopf/Git/recipes/build/tmp/work-shared/seco-uq7-dl-256mbx4/kernel-source/arch/arm/kernel/return_address.c:66:7:
>> error: redefinition of 'return_address'
>>  void *return_address(unsigned int level)
>>^
>> In file included from
>> /home/pknopf/Git/recipes/build/tmp/work-shared/seco-uq7-dl-256mbx4/kernel-source/include/linux/ftrace.h:20:0,
>>  from
>> /home/pknopf/Git/recipes/build/tmp/work-shared/seco-uq7-dl-256mbx4/kernel-source/arch/arm/kernel/return_address.c:12:
>>
>> /home/pknopf/Git/recipes/build/tmp/work-shared/seco-uq7-dl-256mbx4/kernel-source/arch/arm/include/asm/ftrace.h:48:21:
>> note: previous definition of 'return_address' was here
>>  extern inline void *return_address(unsigned int level)
>>  ^
>> make[3]: *** [arch/arm/kernel/return_address.o] Error 1
>> make[3]: *** Waiting for unfinished jobs
>> make[2]: *** [arch/arm/kernel] Error 2
>> make[1]: *** [sub-make] Error 2
>> ---
>>
>> Any idea why update Yocto would cause this build error?
>> --
>>
>> Thanks,
>> Paul Knopf
>> Software Engineer
>> Med X Change, Inc
>> pkn...@medxchange.com
>
> --
>
> Thanks,
> Paul Knopf
> Software Engineer
> Med X Change, Inc
> pkn...@medxchange.com
>
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>



-- 
http://ch.ege.io/
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [PATCH] bluez5: fixed path to bluetoothd in sysvinit script

[Christian Ege]

Within the sysvinit script the path to bluetoothd is wrong. Because of this
the init scripts silently terminates without any message

Signed-off-by: Christian Ege 
---
 meta/recipes-connectivity/bluez5/bluez5/init | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-connectivity/bluez5/bluez5/init 
b/meta/recipes-connectivity/bluez5/bluez5/init
index 1606a5c..9777614 100644
--- a/meta/recipes-connectivity/bluez5/bluez5/init
+++ b/meta/recipes-connectivity/bluez5/bluez5/init
@@ -3,7 +3,7 @@
 PATH=/sbin:/bin:/usr/sbin:/usr/bin
 DESC=bluetooth
 
-DAEMON=/usr/lib/bluez5/bluetooth/bluetoothd
+DAEMON=/usr/libexec/bluetooth/bluetoothd
 
 # If you want to be ignore error of "org.freedesktop.hostname1",
 # please enable NOPLUGIN_OPTION.
-- 
2.1.4

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

[yocto] Hi, Re: Serial Timeout

[Christian Ege]

Am 18. April 2016 5:14:34 nachm. schrieb Markus Haege :


Hello there,

We use a Freescale imx6 with u-boot. Everything works fine, via serial
loader we copy
devictree, u-boot and kernel+initramfs to the board an it all starts. We
can login but after
5 sec the connection breaks and no further input is possible via serial
console.


Could be watchdog related. You habe an external watchdog or  power monitor 
in your system?


When you run from USB you should see a hid device after a reset.


For the rootfs we use core-image-minimal and bundle it with little code via
a configfile which
I add to bitbake with -R. I found these instructions in the web. Don't find
it now.
But why everything stops after 5 sec? I searched the web for hours but
don't find anything.


Those fixed timing smells like timer/watchdog ...


Help is appreciated, thanks

Markus





Best,
Christian



--
--
___
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] Yocto touch

[Christian Ege]

Hi,
Am 10. April 2016 5:31:52 nachm. schrieb Berlin Vince Joe V S 
:


hi ,,I already posted my query on yocto mail but it won't get moderator 
approval I don't know why ?
I am working on KONTRON SMARC(IMX6"Freescale"). I need to build the yocoto 
that can control all the devices that are connected to KONTRON but it 
won't. Now the problem is i am trying to interface with a capacitive touch 
screen (FT5x06 family) the Driver is already available but it is not working.


Are you planning ti use Qt5 with eglfs on framebuffer or are you planning 
to use X11 or Wayland?


Any way I am really need help could you please tell me if i need to add a 
hardware driver individually what are the files I need to take care of  
but OS Run Good but touch is not responding!!!



Have you checked lsmod if the driver is loaded (when compiled as module )

Have you checked dmesg if the touch screen is successful detected?

Is there any new input device?

How is the touchscreen connected by USB or i2c? If by i2c it may worth to 
check with i2c tools.


Please help me guys


Regards,
Christian







--
--
___
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] Re: Qt5.6 new modules

[Christian Ege]

Hi,

2016-03-17 17:16 GMT+01:00 idealsim :
> Hi, i have started a build of the image this master Branch, like you said i
> have an error on qtserialbus :
>
> WARNING: Failed to fetch URL
> git://github.com/qtproject/qtserialbus.git;name=qtserialbus;branch=5.6;protocol=git,
> attempting MIRRORS if available
> ERROR: Fetcher failure: Unable to find revision
> 6a16281aceedb713676e16c3074e6f7ea1e70b79 in branch 5.6 even from upstream
> ERROR: Function failed: Fetcher failure for URL:
> 'git://github.com/qtproject/qtserialbus.git;name=qtserialbus;branch=5.6;protocol=git'.
> Unable to fetch URL from any source.
> ERROR: Logfile of failure stored in:
> /media/modjo/data1TO/yocto/seco/udoo-community-bsp/neoBuild/tmp/work/cortexa9hf-vfp-neon-poky-linux-gnueabi/qtserialbus/5.5.99+5.6.0-rc+gitAUTOINC+6a16281ace-r0/temp/log.do_fetch.5862
> ERROR: Task 894
> (/media/modjo/data1TO/yocto/seco/udoo-community-bsp/sources/meta-qt5/recipes-qt/qt5/qtserialbus_git.bb,
> do_fetch) failed with exit code '1'
>
> This is my qtserialbus_git.bb :
>
> require qt5.inc
> require qt5-git.inc
>
> # There are no LGPLv3-only licensed files in this component.
> # There are no GPLv2 licensed files in this component.
> LICENSE = "GFDL-1.3 & BSD & (LGPL-2.1 & The-Qt-Company-Qt-LGPL-Exception-1.1
> | LGPL-3.0)"
> LIC_FILES_CHKSUM = " \
> file://LICENSE.LGPLv3;md5=b8c75190712063cde04e1f41b6fdad98 \
> file://LICENSE.GPLv3;md5=40f9bf30e783ddc201497165dfb32afb \
> file://LICENSE.FDL;md5=6d9f2a9af4c8b8c3c769f6cc1b6aaf7e \
> file://LICENSE.GPLv2;md5=05832301944453ec79e40ba3c3cfceec \
> "
>
> DEPENDS += "qtbase qtserialport"
>
> SRCREV = "6a16281aceedb713676e16c3074e6f7ea1e70b79"
The SRCREV is the git SHA1 of the repository qtserialbus. For the 5.6
Branch the latest one is:

SRCREV = "92c979c6652d55c30ab9118d45db74d8da96fc3b"


You can check the SHA1s here:
https://github.com/qtproject/qtserialbus/commits/5.6

The MD5 Sums will be complained during configure step and bitbake wil
tell you the right ones.
Please check if the Licences do match

Regards,
Christian

>
> An idea is welcome !
>
> Regards,
>
> Mickaël
>
>
>
> Le 16/03/2016 14:57, idealsim a écrit :
>
> Thanks for the tip. I will try it out and let you know ...
>
> Regards,
>
> Mickaël
>
> Le 16/03/2016 10:17, Christian Ege a écrit :
>
> Hi,,
>
> 2016-03-16 9:04 GMT+01:00 idealsim :
>
> Hi, we have build an image for udoo neo from meta-qt5 jansa/master-5.6 and
> works fine (thanks to Christian Ege ). The problem is that I'm looking for
> https://github.com/qtproject/qtquickcontrols2 and
> https://github.com/qtproject/qtserialbus. My question is how we can add this
> modules to our build ?  I add this to our local.conf :
>
>  "qtquickcontrols2 \
>   qtserialbus \
>  "
> But this modules don't have buildable providers ! If someone can help to
> said me how to proceed ...
>
> You can try to add a meta-qt5/recipes-qt/qt5/qtserialbus_git.bb and
> take for example meta-qt5/recipes-qt/qt5/qtsensors_git.bb as reference
>
> require qt5.inc
> require qt5-git.inc
> # There are no LGPLv3-only licensed files in this component.
> # There are no GPLv2 licensed files in this component.
> LICENSE = "GFDL-1.3 & BSD & (LGPL-2.1 &
> The-Qt-Company-Qt-LGPL-Exception-1.1 | LGPL-3.0)"
> LIC_FILES_CHKSUM = " \
> file://LICENSE.LGPLv21;md5=58a180e1cf84c756c29f782b3a485c29 \
> file://LICENSE.LGPLv3;md5=b8c75190712063cde04e1f41b6fdad98 \
> file://LICENSE.GPLv3;md5=40f9bf30e783ddc201497165dfb32afb \
> file://LGPL_EXCEPTION.txt;md5=9625233da42f9e0ce9d63651a9d97654 \
> file://LICENSE.FDL;md5=6d9f2a9af4c8b8c3c769f6cc1b6aaf7e \
> file://LICENSE.GPLv2;md5=05832301944453ec79e40ba3c3cfceec \
> "
> DEPENDS += "qtbase"
>
> SRCREV = "71a323e1f12df8d213a4052621027e223eb5a343"
>
> The configure step will bail out due to the fact that you have wrong
> checksums but it will show you the right ones
>
> Best,
> Christian
>
>
> regards,
>
> Mickael
>
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
>
>
>
>



-- 
http://ch.ege.io/
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [master] ERROR: gobject-introspection-1.46.0-r0 do_populate_sysroot:

[Christian Ege]

Hi,

with the latest master from today I ran in some trouble:

Build Configuration:
BB_VERSION= "1.29.0"
BUILD_SYS = "x86_64-linux"
NATIVELSBSTRING   = "universal"
TARGET_SYS= "arm-poky-linux-gnueabi"
MACHINE   = "udooneo"
DISTRO= "poky"
DISTRO_VERSION= "2.0+snapshot-20160316"
TUNE_FEATURES = "arm armv7a vfp thumb neon
callconvention-hard   cortexa9"
TARGET_FPU= "hard"
meta
meta-poky = "HEAD:8debfea81e69d038bd2d56314b272cb74f5582ed"
meta-oe
meta-multimedia
meta-python
meta-networking   = "HEAD:35d91f32c462ad5889cb3229766d6d4ed2c80a4c"
meta-qt5  = "master-5.6:b2d5376b41625521b9a081fe800345fff33d8dd6"
meta-ruby = "HEAD:35d91f32c462ad5889cb3229766d6d4ed2c80a4c"
meta-fsl-arm  = "HEAD:37564e6801ce82fad979b4f57151c676d80e8a6c"
meta-fsl-arm-extra = "HEAD:36a638abe1238bdc8e0ef1242dd7bfab59cc48d7"
meta-fsl-demos= "HEAD:6b779b2cb0d231063fc035a9a0871d722366c329"
meta-udoo = "master:1b38bcec5057b93017a00f107e0738ce64ade66f"
meta-swupdate = "master:44516e81a494afef3be7e3f249713fdec6e6e32a"

NOTE: Preparing RunQueue
NOTE: Executing SetScene Tasks
NOTE: Executing RunQueue Tasks
ERROR: gobject-introspection-1.46.0-r0 do_populate_sysroot: The recipe
gobject-introspection is trying to install files into a shared area
when those files already exist. Those files and their manifest
location are:
   
/data/FSL/fsl-community-bsp-master/build/tmp/sysroots/udooneo/usr/share/gobject-introspection-1.0/Makefile.introspection
 Matched in manifest-udooneo-gtk-doc-stub.populate_sysroot
 
/data/FSL/fsl-community-bsp-master/build/tmp/sysroots/udooneo/usr/share/aclocal/introspection.m4
 Matched in manifest-udooneo-gtk-doc-stub.populate_sysroot
Please verify which recipe should provide the above files.
The build has stopped as continuing in this scenario WILL break
things, if not now, possibly in the future (we've seen builds fail
several months later). If the system knew how to recover from this
automatically it would however there are several different scenarios
which can result in this and we don't know which one this is. It may
be you have switched providers of something like virtual/kernel (e.g.
from linux-yocto to linux-yocto-dev), in that case you need to execute
the clean task for both recipes and it will resolve this error. It may
be you changed DISTRO_FEATURES from systemd to udev or vice versa.
Cleaning those recipes should again resolve this error however
switching DISTRO_FEATURES on an existing build directory is not
supported, you should really clean out tmp and rebuild (reusing sstate
should be safe). It could be the overlapping files detected are
harmless in which case adding them to SSTATE_DUPWHITELIST may be the
correct solution. It could also be your build is including two
different conflicting versions of things (e.g. bluez 4 and bluez 5 and
the correct solution for that would be to resolve the conflict. If in
doubt, please ask on the mailing list, sharing the error and filelist
above.
ERROR: gobject-introspection-1.46.0-r0 do_populate_sysroot: If the
above message is too much, the simpler version is you're advised to
wipe out tmp and rebuild (reusing sstate is fine). That will likely
fix things in most (but not all) cases.
ERROR: gobject-introspection-1.46.0-r0 do_populate_sysroot: Function
failed: sstate_task_postfunc
ERROR: Logfile of failure stored in:
/data/FSL/fsl-community-bsp-master/build/tmp/work/cortexa9hf-neon-poky-linux-gnueabi/gobject-introspection/1.46.0-r0/temp/log.do_populate_sysroot.16494
ERROR: Task 1802
(/data/FSL/fsl-community-bsp-master/sources/poky/meta/recipes-gnome/gobject-introspection/gobject-introspection_1.46.0.bb,
do_populate_sysroot) failed with exit code '1'
NOTE: Tasks Summary: Attempted 4772 tasks of which 4742 didn't need to
be rerun and 1 failed.
No currently running tasks (4772 of 5254)


Any help is appreciated.

Best,
Christian

-- 
http://ch.ege.io/


log.do_populate_sysroot.16494
Description: Binary data
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [master] ERROR: gobject-introspection-1.46.0-r0 do_populate_sysroot:

[Christian Ege]

Hi,
On 16.03.2016 20:44, Martin Jansa wrote:
> Delete your TMPDIR and start again.
thx, this did the trick

Best,
Christian
> 
> On Wed, Mar 16, 2016 at 8:29 PM, Christian Ege  <mailto:k423...@gmail.com>> wrote:
> 
> Hi,
> 
> with the latest master from today I ran in some trouble:
> 
> Build Configuration:
> BB_VERSION= "1.29.0"
> BUILD_SYS = "x86_64-linux"
> NATIVELSBSTRING   = "universal"
> TARGET_SYS= "arm-poky-linux-gnueabi"
> MACHINE   = "udooneo"
> DISTRO= "poky"
> DISTRO_VERSION= "2.0+snapshot-20160316"
> TUNE_FEATURES = "arm armv7a vfp thumb neon
> callconvention-hard   cortexa9"
> TARGET_FPU= "hard"
> meta
> meta-poky = "HEAD:8debfea81e69d038bd2d56314b272cb74f5582ed"
> meta-oe
> meta-multimedia
> meta-python
> meta-networking   = "HEAD:35d91f32c462ad5889cb3229766d6d4ed2c80a4c"
> meta-qt5  =
> "master-5.6:b2d5376b41625521b9a081fe800345fff33d8dd6"
> meta-ruby = "HEAD:35d91f32c462ad5889cb3229766d6d4ed2c80a4c"
> meta-fsl-arm  = "HEAD:37564e6801ce82fad979b4f57151c676d80e8a6c"
> meta-fsl-arm-extra = "HEAD:36a638abe1238bdc8e0ef1242dd7bfab59cc48d7"
> meta-fsl-demos= "HEAD:6b779b2cb0d231063fc035a9a0871d722366c329"
> meta-udoo = "master:1b38bcec5057b93017a00f107e0738ce64ade66f"
> meta-swupdate = "master:44516e81a494afef3be7e3f249713fdec6e6e32a"
> 
> NOTE: Preparing RunQueue
> NOTE: Executing SetScene Tasks
> NOTE: Executing RunQueue Tasks
> ERROR: gobject-introspection-1.46.0-r0 do_populate_sysroot: The recipe
> gobject-introspection is trying to install files into a shared area
> when those files already exist. Those files and their manifest
> location are:
>  
>  
> /data/FSL/fsl-community-bsp-master/build/tmp/sysroots/udooneo/usr/share/gobject-introspection-1.0/Makefile.introspection
>  Matched in manifest-udooneo-gtk-doc-stub.populate_sysroot
>  
> /data/FSL/fsl-community-bsp-master/build/tmp/sysroots/udooneo/usr/share/aclocal/introspection.m4
>  Matched in manifest-udooneo-gtk-doc-stub.populate_sysroot
> Please verify which recipe should provide the above files.
> The build has stopped as continuing in this scenario WILL break
> things, if not now, possibly in the future (we've seen builds fail
> several months later). If the system knew how to recover from this
> automatically it would however there are several different scenarios
> which can result in this and we don't know which one this is. It may
> be you have switched providers of something like virtual/kernel (e.g.
> from linux-yocto to linux-yocto-dev), in that case you need to execute
> the clean task for both recipes and it will resolve this error. It may
> be you changed DISTRO_FEATURES from systemd to udev or vice versa.
> Cleaning those recipes should again resolve this error however
> switching DISTRO_FEATURES on an existing build directory is not
> supported, you should really clean out tmp and rebuild (reusing sstate
> should be safe). It could be the overlapping files detected are
> harmless in which case adding them to SSTATE_DUPWHITELIST may be the
> correct solution. It could also be your build is including two
> different conflicting versions of things (e.g. bluez 4 and bluez 5 and
> the correct solution for that would be to resolve the conflict. If in
> doubt, please ask on the mailing list, sharing the error and filelist
> above.
> ERROR: gobject-introspection-1.46.0-r0 do_populate_sysroot: If the
> above message is too much, the simpler version is you're advised to
> wipe out tmp and rebuild (reusing sstate is fine). That will likely
> fix things in most (but not all) cases.
> ERROR: gobject-introspection-1.46.0-r0 do_populate_sysroot: Function
> failed: sstate_task_postfunc
> ERROR: Logfile of failure stored in:
> 
> /data/FSL/fsl-community-bsp-master/build/tmp/work/cortexa9hf-neon-poky-linux-gnueabi/gobject-introspection/1.46.0-r0/temp/log.do_populate_sysroot.16494
> ERROR: Task 1802
> 
> (/data/FSL/fsl-community-bsp-master/sources/poky/meta/recipes-gnome/gobject-introspection/gobject-introspection_1.46.0.bb
> <http://gobject-introspection_1.46.0.bb>,
> do_populate_sysroot) failed with exit code '1'
> NOTE: Tasks Summary: Attempted 4772 tasks of which 4742 didn't ne

Re: [yocto] Qt5.6 new modules

[Christian Ege]

Hi,,

2016-03-16 9:04 GMT+01:00 idealsim :
> Hi, we have build an image for udoo neo from meta-qt5 jansa/master-5.6 and
> works fine (thanks to Christian Ege ). The problem is that I'm looking for
> https://github.com/qtproject/qtquickcontrols2 and
> https://github.com/qtproject/qtserialbus. My question is how we can add this
> modules to our build ?  I add this to our local.conf :
>
> "qtquickcontrols2 \
>  qtserialbus \
> "
> But this modules don't have buildable providers ! If someone can help to
> said me how to proceed ...
You can try to add a meta-qt5/recipes-qt/qt5/qtserialbus_git.bb and
take for example meta-qt5/recipes-qt/qt5/qtsensors_git.bb as reference

require qt5.inc
require qt5-git.inc
# There are no LGPLv3-only licensed files in this component.
# There are no GPLv2 licensed files in this component.
LICENSE = "GFDL-1.3 & BSD & (LGPL-2.1 &
The-Qt-Company-Qt-LGPL-Exception-1.1 | LGPL-3.0)"
LIC_FILES_CHKSUM = " \
file://LICENSE.LGPLv21;md5=58a180e1cf84c756c29f782b3a485c29 \
file://LICENSE.LGPLv3;md5=b8c75190712063cde04e1f41b6fdad98 \
file://LICENSE.GPLv3;md5=40f9bf30e783ddc201497165dfb32afb \
file://LGPL_EXCEPTION.txt;md5=9625233da42f9e0ce9d63651a9d97654 \
file://LICENSE.FDL;md5=6d9f2a9af4c8b8c3c769f6cc1b6aaf7e \
file://LICENSE.GPLv2;md5=05832301944453ec79e40ba3c3cfceec \
"
DEPENDS += "qtbase"

SRCREV = "71a323e1f12df8d213a4052621027e223eb5a343"

The configure step will bail out due to the fact that you have wrong
checksums but it will show you the right ones

Best,
Christian


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



-- 
http://ch.ege.io/
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Image SDK with qmake

[Christian Ege]

Hi Stefano,


Am 8. März 2016 3:55:09 nachm. schrieb Stefano Cordibella 
:



Hi list,
 I am working on an image that use Qt5 and now I want to share an
SDK with some of our developers.

When I try to generate the SDK with bitbake -c populate_sdk
  there isn't a cross qmake in the generated SDK.
On the other hand when I try to use bitbake meta-toolchain-qt5 some
image libraries and tools are missing on the SDK.



Have you put this in your image?
inherit populate_sdk_qt5

Like I did for meta-udoo
https://github.com/graugans/meta-udoo/blob/jethro/qt5-layer/recipes-qt/images/udoo-image-qt5.bb

Best,
Christian


I read about Qt5 and SDK in the meta-qt5 wiki, but I suppose that the
related patch is integrated in the fido release that I am using.

So the question is: are there any way to generate a complete SDK with
Qt5 cross tools for my custom image? I have to add some sort on
nativesdk qt5 package to my image in IMAGE_INSTALL ?

Thank you in advance,
Stefano.

--
*Stefano Cordibella*
EDALab s.r.l. - Networked Embedded Systems

Strada Le Grazie, 15 - 37134 Verona - Italy
email : stefano.cordibe...@edalab.it
skype : stefano.cordibella
tel. : +39 045 802 70 85
web : www.edalab.it



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

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

Re: [yocto] Question about access local stash/bitbucket server via yocto

[Christian Ege]

Hi Rikard,

> My first post so here we go….
Welcome to the OpenEmbedded world.
>
> 1) I am new to yocto and so is the company I work for….
> 2) My companys firewall/intranet blocks git protocol so only http works…
welcome to my world

> Anyhow, in the company there is a local stash/bitbucket sever which run on
>  port number where I have some repositories and I am able to clone them
> with:
>
> git clone http://@:/XXX/~YYY/ZZZ.git ==> This works fine
> from command line, note the “~”
>
>
>
> However, now I want to do the clone from a yocto/bitbake file I created as
> follows:
>
> LIC_FILES_CHKSUM = "file://LICENSE;md5=X"
>
> FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}-${PV}:"
>
> SRCREV = "XXX"
>
> SRC_URI = "http:/@:/XXX/~YYY/ZZZ.git"
>
> However this fails with Username/Password Authentication Failed which I find
> strange since I have no problem with git clone …..
> Now I have two questions:
>
> 1) Is it possible to add my USER and PASSWORD in the bitbake/yocto (*.bb
> file) file to work around the Username/Password Authentication Failed
> problem.
>
> 2) I also have a question if there are any limitation in the path I use,
> for example:
>
> a. Is it OK to have  number as part of path, I haven’t seen that
> in any other files related to yocto/bitbake? And if not how do I specify the
> PORT number?
>
> b.Or maybe the “~” will cause problem , I haven’t seen this in any path
> names related to yocto/bitbake?
You have multiple options here:

- Switch to SSH for stash access
- Add a yocto user to stash and add those credentials to a the yocto
build users .netrc (http://www.mavetju.org/unix/netrc.php)
- Check poky/bitbake/lib/bb/fetch2/git.py what options are possible
for the git fetcher

You can wrap your stash URL in a Variable and set it in a global
location for example your conf/local.conf

MYFANCY_URI ??= "git://git..com/scm/proj"
MYFANCY_URI_PROTOCOL ??= "https"


> Any advice I appreciated.
>
>
>
> Mit freundlichen Grüßen / Best regards
Regards,
Christian
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Kernel build gets stuck in a endless loop

[Christian Ege]

Hi,

Thanks to Guiseppe Pagano, there is a solution for this issue. It is
more a hot fix than a real solution but this is maybe for someone else
helpful.

> Hi Crhistian,
> It is not a clean patch, but it works for me.
> 
> File:kernel_imx_3.14/Makefile
> 
> - $(Q)$(MAKE) -f $(srctree)/Makefile silentoldconfig
> + if [[ ! -e include/config/auto.conf ]]; then $(MAKE) -f
> $(srctree)/Makefile silentoldconfig ; fi
> 
> In this way:
> 
> 
> # If .config is newer than include/config/auto.conf, someone tinkered
> # with it and forgot to run make oldconfig.
> # if auto.conf.cmd is missing then we are probably in a cleaned tree so
> # we execute the config step to be sure to catch updated Kconfig files
> include/config/%.conf: $(KCONFIG_CONFIG) include/config/auto.conf.cmd
> if [[ ! -e include/config/auto.conf ]]; then $(MAKE) -f
> $(srctree)/Makefile silentoldconfig ; fi
> #   $(Q)$(MAKE) -f $(srctree)/Makefile silentoldconfig
> else
> # external modules needs include/generated/autoconf.h and
> include/config/auto.conf
> # but do not care if they are up-to-date. Use auto.conf to trigger the test
> PHONY += include/config/auto.conf
> 
> I had a similar problem during Android 5.0 build process, ad this patch
> solves. Hope it will the same for you.
> 
> If it works I'll pass the patch to udooneo Team.
I've added this to my UDOO layer in a slightly modified version:

https://github.com/graugans/meta-udoo/blob/jethro/recipes-kernel/linux/linux-udooboard/0003-avoid-endless-loop.patch

Regards,
Christian

> 
> Bye
> Giuseppe
> 
> 
> 
> 2016-01-03 19:14 GMT+01:00 Christian Ege  <mailto:k423...@gmail.com>>:
> 
> Hi Giuseppe,
> 
> Am 03.01.2016 7:08 nachm. schrieb "Giuseppe Pagano"
> >
> > Did you solved ?
> I did a little investigation but did not finally succeeded.
> > Maybe I have a patch for you.
> >
> This would be awesome.
> 
> Regards,
> Christian
> 
> 
> >
> >
> > Christian Ege k4230r6 at gmail.com <http://gmail.com> 
> > Sun Nov 29 12:24:50 PST 2015
> >
> > Previous message: [yocto] [meta-security][PATCH] nmap: package
> update to 7.0
> > Next message: [yocto] [Recipe reporting system] Upgradable recipe
> name list
> > Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
> > 
> >
> > Hi,
> >
> > can anyone give me some advice how to debug an endless loop during
> > kernel and module recipes with my UDOO Neo support layer?
> >
> > https://github.com/graugans/meta-fsl-arm-extra/tree/master-udooneo
> >
> > When I build the kernel for the UDOO Neo kernel or a module with
> bitbake
> > the bitbake process hangs in an endless loop:
> >
> >
> > bitbake -v kernel-module-imx-gpu-viv
> >
> > + cd
> >
> 
> /data/FSL/fsl-community-bsp-master/build/tmp/work/udooneo-poky-linux-gnueabi/kernel-module-imx-gpu-viv/5.0.11.p7.1+fslc+gitAUTOINC+eeeb23c0fb-r0/git
> > + do_make_scripts
> > + unset CFLAGS CPPFLAGS CXXFLAGS LDFLAGS
> > + make CC=arm-poky-linux-gnueabi-gcc  -mno-thumb-interwork -marm
> > -fuse-ld=bfd LD=arm-poky-linux-gnueabi-ld.bfd
> > AR=arm-poky-linux-gnueabi-ar  -C
> >
> 
> /data/FSL/fsl-community-bsp-master/build/tmp/work-shared/udooneo/kernel-source
> >
> 
> O=/data/FSL/fsl-community-bsp-master/build/tmp/work-shared/udooneo/kernel-build-artifacts
> > scripts
> >
> > make: Entering directory
> >
> 
> '/data/FSL/fsl-community-bsp-master/build/tmp/work-shared/udooneo/kernel-source'
> >
> >   GEN
> >
> 
> /data/FSL/fsl-community-bsp-master/build/tmp/work-shared/udooneo/kernel-build-artifacts/Makefile
> >
> > scripts/kconfig/conf --silentoldconfig Kconfig
> >
> >   GEN
> >
> 
> /data/FSL/fsl-community-bsp-master/build/tmp/work-shared/udooneo/kernel-build-artifacts/Makefile
> >
> > scripts/kconfig/conf --silentoldconfig Kconfig
> >
> >   GEN /data/FSL/fsl-community-bsp-master/build/tmp/work-shared
> >
> > For the kernel I can workaround this by adding the following line
> to the
> > recipe:
> >
> > B = "${S}"
> >
> > But this does not work for kernel module recipes like the
> > "kernel-module-imx-gpu-viv"
> 
> 

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

Re: [yocto] Power off IC over Yocto

[Christian Ege]

Am 15.12.2015 7:45 nachm. schrieb "Christian Ege" :
>
> Hi,
>
> Am 15.12.2015 6:45 nachm. schrieb "simo" :
> >
> > I am using a Gumtix Overo board and we create and expansion board that
> > power Overo and other devices by external power supply IC.
> >
> > Our expansion board with power supply are connected by I2C bus 2 in
> > overo (not the same i2C that TW4030 or tps6595 is connected).
> >
> > Using the Linux  command shutdown we would like to power off the hole
> > system.
> > We would like to close the linux and last thing send a command over I2C
> > to our power supply IC in order it disconnect the physical power.
> >
> > Our question is:
> >
> > Where we have to implement that function?
> > Is there any example of it?
> I guess you can use
> http://lxr.free-electrons.com/source/kernel/reboot.c
>
register_reboot_notifier is your friend
> You have to create some kernel module doing this or write a kernel patch.
>
> Regards,
> Christian
>
> > --
> > ___
> > 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] Power off IC over Yocto

[Christian Ege]

Hi,
Am 15.12.2015 6:45 nachm. schrieb "simo" :
>
> I am using a Gumtix Overo board and we create and expansion board that
> power Overo and other devices by external power supply IC.
>
> Our expansion board with power supply are connected by I2C bus 2 in
> overo (not the same i2C that TW4030 or tps6595 is connected).
>
> Using the Linux  command shutdown we would like to power off the hole
> system.
> We would like to close the linux and last thing send a command over I2C
> to our power supply IC in order it disconnect the physical power.
>
> Our question is:
>
> Where we have to implement that function?
> Is there any example of it?
I guess you can use
http://lxr.free-electrons.com/source/kernel/reboot.c

You have to create some kernel module doing this or write a kernel patch.

Regards,
Christian
> --
> ___
> 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] RFC: Reference updater filesystem

[Christian Ege]

On 23.11.2015 22:15, Mariano Lopez wrote:
> There has been interest in an image based software updater in Yocto
> Project. The proposed solution for a image based updater is to use
> Stefano Babic's software updater (http://sbabic.github.io/swupdate).
> This software do a binary copy, so it is needed to have at least two
> partitions, these partitions would be the rootfs and the maintenance
> partition. The rootfs it's the main partition used to boot during the
> normal device operation, on the other hand, the maintenance will be used
> to update the main partition.
> 
> To update the system, the user has to connect to device and boot in the
> maintenance partition; once in the maintenance partition the software
> updater will copy the new image in the rootfs partition. A final reboot
> into the rootfs it is necessary to complete the upgrade.
> 
> As mentioned before the the software will copy an image to the
> partition, so everything in that partition will be wiped out, including
> custom configurations. To avoid the loss of configuration I explore
> three different solutions:
> 1. Use a separate partition for the configuration.
>   a. The pro of this method is the partition is not touched during the
> update.
>   b. The con of this method is the configuration is not directly in
> rootfs (example: /etc).
> 
> 2. Do the backup during the update.
>   a. The pro is the configuration is directly in rootfs.
>   b. The con is If the update fail most likely the configuration would
> be lost.
> 
> 3. Have an OverlayFS for the rootfs or the partition that have the
> configuration.
>   a. The pro is the configuration is  "directly" in rootfs.
>   b. The con is there is need to provide a custom init to guarantee the
> Overlay is mounted before the boot process.
> 
> With the above information I'm proposing to use a separate partition for
> the configuration; this is because is more reliable and doesn't require
> big changes in the current architecture.
> 
> So, the idea is to have 4 partitions in the media:
> 1. boot. This is the usual boot partition
> 2. data. This will hold the configuration files. Not modified by updates.
> 3. maintenance. This partition will be used to update rootfs.
> 4. rootfs. Partition used for normal operation.
This is mostly what we have implemented for our O3D3xx 3D Camera at ifm.
We are using the swupdate tool developed by Stefano and sponsored
by ifm.

We have two flashes one small SPI NOR flash which is responsible for
booting and a larger NAND which contains the root filesystem.

Due to the restrictions to not have any buttons on the camera Stefano
implemented a boot counter which allows us to boot into swupdate from
the rootfs. Or if the rootfs is not able to boot we automatically boot
into swupdate mode itself.

To have the same ip address in both cases we have a small partition in
the SPI NOR which contains the network config and some stuff which must
retain during software update. The swupdate itself is implemented as a
kernel with an initramfs. We decided to have such an fallback to not
loose any camera during a field update. BTW this was a good decision and
we have a lot of good feedback on this feature.

Another option was the way how for example AVM Fritz.Box! implements the
update, they do download the image and install the image from the rootfs
during shutdown. But if someone removes power the box is bricked unless
you do some tftp magic. I guess swupdate is tunable to support this
usecase as-well.

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

[yocto] Kernel build gets stuck in a endless loop

[Christian Ege]

Hi,

can anyone give me some advice how to debug an endless loop during
kernel and module recipes with my UDOO Neo support layer?

https://github.com/graugans/meta-fsl-arm-extra/tree/master-udooneo

When I build the kernel for the UDOO Neo kernel or a module with bitbake
the bitbake process hangs in an endless loop:


bitbake -v kernel-module-imx-gpu-viv

+ cd
/data/FSL/fsl-community-bsp-master/build/tmp/work/udooneo-poky-linux-gnueabi/kernel-module-imx-gpu-viv/5.0.11.p7.1+fslc+gitAUTOINC+eeeb23c0fb-r0/git
+ do_make_scripts
+ unset CFLAGS CPPFLAGS CXXFLAGS LDFLAGS
+ make CC=arm-poky-linux-gnueabi-gcc  -mno-thumb-interwork -marm
-fuse-ld=bfd LD=arm-poky-linux-gnueabi-ld.bfd
AR=arm-poky-linux-gnueabi-ar  -C
/data/FSL/fsl-community-bsp-master/build/tmp/work-shared/udooneo/kernel-source
O=/data/FSL/fsl-community-bsp-master/build/tmp/work-shared/udooneo/kernel-build-artifacts
scripts

make: Entering directory
'/data/FSL/fsl-community-bsp-master/build/tmp/work-shared/udooneo/kernel-source'

  GEN
/data/FSL/fsl-community-bsp-master/build/tmp/work-shared/udooneo/kernel-build-artifacts/Makefile

scripts/kconfig/conf --silentoldconfig Kconfig

  GEN
/data/FSL/fsl-community-bsp-master/build/tmp/work-shared/udooneo/kernel-build-artifacts/Makefile

scripts/kconfig/conf --silentoldconfig Kconfig

  GEN /data/FSL/fsl-community-bsp-master/build/tmp/work-shared

For the kernel I can workaround this by adding the following line to the
recipe:

B = "${S}"

But this does not work for kernel module recipes like the
"kernel-module-imx-gpu-viv"

Maybe the cause of this issues is due to the fact that they have
included the backports subdirectory into their kernel?

https://github.com/UDOOboard/linux_kernel/tree/imx_3.14.28_1.0.0_ga_neo/backports

I already added some debugging code to the conf utility but it looks
like it does what it is supposed to do. But  I guess the surrounding
Makefile is not happy.


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

[yocto] Yocto on the UDOO Neo

[Christian Ege]

Hi,

if you have participated in the UDOO Neo Kickstarter campaign and
received your UDOO Neo you can try my meta-fsl-arm-extra fork with
UDOO Neo support

https://github.com/graugans/meta-fsl-arm-extra

My changes are in branch fido.

I'll prepare patches to meta-fsl-arm-extra when I have done more
testing.

In my branch there is also support for udooquad but those are fairly
untested because I do not have one.

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

Re: [yocto] VFAT patent EP 0 618 540

[Christian Ege]

Hi,
Am 09.10.2015 8:31 nachm. schrieb "Robert Berger" <
gm...@reliableembeddedsystems.com>:
>
> Hi,
>
> On 10/09/2015 11:36 AM, Gorny Krystian wrote:
> > Hi,
> >
> > I have a question regarding the VFAT patent (EP 0 618 540) owned by
> > Microsoft. It’s about common name space for long and short filenames. I
> > have read that this patent was canceled by Germany / EU, but it’s still
> > available in the US right? So is there a patch/option where we can
> > activate to avoid this patent?
>
> I am not a lawyer, but wouldn't it be easier not to use VFAT?
> The only reason I would use it, would be because the bootloader of my
> SoC would only be able to boot over FAT/FAT32 from a managed flash. A
> patch will not help here as well;)
A decent U-Boot can load the kernel from ext4. And I do not know any ROM
loader which needs vfat, except maybe this TI SOCs...

Regards,
Christian
>
> There are rumors that a fix was implemented a long time ago[1] ;)
>
> >
> > Thanks
> >
> > Krystian
> >
>
> Regards,
>
> Robert
>
>
> [1]
>
http://arstechnica.com/information-technology/2009/07/vfat-linux-patch-could-circumvent-microsofts-patent-claims/
>
> >
> > Legal information:
> > Wipotec Wiege- und Positioniersysteme GmbH
> > HRB 2317 Kaiserslautern, Management: T. Düppre, U. Wagner
> >
> > This e-mail may contain confidential and/or privileged information.
> > If you are not the intended recipient (or have received this e-mail in
> > error)
> > please notify the sender immediately and delete this e-mail. Any
> > unauthorized
> > copying, disclosure or distribution of the material in this e-mail is
> > strictly
> > forbidden.
> >
>
> Since you are concerned about legal issues you might also want to remove
> this footer when posting to public lists ;)
>
> >
> > --
> >
>
> ..."Rules of Optimization: Rule1: Don't do it. Rule 2 (for experts
> only): Don't do it yet." - M.A. Jackson (not the singer)
>
> My public pgp key is available,at:
> http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x90320BF1
>
>
> --
> ___
> 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] Generate iso image

[Christian Ege]

Hi,

2015-06-11 12:49 GMT+02:00 Mayank Agarwal :
> Hi,
>
> I have configured the yocto project and i am getting vmdk.ext3 image
> I want to configure that iso image should also be generated.
> I have changed IMAGE_FSTYPE in qemux86.conf to iso.
>
> But on building i am getting do_configure failure in grub_0.xx recipe.
> and the error is: cannot link at address 7C00
Can you please provide a more detailed error log?
>
> I think i am missing some setting in which i have to configure kernel
> to generate
> an iso image.
>
Regards,
Christian
>
> Regards,
> Mayank
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto



-- 
http://ch.ege.io/
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Start openvpn with my own config at startup

[Christian Ege]

> Am 27.05.2015 um 20:07 schrieb Matthew Karas :
> 
> I have an ovpn file I'd like my system to start up with.  I was able
> to install the openvpn file into /etc/openvpn using a bbappends file -
> but the system doesn't start openvpn like the openvpn docs describes.
> 
> How do I set up openvpn to launch with my config file at start up?
It depends if you build for a systemd or init.d based set-up. If you are 
building for init.d which is the default setting you can check the init script 
how openvpn is started:

http://cgit.openembedded.org/meta-openembedded/tree/meta-networking/recipes-support/openvpn/openvpn/openvpn
 


Regards,
Christian
> 
> Thanks
> -- 
> ___
> 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] Newb looking for where to start on unsupported hardware?

[Christian Ege]

Hi,
Am 07.05.2015 7:18 nachm. schrieb "daryl kuchay" :
>
> Hello,
>
> I'm about 3 weeks in to light reading in documentation on Yocto. I found
the project when searching for Open Embedded.
>
> My challenge is that I have ancient hardware. A Geode based tablet with
serial touchscreen and other niche items that will require me to build a
custom kernel for proper support. Also worthy of mention is that syslinux
is no longer supporting the hardware. Its not too far from an olpc but its
more proprietary. Made by DT Research. WebDT366 GX1 is the model.
>
Okay, as far as I remember geode is x86 architecture. So at-least
architecture is supported.

> While documentation does provide a great deal of information on what to
do once you get to the stage of building I am just not sure where to start.
I downloaded the build appliance but it only seems to build stock images
that allow for some scripted modification.
>
You have to create a new BSP layer for your board. Here is some
documentation

http://www.yoctoproject.org/docs/current/bsp-guide/bsp-guide.html

> Without a great deal of knowledge on bitbake or what would be needed in
the form of scripts I am not sure that this is the right path to take.
>
> Whats lacking in the documentation is an if/then scenario. Like if you
need to build a custom kernel start "here", then move to "here" and so on.
>
There is also a document on kernel development.
https://www.yoctoproject.org/training/kernel-lab

I learned a much from studying existing BSP layers. My source was the
raspberry pi layer.

> While I can find old mentions of OE-Classic build recipes for Geode I
cant seem to find out weather or not these are supported by Yocto.  The
docs seem to assume a level of knowledge that I do not have on open
embedded or a work flow within. Laying down that many bsp commands with no
knowledge of how to use is daunting.
>

Start with a known board and learn how to build the image and flash it and
boot. Or use a qemu machine as target to play with.

> Can someone help a newb out with where to start if one needed to config a
kernel, add a lot of software from inputattach to evdev, acpid,
xinput-calibrator and others? And how to move to the next step? My hope is
to make a .img that can be dd'd to the target with full hardware support.
>
Here as-well the RPI is a good source of information

http://git.yoctoproject.org/cgit/cgit.cgi/meta-raspberrypi/tree/classes/sdcard_image-rpi.bbclass?h=fido

> Thank you in advance
> Daryl

Regards,
Christian
>
> --
> ___
> 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] remove package from sdimg

[Christian Ege]

Hi,
Am 31.03.2015 17:07 schrieb "abhishek srivastava" :
>
> hi
> i have created core-image-sato sdimg for my project on raspberrypi.
actually, i want to run few applications that need python. i want to remove
unnecessary packages that were required for smooth compilation of those
applications since I downloaded entire python and gcc packages which had
heavily increased size of my sdimg size.
>
> how can i find which applications requires what packages for its normal
functionality so that i can further tweak my sdimg or keep exactly those
libraries that are needed for my application and remove rest.
> please help
>
Have a look at my cheat sheet:
https:// 
github.com /
cybertux
/
cheatsheets
/tree/master/
bitbake

Or in the yocto wiki:

https://wiki.yoctoproject.org/wiki/FAQ#How_can_one_view_the_dependencies_of_packages_and_the_resulting_growth_in_code_size_as_packages_are_added.3F

Regards,
Christian
> regards
> Abhishek
>
> --
> ___
> 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] How to support arm-none-eabi toolchain for u-boot on Amlogic

[Christian Ege]

Am 19.03.2015 00:35 schrieb "Khem Raj" :
>
> On Wed, Mar 18, 2015 at 12:55 PM, Christian Ege  wrote:
> > Hello,
> >
> > it looks like that Amlogic based devices like the ODROID-C1 [1]
> > requires their u-boot compiled with an arm-none-eabi toolchain. The
> > rest kernel and rootfs is compiled with standard arm eabi toolchain. I
> > am wondering how to support this in yocto/openembedded.
>
> are there any specific reasons for doing that ?
> can it be done by passing -ffreestanding option via CFLAGS
> afterall uboot is a baremetal/standalone app.

I do not know any reason, but all tutorials require a arm-none-eabi
toolchain. Could this be required by the ROM bootloader? Frankly I not
familiar with this eabi none eabi difference. Due to the fact that there is
lack of documentation I have to try if I can build it with eabi toolchain.

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

[yocto] How to support arm-none-eabi toolchain for u-boot on Amlogic

[Christian Ege]

Hello,

it looks like that Amlogic based devices like the ODROID-C1 [1]
requires their u-boot compiled with an arm-none-eabi toolchain. The
rest kernel and rootfs is compiled with standard arm eabi toolchain. I
am wondering how to support this in yocto/openembedded.

With kind regrads,
Christian


[1] http://odroid.com/dokuwiki/doku.php?id=en:c1_building_u-boot
-- 
http://project-magpie.github.io/
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-raspberrypi] Pi-2 support?

[Christian Ege]

Am 24.02.2015 um 22:07 schrieb Gary Thomas:

Any ideas when this layer might support the new Pi-2?
Is anyone working on it?


Andrei Gherzan already sended some Patches to this ML
http://comments.gmane.org/gmane.linux.embedded.yocto.general/23265

It looks like those are already merged:
http://git.yoctoproject.org/cgit/cgit.cgi/meta-raspberrypi/commit/?id=54c5451a04a2b6601ca729038780d4e4eb69437e

regards,
Christian


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

Re: [yocto] do_install() is not getting called

[Christian Ege]

Am 08.11.2014 13:10 schrieb "hari kumar" :
>
> Hi All,
>
> I am creating a new recipe in bsp layer. So I created a bb file inside
the recipe.
> Then from the build directory, I am able to successfully compile the
source files and was able to create the library ( bitbake -c compile -f
 ). This is a makefile based package and I don't have an
install target in my Makefile. So I am writing a do_install in my bb file
and I am doing install there. I can see that do_compile task is getting
called. But do_install ( which was overridden in my bb file ) task is not
called and the images and libraries are not installed in the sysroots
directory.
>
By running bitbake -f -c compile the do_install is not called. Either you
call bitbacke package_name or to force install butbake -c install.

Sometime a clean or cleanall before a compile also helps. This is needed if
you already had a successfull run.

Regards
Christian
> Bitbake Snippet :
>
> SRC_URI = "file://src/"
>
> PV = "1.0"
>
> S = "${WORKDIR}/src/"
>
> EXTRA_OEMAKE = "CFLAGS=--sysroot=${PKG_CONFIG_SYSROOT_DIR}
'LDFLAGS=-lpthread -lrt ${LDFLAGS}'"
>
> do_install () {
> oe_runmake install DESTDIR=${D} SBINDIR=${sbindir} MANDIR=${mandir}
INCLUDEDIR=${includedir}
>install -d ${D}${includedir}/
>
>for f in ${S}/*.h; do
>install -m 0644 $f ${D}${includedir}/
>done
>
> }
> PARALLEL_MAKE = ""
> #BBCLASSEXTEND = "native"
>
> Could you please suggest why do_install is not getting called for this
Makefile based system ?
>
> --
> ___
> 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] Creating new u-boot board

[Christian Ege]

Am 16.10.2014 02:40 schrieb "Matt Schuckmann" :
>
> I'm pretty confused about what is the best way to go on this.
> I realize that there are several paths that I could take but I really
don't know which is the best way to go.
>
> We are creating a new board largely based off the beaglebone design but
customized to our needs.
> I'm basing my software work off the TI SDK 7.0 (yes I know that is almost
a year but it is the TI blessed version)
>
> I feel like I need to create a new u-boot board configuration which I
have done in my own sandbox.
>
> Now I don't know if I should be creating a patch for my changes and
adding them to a bbappends for the ti u-boot recipe or if I should create a
new clone of ti's u-boot repo to check my changes into and create a new
recipe that references my repo? Or is there another option that I should be
exploring.
>
If you only made a few changes like config the easiest way may be just to
patch inside a bbappend.

If there are changes in the u-boot itself it may worth to run an own u-boot
git and sync it with denx or TI.

You can overwrite the SRC_URI in the bbappend as-well.

I am a bbappend fan boy so I would prefer this over an new recipe.

But it may worth to look at the various layers like freescale and TI how
they solved this.

> Which path is preferred?
There is no silver bullet.
> What are the short/long term pro's and con's of each approach?
>
Regards,
Christian
> Matt S.
>
> --
> ___
> 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] cellular modem connection with USB: how to have /dev/ttyACM0 interface?

[Christian Ege]

Am 10.10.2014 18:13 schrieb "Simon Andrieu" :
>
> Hi,
>
>
>
> I work on connecting a cellular module (with H24 Telit component) using
an USB interface to our Yocto distribution.
>
> The /dev/ttyACM0 interface is not mounted on the Yocto distribution I use
following USB connection. Here are the dmesg logs:
>
> [65133.056335] usb 2-1: new high speed USB device using musb-hdrc and
address 2
>
> [65133.214965] usb 2-1: device v22b8 p2d91 is not supported
>
> [65133.220520] usb 2-1: New USB device found, idVendor=22b8,
idProduct=2d91
>
> [65133.227508] usb 2-1: New USB device strings: Mfr=1, Product=2,
SerialNumber=0
>
> [65133.234924] usb 2-1: Product: Motorola Phone (H24)
>
> [65133.239929] usb 2-1: Manufacturer: Motorola, Inc.
>
> [65133.274108] usbcore: registered new interface driver cdc_acm
>
> [65133.280029] cdc_acm: v0.26:USB Abstract Control Model driver for USB
modems and ISDN adapters
>
>
>
> Maybe the used cdc-acm driver is not the right version.
>
> Would you know which cdc-acm driver version I should use please?
>
> How is it possible to change/upgrade the cdc-acm module?
>
> Would you have any advice to help me please?
>
Is udev/systemd up and running?

Regards,
Christian
>
>
> Thanks for your help.
>
>
>
> Regards,
>
> Simon Andrieu
>
>
>
>
> --
> ___
> 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] PR and bbappend files

[Christian Ege]

Hi,
2014-09-28 11:47 GMT+02:00 Chris Tapp :
> I'm currently using a bbappend file to patch bash under 'danny' due to 
> "Shellshocked" - basically by adding patches 11..50 to the SRC_URI.
>
> However, patches are still coming out ;-)
>
> How do I make sure that new ones get reflected in the build? I would normally 
> bump PR in a .bb file, but I don't think a .bbappend should be changing this?
For danny you can use PRINC
http://www.yoctoproject.org/docs/1.3.2/poky-ref-manual/poky-ref-manual.html#var-PRINC
For newer releases this is deprecated.

Could you please be so kind and share your bbappend + patches?
Is there any chance to get this in the official poky branches?


regards,
Christian
>
> --
>
> Chris Tapp
> opensou...@keylevel.com
> www.keylevel.com
>
> 
> You can tell you're getting older when your car insurance gets real cheap!
>
>
>
>
>
>
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto



-- 
http://project-magpie.github.io/
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Building kernel modules as dependencies

[Christian Ege]

Hi Andreas,

> I created recipes for two out-of-tree kernel modules written by myself
> in Yocto. I added these two modules in the machine config to
> MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS or even
> MACHINE_ESSENTIAL_EXTRA_RDEPENDS.
Have you used the name of your recipe or kernel-module-my-module-name?

> The modules build fine if I build them as targets with bitbake. The
> right packages are generated and if I build the image after that, they
> are included into the rootfs.
> But if the modules are not build by hand before building the image, they
> aren't built as dependencies and RRECOMMENDS just doesn't include them
> into the image as it is supposed to do and RDEPENDS fails of course with
> "Nothing PROVIDES kernel-module-my-module-name".
>
> How can I build the kernel modules as image dependencies?
> I can't seem to get it done with the countless approaches I already
> tried. For example just adding the modules to CORE_IMAGE_EXTRA_INSTALL
> didn't work either.
>
Maybe you can provide a more complete example

regards,
Christian

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



-- 
http://project-magpie.github.io/
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Pulseadudio depends

[Christian Ege]

Am 28.06.2014 21:54 schrieb "Michael Gloff" :
>
> All,
> I'm having some build errors when pulseaudio tries to configure. It looks
like there is a dependency on libcap. If the image already has libcap
pulled in or I manually make it so, everything is fine. Just wondering if
anyone else has experienced this and/or can duplicate on a clean build.
>
It may fixes your Problem by addind RDEPENDS += "libcap"

to the pulsaudio recipe. It may worth filing a patch if it is fixed.

Regards,
Christian
> Thanks,
>
> Michael Gloff
>
>
> --
> ___
> 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] FTDI support in yocto on CGTQMX6

[Christian Ege]

Am 16.06.2014 13:23 schrieb "Joshua Collins" :
>
> Hi,
>
>
>
> I have successfully built the 'fsl-image-gui' image and installed it on
my cqtqmx6. I require FTDI drivers to be installed to detect a usb device
as a serial port. I am unsure how to go about adding these drivers. I have
tried modifying my local.conf file with the following line:
>
The ftdi drivers are part of the kernel, you have to enable it by adding
them in your kernel config. This can be done by bbappend.

http://www.yoctoproject.org/docs/1.6/kernel-dev/kernel-dev.html

I you need libftdi, you may have to add a recipe to support it.

>
> PACKAGECONFIG_append_pn = " libftdi"
>
>
>
> which didn't seem to do anything. I also tried:
>
>
>
> IMAGE_INSTALL_append = " libftdi"
>
>
>
> Which caused bitbake to fail with the error: "ERROR: QA Issue: libftdi:
The compile log indicates that host include and/or library paths were used."
>
>
>
> I don't have a great understanding of knowing how to add more features to
my yocto image, and would appreciate any help with enabling FTDI support.
>
>
Regards,
Christian
>
> Cheers,
>
> Josh
>
>
>
>
> --
> ___
> 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] Why use Yocto?

[Christian Ege]

Am 10.06.2014 12:38 schrieb "Paul Barker" :
>
> On Mon, Jun 09, 2014 at 03:52:50PM -0700, Marlon Smith wrote:
> > Hi everyone,
> >
> > I'm developing a product that will run on a custom i.MX6 board and I'm
> > trying to decide whether to use Yocto or Ubuntu (there's a version of
> > Ubuntu packaged for the Wandboard that will run on our board).  The
> > board will run our own custom app, and we'll modify the Linux kernel to
> > support our hardware.
> >
> > Ubuntu seems like it would be ready to go - just put it on an SD card,
> > boot the board, compile the app and create a new SD card image from the
> > result to use for manufacturing.
> >
> > Yocto seems like it would be easier to remove unneeded packages from,
> > and easier to cross-compile the application for.  This means we could
> > have a smaller SD card image in the end.
> >
> > What are your thoughts on this?
>
> Philip has already mentioned license compliance in his reply, I'd like to
add a
> couple of other points:
>
> - In addition to a smaller image, you should have less services running by
>   default and so lower power usage.
>
This is because yocto splits documentation and not needed stuff in separate
packages. In ubuntu you have to remove a lot of stuff.
> - It's much easier to do consistent, reproducible image builds which
include
This us a major feature. You can build the whole image by Jenkins or any
other build server.
>   your own packages. Rather than having a series of steps such as
installing
>   Ubuntu on an SD card, booting, installing required additional packages,
>   downloading your source code to the card, building and then installing,
you
>   just do 'bitbake my-image' and everything you need is encoded in recipe
files
>   which you can keep under version control. There's less chance for human
error
>   to creep in.
>
> - You don't need to install the toolchain on the board itself, you can do
the
You can even create your own toolchain with all needed headers. And it is
damn easy to remote debug your application from eclipse for example.
>   system build on a separate machine and not pollute the SD card image
with the
>   history of building your software. It saves you the time of going
through and
>   removing the things you need to build your software but aren't needed
to run
>   it, which you'll probably end up doing to reduce the image size.
>
> - You'll have a great community of people doing similar things with the
Yocto
+1
>   Project. I don't know of a similar community for modifying Ubuntu SD
card
>   images in this fashion.
>
And you can fine tune all those recipe and build for example a hard float
or a softfloat image.

It is a little bit hard to get started but if you get familiar with this.
There is no alternative :)

--
Christian Ege
> Hope this helps,
>
> --
> Paul Barker
>
> Email: p...@paulbarker.me.uk
> http://www.paulbarker.me.uk
>
> --
> ___
> 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] How to run c++ programs?

[Christian Ege]

Am 24.04.2014 04:46 schrieb "Rich Wilson" :
>
> I have my core-image-minimal distribution working.
> Now, I would like to compile and run c++ programs.
> How do get there from here?
>

I think bitbake -c populate_sdk is what you are looking for. This creates
an SDK with the required headers and libs to compile your c++ code against.

> I'm a newbie here, so please be gentle :-)
>
> (I'm hoping I can use the Xilinx SDK for the compiler and
> debugger; I think I just need the libraries)
>
The approach above generates a complete SDK.
> Build Configuration:
> BB_VERSION= "1.20.0"
> BUILD_SYS = "x86_64-linux"
> NATIVELSBSTRING   = "openSUSE-project-12.3"
> TARGET_SYS= "arm-poky-linux-gnueabi"
> MACHINE   = "zedboard-zynq7"
> DISTRO= "poky"
> DISTRO_VERSION= "1.5.1"
> TUNE_FEATURES = " armv7a vfp neon zynq"
> TARGET_FPU= "vfp-neon"
> meta
> meta-yocto
> meta-yocto-bsp= ":"
> meta-xilinx   = "dora:aa7d677515ab7d45bbd3bdd6c5383f4143147c6d"
>
> --
> Rich Wilson
>
>
> --
> ___
> 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] File not found when trying to run an executable not build by Yocto

[Christian Ege]

Hi,

Hi,

I am building an image for an embedded system using the chiefriver and 
kernel 3.12.9.  I am using Ubuntu as our base system.


The image builds and boots fine which is great but we have some 
binaries built on Ubuntu which must run on the Yocto image.  When we 
copy these across and try and run them we get a "File Not Found" error.


Why would this be?  Doing file on our ubuntu executables we get:

/bin/true: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), 
dynamically linked (uses shared libs), for GNU/Linux 2.6.24, 
BuildID[sha1]=0x2b45516be4a9f45b1127d54efb0d42e5f69b1c82, stripped



Just for the sake of completeness:
- Have you either copied the files to /usr/bin or using ./executable_name?
- Have you made a chmod+x executable_name before?

Sometimes transfering files over ftp in ASCII mode results in funny 
behaviours


regrads,
Christian

The Yocto executables are the same except instead of GNU/Linux 2.6.24 
it is 2.6.16.  It that a problem?


Also, on ubuntu we are running libc-2.17 but on Yocto it is libc-2.18. 
 Is that a problem?


Thanks for any assistance,
Dave


___
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] SRCREV for BBLAYERS

[Christian Ege]

Hi,

> Hi Paul,
> thanks for your quick answer!
> I'll work with separate checkouts for now...
>
> But now I've got another question:
> Is there any possibility to submit something like a feature request for this?
> And is there a (realistic) chance that this feature gets implemented?
> If so, where should this request go? To the bitbake-devel list?
I am not sure If I got your point. If you intend to handle different
versions of layers you are using you may can use the setup-scripts
from Angstrom
They do use an "layer manager"
https://github.com/Angstrom-distribution/setup-scripts
https://github.com/Angstrom-distribution/setup-scripts/blob/master/sources/layers.txt

Which fetches the configured layers with the defined branch and commit ID.


regards,
Christian

>
> best regards,
> Richard
>
>> -Original Message-
>> From: Paul Eggleton [mailto:paul.eggle...@linux.intel.com]
>> Sent: Monday, February 03, 2014 3:46 PM
>> To: Richard Leitner - SKIDATA
>> Cc: yocto@yoctoproject.org
>> Subject: Re: [yocto] SRCREV for BBLAYERS
>>
>> Hi Richard,
>>
>> On Monday 03 February 2014 12:17:04 Richard Leitner - SKIDATA wrote:
>> > I've a question regarding the BBLAYERS variable.
>> > Is it possible to set some kind of a SRCREV (=> git
>> > tag/branch/commit-id) for a path listed in BBLAYERS?
>> >
>> > I came to this question because I've two different branches in my meta
>> > layer: one for development and one for 'stable' releases. Therefore I
>> > have also two different build dirs and want to 'pin' the branches/tags
>> > to the build dir (preferable via the bblayers.conf). I think this
>> > should be possible because at the start of a build the revs are displayed 
>> > like:
>> > meta-yocto = "[branch]:[commit-id]" The problem is that I wasn't able
>> > to find any answers or solutions on the web so I ask you now for help.
>>
>> The build system doesn't actually manage checking out/updating layers for 
>> you, it only
>> reports the revision if there is one, so this functionality isn't supported. 
>> Probably the
>> easiest way to handle this would be to keep two separate checkouts.
>>
>> Cheers,
>> Paul
>>
>> --
>>
>> Paul Eggleton
>> Intel Open Source Technology Centre
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] How to fix : "WARNING: The recipe XXX is trying to install files into a shared area ..."

[Christian Ege]

Hi,

I do have two recipes which install files in a shared area both packages 
install files with the same name but maybe with
a slightly different content. So splitting packages will not be a good 
solution. What else can I do?


I tried setting both packages to conflict each other that also did not 
fixed things up.


Are there any hints?

regards,

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

[yocto] eglibc-locale issue in dora for populate_sdk

[Christian Ege]

Hi,

may I ask to have an minor patch backportet to dora? The patch I am
talking about is the following:
http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/meta/recipes-core/eglibc/eglibc-locale.inc?id=ef942e3abdfa822271efd7c0f629829a80132fe5

Without this patch It is not possible to build an SDK image for my SH4
port based on dora.

With kind regards,
Christian Ege

---
http://project-magpie.github.io/
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] FW: YP Linux Kernel Development Manual

[Christian Ege]

Hi,
I am not sure if this is the problem you are struggling with.
I am wondering why class module.bbclass behaves completely different
than kernel.bbclacc


 hi, I follow the kernel development manual "2.5. Incorporating
Out-of-Tree Modules",
 copy the "hello-mod_0.1.bb" and "files" folder into my taget layer
"meta-intel/meta-jasperforest/recipe-kernel", then add 
"MACHINE_EXTRA_

RDEPENDS += "kernel-module-hello" in the conf/local.conf
 after build and boot, there's no "hello.ko" found in the binary 
image

 also there's no hello.ko in the "tmp/work/..." folder


If you hello-mod_0.1.bb inherits module class there is no mechanism
to create the kernel-module package. This only applies to the 
kernel.bbclass


http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/classes/module.bbclass
http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/classes/module-base.bbclass

Have a look at kernel.bbclass instead shows some pathon code which 
handles the module package creation:

http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/classes/kernel.bbclass#n301

I've fixed this in my layer by stealing the code from kernel.bbclass
https://github.com/project-magpie/meta-stlinux/blob/master/recipes-bsp/tdt-driver/tdt-driver.inc

With this you can also use the following extends with your module:
module_autoload_aotom = "aotom"
and
module_conf_stmfb = "options stmfb 
display0=1280x720-32@50:8m:pal:yuv:yuv"


If you are only inherting from module this have not worked for me.

The next part I had to fight against was the fact that in 
core-image-minimal the package managment information are stripped and 
thus no pre hooks are executet. So the module is installed in the image 
but not loaded on boot-up unless you call update-modules by hand.


ROOTFS_POSTPROCESS_COMMAND += "remove_packaging_data_files ; "

To prevent this I've defined an image without the stripping:
https://github.com/project-magpie/meta-stlinux/blob/master/recipes-core/images/core-image-base.bb

I hope this clarify things a little bit


regards,
Christian



 Eddy

All,

There is a new YP manual under development. It is a development 
manual
for Linux kernels in the YP. Darren Hart is the original author of 
the

manual as you probably know. It is still being worked on but it is in
HTML form and now part of the yocto-docs/master branch. It is
published at
http://www.yoctoproject.org/docs/1.4/kernel-dev/kernel-dev.html [1].
Feel free to access it and comment.

Thanks,

Scott

Scott Rifenbark

Intel Corporation

Yocto Project Documentation

503.712.2702

503.341.0418 (cell)

___

yocto mailing list

yocto@yoctoproject.org [2]

https://lists.yoctoproject.org/listinfo/yocto [3]



Links:
--
[1] http://www.yoctoproject.org/docs/1.4/kernel-dev/kernel-dev.html
[2] mailto:yocto@yoctoproject.org
[3] https://lists.yoctoproject.org/listinfo/yocto
Hi,

I am reposting this to the discussion list and copying Darren Hart.

Scott

FROM: Eddy Lai GMail [mailto:eddy.lai...@gmail.com]
 SENT: Monday, January 21, 2013 3:36 PM
 TO: Rifenbark, Scott M
 SUBJECT: Re: [yocto] YP Linux Kernel Development Manual

hi

 hi, I follow the kernel development manual "2.5. Incorporating
Out-of-Tree Modules",
 copy the "hello-mod_0.1.bb" and "files" folder into my taget layer
"meta-intel/meta-jasperforest/recipe-kernel", then add 
"MACHINE_EXTRA_

RDEPENDS += "kernel-module-hello" in the conf/local.conf
 after build and boot, there's no "hello.ko" found in the binary 
image

 also there's no hello.ko in the "tmp/work/..." folder

 Eddy

All,

There is a new YP manual under development. It is a development 
manual
for Linux kernels in the YP. Darren Hart is the original author of 
the

manual as you probably know. It is still being worked on but it is in
HTML form and now part of the yocto-docs/master branch. It is
published at
http://www.yoctoproject.org/docs/1.4/kernel-dev/kernel-dev.html [1].
Feel free to access it and comment.

Thanks,

Scott

Scott Rifenbark

Intel Corporation

Yocto Project Documentation

503.712.2702

503.341.0418 (cell)

___

yocto mailing list

yocto@yoctoproject.org [2]

https://lists.yoctoproject.org/listinfo/yocto [3]



Links:
--
[1] http://www.yoctoproject.org/docs/1.4/kernel-dev/kernel-dev.html
[2] mailto:yocto@yoctoproject.org
[3] https://lists.yoctoproject.org/listinfo/yocto


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

Re: [yocto] FW: YP Linux Kernel Development Manual

[Christian Ege]

Am Dienstag, den 22.01.2013, 11:14 +0100 schrieb Darren Hart 
:

On 01/22/2013 12:59 AM, Christian Ege wrote:

 Hi,
 I am not sure if this is the problem you are struggling with.
 I am wondering why class module.bbclass behaves completely 
different

 than kernel.bbclacc


 hi, I follow the kernel development manual "2.5. Incorporating
Out-of-Tree Modules",
 copy the "hello-mod_0.1.bb" and "files" folder into my taget layer
"meta-intel/meta-jasperforest/recipe-kernel", then add
"MACHINE_EXTRA_
RDEPENDS += "kernel-module-hello" in the conf/local.conf
 after build and boot, there's no "hello.ko" found in the binary
image
 also there's no hello.ko in the "tmp/work/..." folder


 If you hello-mod_0.1.bb inherits module class there is no mechanism
 to create the kernel-module package. This only applies to the
 kernel.bbclass

 
http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/classes/module.bbclass
 
http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/classes/module-base.bbclass


 Have a look at kernel.bbclass instead shows some pathon code which
 handles the module package creation:
 
http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/classes/kernel.bbclass#n301


 I've fixed this in my layer by stealing the code from 
kernel.bbclass
 
https://github.com/project-magpie/meta-stlinux/blob/master/recipes-bsp/tdt-driver/tdt-driver.inc


 With this you can also use the following extends with your module:
 module_autoload_aotom = "aotom"
 and
 module_conf_stmfb = "options stmfb
 display0=1280x720-32@50:8m:pal:yuv:yuv"


Christian, this is a really good point I hadn't considered. Would you
care to take a stab at adding this to module.bbclass and sending the
patch to the oe-core list for review? CC'ing myself?


I'll try to write a patch. Maybe tomorrow or by end of the week. I'll 
send it to oe-core and

to you in CC.

regrads,

Christian



Thanks,


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

Re: [yocto] Build external module against Yocto kernel

[Christian Ege]

Hi,
I am not sure if this is the problem you are struggling with.
I am wondering why class module.bbclass behaves completely different
than kernel.bbclacc


 copy the "hello-mod_0.1.bb" and "files" folder into my taget layer
"meta-intel/meta-jasperforest/recipe-kernel", then add 
"MACHINE_EXTRA_

RDEPENDS += "kernel-module-hello" in the conf/local.conf
 after build and boot, there's no "hello.ko" found in the binary 
image

 also there's no hello.ko in the "tmp/work/..." folder


If you hello-mod_0.1.bb inherits module class there is no mechanism
to create the kernel-module package. This only applies to the 
kernel.bbclass


http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/classes/module.bbclass
http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/classes/module-base.bbclass

Have a look at kernel.bbclass instead shows some pathon code which 
handles the module package creation:

http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/classes/kernel.bbclass#n301

I've fixed this in my layer by stealing the code from kernel.bbclass
https://github.com/project-magpie/meta-stlinux/blob/master/recipes-bsp/tdt-driver/tdt-driver.inc

With this you can also use the following extends with your module:
module_autoload_aotom = "aotom"
and
module_conf_stmfb = "options stmfb 
display0=1280x720-32@50:8m:pal:yuv:yuv"


If you are only inherting from module this have not worked for me.

The next part I had to fight against was the fact that in 
core-image-minimal the package managment information are stripped and 
thus no pre hooks are executet. So the module is installed in the image 
but not loaded on boot-up unless you call update-modules by hand.


ROOTFS_POSTPROCESS_COMMAND += "remove_packaging_data_files ; "

To prevent this I've defined an image without the stripping:
https://github.com/project-magpie/meta-stlinux/blob/master/recipes-core/images/core-image-base.bb

I hope this clarify things a little bit


regards,
Christian



 Eddy

All,

There is a new YP manual under development. It is a development 
manual
for Linux kernels in the YP. Darren Hart is the original author of 
the

manual as you probably know. It is still being worked on but it is in
HTML form and now part of the yocto-docs/master branch. It is
published at
http://www.yoctoproject.org/docs/1.4/kernel-dev/kernel-dev.html [1].
Feel free to access it and comment.

Thanks,

Scott

Scott Rifenbark

Intel Corporation

Yocto Project Documentation

503.712.2702

503.341.0418 (cell)

___

yocto mailing list

yocto@yoctoproject.org [2]

https://lists.yoctoproject.org/listinfo/yocto [3]



Links:
--
[1] http://www.yoctoproject.org/docs/1.4/kernel-dev/kernel-dev.html
[2] mailto:yocto@yoctoproject.org
[3] https://lists.yoctoproject.org/listinfo/yocto
Hi,

I am reposting this to the discussion list and copying Darren Hart.

Scott

FROM: Eddy Lai GMail [mailto:eddy.lai...@gmail.com]
 SENT: Monday, January 21, 2013 3:36 PM
 TO: Rifenbark, Scott M
 SUBJECT: Re: [yocto] YP Linux Kernel Development Manual

hi

 hi, I follow the kernel development manual "2.5. Incorporating
Out-of-Tree Modules",
 copy the "hello-mod_0.1.bb" and "files" folder into my taget layer
"meta-intel/meta-jasperforest/recipe-kernel", then add 
"MACHINE_EXTRA_

RDEPENDS += "kernel-module-hello" in the conf/local.conf
 after build and boot, there's no "hello.ko" found in the binary 
image

 also there's no hello.ko in the "tmp/work/..." folder

 Eddy

All,

There is a new YP manual under development. It is a development 
manual
for Linux kernels in the YP. Darren Hart is the original author of 
the

manual as you probably know. It is still being worked on but it is in
HTML form and now part of the yocto-docs/master branch. It is
published at
http://www.yoctoproject.org/docs/1.4/kernel-dev/kernel-dev.html [1].
Feel free to access it and comment.

Thanks,

Scott

Scott Rifenbark

Intel Corporation

Yocto Project Documentation

503.712.2702

503.341.0418 (cell)

___

yocto mailing list

yocto@yoctoproject.org [2]

https://lists.yoctoproject.org/listinfo/yocto [3]



Links:
--
[1] http://www.yoctoproject.org/docs/1.4/kernel-dev/kernel-dev.html
[2] mailto:yocto@yoctoproject.org
[3] https://lists.yoctoproject.org/listinfo/yocto



On Jan 16, 2013, at 11:11 AM, Darren Hart  
wrote:

On 01/15/2013 10:38 AM, Bruce Ashfield wrote:


I finally found the entries that I was recalling earlier. They are:

https://bugzilla.yoctoproject.org/show_bug.cgi?id=241
https://bugzilla.yoctoproject.org/show_bug.cgi?id=1614
https://bugzilla.yoctoproject.org/show_bug.cgi?id=2968

1614 and 2968 are the most interesting for what you are asking.

As you can see the net result of those bugs is that you can get the
right parts of the kernel tree in SDK packages, since they include
dev packages, and with what is currently in kernel-dev .. it should
be enough to build against in the SDK (perhaps with just the 
LDFLAGS

tw

Re: [yocto] How to handle src.rpm packages

[Christian Ege]

Hi,

I think src rpms are not that interesting stuff for a lot of you. I've 
fixed this by my own by adding a class to my meta-stlinux layer which 
handles the extra sources and patches within the *.src.rpm.


The idea was taken from the lsof package.

LOCAL_SRC ??= ""

def src_rpm_do_base(d,func):
bb.build.exec_func(func, d)
src_uri = d.getVar('SRC_URI')
d.setVar('SRC_URI', '${LOCAL_SRC}')
bb.build.exec_func(func, d)
d.setVar('SRC_URI', src_uri)



python do_unpack () {
src_rpm_do_base(d,'base_do_unpack')
}

python do_patch () {
src_rpm_do_base(d,'base_d
}

https://github.com/project-magpie/meta-stlinux/blob/master/classes/src_rpm.bbclass

I hope this is the way things like this should be handled.

regards,

Christian




Hello,

I am interested in how to handle source code inside of a src.rpm 
package. There had been a patch from Mark Hatle which handles the rpm 
packages inside the fetcher2. In his patch he suggests to handle 
Patches inside the rpm in the following way:



file://${WORKDIR}/mypatch.patch

When I tried this inside the SRC_URI declaration I always get en error 
like this:


NOTE: Running task 439 of 669 (ID: 4, 
/home/chris/src/poky-denzil/meta-stlinux/recipes-core/stslave/stslave_0.7.bb, 
do_fetch)

NOTE: package stslave-0.7-r1: task do_fetch: Started
ERROR: Function failed: Fetcher failure for URL: 
'file:///home/chris/src/poky-denzil/spark7162-build/tmp/work/sh4-poky-linux/stslave-0.7-r1/stslave-0.7.tar.gz'. 
Unable to fetch URL from any source.
ERROR: Logfile of failure stored in: 
/home/chris/src/poky-denzil/spark7162-build/tmp/work/sh4-poky-linux/stslave-0.7-r1/temp/log.do_fetch.25817

Log data follows:
| DEBUG: Trying PREMIRRORS
| DEBUG: For url ['file', '', 
'/home/chris/src/poky-denzil/spark7162-build/tmp/work/sh4-poky-linux/stslave-0.7-r1/stslave-0.7.tar.gz', 
'', '', {}] comparing ['bzr', '.*', '/.*', '', '', {}] to ['http', 
'downloads.yoctoproject.org', '/mirror/sources/', '', '', {}]
| DEBUG: For url ['file', '', 
'/home/chris/src/poky-denzil/spark7162-build/tmp/work/sh4-poky-linux/stslave-0.7-r1/stslave-0.7.tar.gz', 
'', '', {}] comparing ['cvs', '.*', '/.*', '', '', {}] to ['http', 
'downloads.yoctoproject.org', '/mirror/sources/', '', '', {}]
| DEBUG: For url ['file', '', 
'/home/chris/src/poky-denzil/spark7162-build/tmp/work/sh4-poky-linux/stslave-0.7-r1/stslave-0.7.tar.gz', 
'', '', {}] comparing ['git', '.*', '/.*', '', '', {}] to ['http', 
'downloads.yoctoproject.org', '/mirror/sources/', '', '', {}]
| DEBUG: For url ['file', '', 
'/home/chris/src/poky-denzil/spark7162-build/tmp/work/sh4-poky-linux/stslave-0.7-r1/stslave-0.7.tar.gz', 
'', '', {}] comparing ['hg', '.*', '/.*', '', '', {}] to ['http', 
'downloads.yoctoproject.org', '/mirror/sources/', '', '', {}]
| DEBUG: For url ['file', '', 
'/home/chris/src/poky-denzil/spark7162-build/tmp/work/sh4-poky-linux/stslave-0.7-r1/stslave-0.7.tar.gz', 
'', '', {}] comparing ['osc', '.*', '/.*', '', '', {}] to ['http', 
'downloads.yoctoproject.org', '/mirror/sources/', '', '', {}]
| DEBUG: For url ['file', '', 
'/home/chris/src/poky-denzil/spark7162-build/tmp/work/sh4-poky-linux/stslave-0.7-r1/stslave-0.7.tar.gz', 
'', '', {}] comparing ['p4', '.*', '/.*', '', '', {}] to ['http', 
'downloads.yoctoproject.org', '/mirror/sources/', '', '', {}]
| DEBUG: For url ['file', '', 
'/home/chris/src/poky-denzil/spark7162-build/tmp/work/sh4-poky-linux/stslave-0.7-r1/stslave-0.7.tar.gz', 
'', '', {}] comparing ['svk', '.*', '/.*', '', '', {}] to ['http', 
'downloads.yoctoproject.org', '/mirror/sources/', '', '', {}]
| DEBUG: For url ['file', '', 
'/home/chris/src/poky-denzil/spark7162-build/tmp/work/sh4-poky-linux/stslave-0.7-r1/stslave-0.7.tar.gz', 
'', '', {}] comparing ['svn', '.*', '/.*', '', '', {}] to ['http', 
'downloads.yoctoproject.org', '/mirror/sources/', '', '', {}]

| DEBUG: Trying Upstream
| ERROR: Function failed: Fetcher failure for URL: 
'file:///home/chris/src/poky-denzil/spark7162-build/tmp/work/sh4-poky-linux/stslave-0.7-r1/stslave-0.7.tar.gz'. 
Unable to fetch URL from any source.


Yes of course I can just let fetcher2 extract all the files an 
afterwards apply the patches by hand. But I think there should be a 
more generic way to handle this. I hope I can get some hints how to 
solve this.





with kind regards,

Christian


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




--
~: https://github.com/project-magpie/meta-stlinux :~

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

[yocto] How to handle src.rpm packages

[Christian Ege]

Hello,

I am interested in how to handle source code inside of a src.rpm 
package. There had been a patch from Mark Hatle which handles the rpm 
packages inside the fetcher2. In his patch he suggests to handle Patches 
inside the rpm in the following way:



file://${WORKDIR}/mypatch.patch

When I tried this inside the SRC_URI declaration I always get en error 
like this:


NOTE: Running task 439 of 669 (ID: 4, 
/home/chris/src/poky-denzil/meta-stlinux/recipes-core/stslave/stslave_0.7.bb, 
do_fetch)

NOTE: package stslave-0.7-r1: task do_fetch: Started
ERROR: Function failed: Fetcher failure for URL: 
'file:///home/chris/src/poky-denzil/spark7162-build/tmp/work/sh4-poky-linux/stslave-0.7-r1/stslave-0.7.tar.gz'. 
Unable to fetch URL from any source.
ERROR: Logfile of failure stored in: 
/home/chris/src/poky-denzil/spark7162-build/tmp/work/sh4-poky-linux/stslave-0.7-r1/temp/log.do_fetch.25817

Log data follows:
| DEBUG: Trying PREMIRRORS
| DEBUG: For url ['file', '', 
'/home/chris/src/poky-denzil/spark7162-build/tmp/work/sh4-poky-linux/stslave-0.7-r1/stslave-0.7.tar.gz', 
'', '', {}] comparing ['bzr', '.*', '/.*', '', '', {}] to ['http', 
'downloads.yoctoproject.org', '/mirror/sources/', '', '', {}]
| DEBUG: For url ['file', '', 
'/home/chris/src/poky-denzil/spark7162-build/tmp/work/sh4-poky-linux/stslave-0.7-r1/stslave-0.7.tar.gz', 
'', '', {}] comparing ['cvs', '.*', '/.*', '', '', {}] to ['http', 
'downloads.yoctoproject.org', '/mirror/sources/', '', '', {}]
| DEBUG: For url ['file', '', 
'/home/chris/src/poky-denzil/spark7162-build/tmp/work/sh4-poky-linux/stslave-0.7-r1/stslave-0.7.tar.gz', 
'', '', {}] comparing ['git', '.*', '/.*', '', '', {}] to ['http', 
'downloads.yoctoproject.org', '/mirror/sources/', '', '', {}]
| DEBUG: For url ['file', '', 
'/home/chris/src/poky-denzil/spark7162-build/tmp/work/sh4-poky-linux/stslave-0.7-r1/stslave-0.7.tar.gz', 
'', '', {}] comparing ['hg', '.*', '/.*', '', '', {}] to ['http', 
'downloads.yoctoproject.org', '/mirror/sources/', '', '', {}]
| DEBUG: For url ['file', '', 
'/home/chris/src/poky-denzil/spark7162-build/tmp/work/sh4-poky-linux/stslave-0.7-r1/stslave-0.7.tar.gz', 
'', '', {}] comparing ['osc', '.*', '/.*', '', '', {}] to ['http', 
'downloads.yoctoproject.org', '/mirror/sources/', '', '', {}]
| DEBUG: For url ['file', '', 
'/home/chris/src/poky-denzil/spark7162-build/tmp/work/sh4-poky-linux/stslave-0.7-r1/stslave-0.7.tar.gz', 
'', '', {}] comparing ['p4', '.*', '/.*', '', '', {}] to ['http', 
'downloads.yoctoproject.org', '/mirror/sources/', '', '', {}]
| DEBUG: For url ['file', '', 
'/home/chris/src/poky-denzil/spark7162-build/tmp/work/sh4-poky-linux/stslave-0.7-r1/stslave-0.7.tar.gz', 
'', '', {}] comparing ['svk', '.*', '/.*', '', '', {}] to ['http', 
'downloads.yoctoproject.org', '/mirror/sources/', '', '', {}]
| DEBUG: For url ['file', '', 
'/home/chris/src/poky-denzil/spark7162-build/tmp/work/sh4-poky-linux/stslave-0.7-r1/stslave-0.7.tar.gz', 
'', '', {}] comparing ['svn', '.*', '/.*', '', '', {}] to ['http', 
'downloads.yoctoproject.org', '/mirror/sources/', '', '', {}]

| DEBUG: Trying Upstream
| ERROR: Function failed: Fetcher failure for URL: 
'file:///home/chris/src/poky-denzil/spark7162-build/tmp/work/sh4-poky-linux/stslave-0.7-r1/stslave-0.7.tar.gz'. 
Unable to fetch URL from any source.


Yes of course I can just let fetcher2 extract all the files an 
afterwards apply the patches by hand. But I think there should be a more 
generic way to handle this. I hope I can get some hints how to solve 
this.





with kind regards,

Christian


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