gmane.linux.embedded.yocto.general

Re: Cedartrail and Dylan?

Paul D. DeRocco — 2013-06-19T23:09:28

My first attempt to build cedartrail-nopvr finds that meta-intel has an
unmatched mesa_9.1.3.bbappend, but I suppose I can configure it to ignore
that since I'm not building graphics. However, meta-cedartrail contains an
unmatched linux-yocto_3.0.bbappend and linux-yocto-rt_3.0.bbappend. I don't
know how to fix that.

Minutes: Yocto Project Technical Team Meeting - Tuesday, June 18, 2013 8:00 AM-9:00 AM (UTC-08:00) Pacific Time (US & Canada).

Liu, Song — 2013-06-19T21:14:53

Attendees:
David Wolf, Cristiana, Nitin, Richard, Paul, TomZ, BjörnS, Kevin, Ross, MichaelH, MarkH, AlexG, Beth, Song

Agenda:

* Opens collection - 5 min (Song)
* Yocto 1.4.1 status (Paul)
  - It's still in QA. Eclipse plug in issue, error message in Bluetooth. Will know more.
  - RP: it's looking good so far.
  - Paul: Will send the feature/know issue list after QA report.
* Yocto 1.5 status - 10 min (Song/team)
  https://wiki.yoctoproject.org/wiki/Yocto_Project_v1.5_Status
  - Open bug: 299. Same as last week. Bug fixing last week: 12. WDD chart little changed from last week. Ask the team to put more effort into bug fixing. We still have a lot of bugs to fix. Let's bring the WDD number down.
  - 1.4.1 and weekly build: If 1.4.1 QA report is good. Let's start weekly build and testing
  - kernel is breaking on gcc 4.8. Bug #4549. Bruce on it.
  - Beth: M1, releasing this morning.

* SWAT team rotation: Andrei Dinu -> Cristiana Voicu
* Opens - 10 min
  - RP: being away. Mentioned in the email a little bit.

Trying to Integrate QNX's Neutrino 6.5.0 toolcain into OE/Yocto as a foreign (external) tool-chain

Glenn Schmottlach — 2013-06-19T21:05:00

The company I work for tends to do a fair amount of work in both Linux and
QNX. Primarily we use the Bitbake/OpenEmbedded/Yocto build framework to
build individual recipes (packages, e.g. libraries, apps, etc...) and
ultimately Linux BSP images for several HW platforms and CPUs. As I
understand it the OpenEmbedded framework supports external (binary)
tool-chains (e.g. like those provided with QNX's Linux host tools which are
gcc based) so my thoughts have been focused on integrating the QNX
tool-chain into the OpenEmbedded/Yocto framework. Ideally, with suitable
recipes and the layering system provided by the framework, it seems
plausible that I *should* be able to generate QNX
executables/libraries/images using this build framework on a Linux host.

Has anyone out there attempted this? Is this even feasible since OE/Yocto
tends to be so Linux focused. I suspect it could be a great option for
people (like myself) who must do development under both platforms and want
to create a common build/packaging process

Re: Qt build error for Debug and Release mode

Navani Srivastava — 2013-06-19T17:12:19

It Worked :)
Thanks


On Wed, Jun 19, 2013 at 2:11 AM, Khem Raj <raj.khem-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org> wrote:

Re: toolchain's environment-setup file that includes the image generated rootfs

Zhang, Jessica — 2013-06-19T16:26:14

Overall, we don't suggest user to copy and alter the environment-setup file manually.

From: yocto-bounces-EtnWKYl6rD/WsZ/bQMPhNw< at >public.gmane.org [mailto:yocto-bounces-EtnWKYl6rD/WsZ/bQMPhNw< at >public.gmane.org] On Behalf Of Thanassis Silis
Sent: Tuesday, June 18, 2013 7:19 AM
To: yocto-EtnWKYl6rD/WsZ/bQMPhNw< at >public.gmane.org
Subject: [yocto] toolchain's environment-setup file that includes the image generated rootfs

hello everyone,
tampering with eclipse I was advised to use the image generated rootfs for sysroot entry, under window->preferences->Yocto Project ADT. I also used the meta-toolchain, which is extracted under /opt/poky/

If I copy extract the same toolchain and sysroots to another pc, I should alter the environment-setup file.
Looking into this file some changes are obvious. Variables:

CC, CXX, CPP, LD should be appended with " --sysroot=/path/to/image-rootfs/", next to the already existing "--sysroot=/opt/poky/1.4.1/sysroots/armv7a-vfp-neon-poky-linux-gnueabi".

It is not clear if the above

Re: cannot bitbake/build.compile tcf-agent for use with fsl-image-gui-sdk

Zhang, Jessica — 2013-06-19T16:25:03

Hi Thanassis,



I don't know why tcf-agent  is not included in your sdk image.  But you also can use ssh to create a rse remote connection that allows you to do remote interaction.  When you create remote connection, instead of choosing tcf, use ssh.  You'll need openssh in your target image for this to work.



Cheers,

Jessica



From: yocto-bounces-EtnWKYl6rD/WsZ/bQMPhNw< at >public.gmane.org [mailto:yocto-bounces-EtnWKYl6rD/WsZ/bQMPhNw< at >public.gmane.org] On Behalf Of Thanassis Silis
Sent: Tuesday, June 18, 2013 6:56 AM
To: meta-freescale-EtnWKYl6rD/WsZ/bQMPhNw< at >public.gmane.org; yocto-EtnWKYl6rD/WsZ/bQMPhNw< at >public.gmane.org
Subject: [yocto] cannot bitbake/build.compile tcf-agent for use with fsl-image-gui-sdk



Hello everyone,
it seems tcf-agent is not provided. Not even in the -sdk image I created. And that is where my problems start:

using this in my local.conf: IMAGE_INSTALL_append = " tcf-agent"
I expected to be able to automate the process of generating the tcf-agent and deploying it in my image with co

Re: Yocto Layers not getting recognized by bitbake

varun bhatnagar — 2013-06-19T16:10:35

Thanks for the reply Gary. I am attaching recipe file below. Please have a
look at it. And yes, there is a line where in all the dependencies are
given.
And this is the link from where I created the layer :
http://cgit.openembedded.org/meta-openembedded/tree/

//
Varun


On Tue, Jun 18, 2013 at 10:11 PM, Gary Thomas <gary-kIKI1E8EpGZWk0Htik3J/w< at >public.gmane.org> wrote:

DESCRIPTION = "bitake file"
DEPENDS = "net-snmp fuse"
RDEPENDS = "curl rpm openssh openldap procps psmisc sed net-snmp-server"
LICENSE = "GPLv2+"
PR = "r0"
SRC_URI = "file:///home/user/Myapp.tar.gz"
EXTRA_OECMAKE += "-DCMAKE_FIND_ROOT_PATH=${STAGING_DIR_HOST} "
EXTRA_OECMAKE += "-DTARGET_ARCHITECTURE=${TARGET_ARCH} "
EXTRA_OECMAKE += "-DCMAKE_SYSTEM_NAME=Linux "
EXTRA_OECMAKE += "-DCMAKE_SYSTEM_VERSION=1 "
EXTRA_OECMAKE += "-DRSTATE=${PR} "
EXTRA_OECMAKE += "-DCMAKE_FIND_ROOT_PATH_MODE_PROGRAM=NEVER "
EXTRA_OECMAKE += "-DCMAKE_FIND_ROOT_PATH_MODE_LIBRARY=ONLY "
EXTRA_OECMAKE += "-DCMAKE_FIND_ROOT_PATH_MODE_INCLUDE=ONLY "
EXTRA_O

Re: Cross building question

Burton, Ross — 2013-06-19T15:32:59

You'll want to put those directories into FILES_$PN-dbg, as otherwise
they end up in PN and you rightly get warnings.

Ross

Re: Cross building question

Gary Thomas — 2013-06-19T15:25:36

Here's what I have:

   [gary< at >thor synology_poky]$ file tmp/work/ppce500v2-amltd-linux-gnuspe/amanda/3.3.3-r0/packages-split/amanda/usr/lib/amanda/libamar.so
   tmp/work/ppce500v2-amltd-linux-gnuspe/amanda/3.3.3-r0/packages-split/amanda/usr/lib/amanda/libamar.so: symbolic link to `libamar-3.3.3.so'
   [gary< at >thor synology_poky]$ file tmp/work/ppce500v2-amltd-linux-gnuspe/amanda/3.3.3-r0/packages-split/amanda/usr/lib/amanda/libamar-3.3.3.so
   tmp/work/ppce500v2-amltd-linux-gnuspe/amanda/3.3.3-r0/packages-split/amanda/usr/lib/amanda/libamar-3.3.3.so: ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 
(SYSV), dynamically linked, BuildID[sha1]=0xef5c0cd4d0ac1abfb9a29b05ca6189d5a1b745ae, stripped

Following your advice, I added these lines to my recipe:

   FILES_${PN} += "/usr/lib \
                   /usr/local \
   "
   INSANE_SKIP_${PN} += "dev-so"

Now I get errors like these (they might have been there before):
   ERROR: QA Issue: non debug package contains .debug directory: amanda path 
/work

Re: Cross building question

Burton, Ross — 2013-06-19T14:52:57

Is libamar actually a module, and not a library? (albeit done badly,
as it's a symlink)  If so, then INSANE_SKIP_${PN} += "dev-so" is the
right way to skip that test.  This may be a bug in amanda which
everyone else has been ignoring.


I've not actually used the SDK but they should be mostly the same,
yes.  Differences are bound to be of interest so please do report
them.

Ross

Re: Cross building question

Gary Thomas — 2013-06-19T14:39:54

Probably what I will do!

In the mean time, I faked that one and moved on and got the whole thing
to build :-)  Now I face this packaging issue:
   ERROR: QA Issue: non -dev/-dbg/-nativesdk package contains symlink .so: amanda path 
'/work/ppce500v2-amltd-linux-gnuspe/amanda/3.3.3-r0/packages-split/amanda/usr/lib/amanda/libamar.so'

Any clues how I fix this?

Query: I've built this now using a cross build (normal Yocto style) and
native using a Yocto created SDK.  These _should_ be the same tools, no?
I ask because I had a few gotchas - things that were different between
the two environments.  If I track them down, are they of any interest?

Re: Cross building question

Burton, Ross — 2013-06-19T14:14:19

You can use qemu, for example the fontconfig cache generation is done
at image construction time using qemu running the target binaries.
The alternative solution is to use the host compiler ($BUILD_CC etc)
and build the tool natively - either by patching the build system or
building it manually yourself before invoking make.

Of course, if this binary is just used to print some stuff for the
user, you could just patch it out. :)

Ross

Cross building question

Gary Thomas — 2013-06-19T14:03:17

I'm asking on this list since this is a pretty general question.
If it's more appropriate for another venue, just let me know.

I'm trying to build a new package for my target which has never
been ported to OpenEmbedded/Yocto/...  (It's the Amanda backup
server if anyone has ever looked at this).  The code is a
giant mass that I'd hoped not to have to delve into very deeply.
Basic configuration (autoolized) went well, but one of the
first things it wants to do is run a [target] program which
has been linked against the [target] libraries that were just
built.  In this case, it's just a utility to interrogate the
libraries and CONFIG.h files and print a user summary.

What's the best way to handle this and how?  I recall in the
dark old days that there were many such things that relied on
running QEMU to actually execute target code.  Is this still
possible (and being done)?  If so, is that a solution and how
might I force it to happen?

It may turn out that this is just a small problem that I can
patch my wa

Re: meta-selinux make ALLOW_EMPTY package specific

Philip Tricca — 2013-06-19T13:53:09

Ping.  Any interest in taking this (and the other patch I sent) into
meta-selinux?

Regards
- Philip

On 06/10/2013 08:54 PM, Philip Tricca wrote:

Fullpass Test Report for Yocto 1.4.1 RC1 20130612-5 Build

Georgescu, Alexandru C — 2013-06-19T13:29:07

Hello,

Here is the Fullpass report for the Yocto 1.4.1 RC1 build. No major (Medium+ or High) issues found. In the LSB-SDK images chmod: cannot access '/var/run/bind/run' 4744<https://bugzilla.yoctoproject.org/show_bug.cgi?id=4744>. X fails to start on liveboot for crownbay-noemgd 4742<https://bugzilla.yoctoproject.org/show_bug.cgi?id=4742>, and archiver.bbclass fails to filter package licenses (present in 1.5 as well) - 4630<https://bugzilla.yoctoproject.org/show_bug.cgi?id=4630>. All the bugs found in the test run can be found in the summary below or by accessing the detailed report: https://wiki.yoctoproject.org/wiki/Full_Pass_Test_Report_for_Yocto_1.4.1_RC1_20130612-5_build.

Testing data

 Test type: Fullpass Test

 Branch: master

 Milestone: 1.4.1 RC1

 Build name: Fullpass

 poky commit: 73f103bf9b2cdf985464dc53bf4f1cfd71d4531f

 poky commit date: Tue Jun 11 18:00:03 2013 +0100

 eclipse-poky: dc9a609c68fe4a6bbbf34d418fd6611489c1d6f7

 Eclipse Plugin commit: Wed Apr 17 20:01:23 2013 +0300

 Autobuild

Re: Toolchain... Issues with systemd (probably)

DAMARLA Satya Swaroop — 2013-06-19T13:11:08

Yes... I thought the same and so, I made two build directories , one for
sysvinit and the other for systemd and the errors I get abosulte no error
when I try to *populate_sdk* under sysvinit but I get the following errors
when I run the same under systemd.

*| The following packages have unmet dependencies:*
*|  udev-dev : Depends: udev (= 182-r7) but 1:204-r0 is to be installed*
*|             Recommends: libusb-dev but it is not installable*
*|             Recommends: module-init-tools-dev but it is not installable*
*|             Recommends: libkmod-dev but it is not installable*
*| E: Unable to correct problems, you have held broken packages.*
*| DEBUG: Python function do_populate_sdk finished*
*| ERROR: Function failed: populate_sdk_image (log file is located at
/home/damarla/openYocto/poky/buildSmartCPUsystemd/tmp/work/smartcpu-poky-linux-gnueabi/rootfs-smartcpu-sdk/1.0-r0/temp/log.do_populate_sdk.17015)
*
*ERROR: Task 10
(/home/damarla/openYocto/poky/meta-skidata/recipes-smartcpu/images/
rootfs-smartc

core-image-x11 works on QEMU and not on real hardware

Alex M — 2013-06-19T12:33:42

Hello!
I'm using poky-dylan-9.0.0.tar.bz2

I just built core-image-x11 and able to run it on qemux86, but all my
attempts to run image on real hardware with nVidia GTX465 or AMD
HD6320 - failed. In X11 logs I see errors about GLX module.

What I should do to add GLX and OpenGL 2.1 3D acceleration with Mesa
and opensource drivers for nVidia, Intel and AMD cards at the same
time?

P.S.
Strange, I expected to see working graphics with plain software VGA
driver not only with QEMU but on all hardware... BTW, when starting
Yocto I see graphic logo and progress bar.

Re: Toolchain... Issues with systemd (probably)

Burton, Ross — 2013-06-19T12:11:22

It really helps when you tell us what the errors are.

Note that changing DISTRO_FEATURES in an existing build directory
isn't supported and may well cause problems.

Ross

Toolchain... Issues with systemd (probably)

DAMARLA Satya Swaroop — 2013-06-19T12:08:26

I think I had to open the issue as its not closed... Here is more
clarity....

The issue is I decided the problem may be with init_manager. I did two
builds one with sysvinit using traditional Poky distro and other one is
uisng systemd using new distribution which is different as we need a new
distribution for using systemd

.. I didno t get any errors when i build using *bitbake -c populate_sdk
rootfs-smartcpu* with sysvinit and got build errors using systemd...

Any possible resons what could have caused failure to build the toolchain?

Cheers,
Satya

[PATCH] ecryptfs-utils: create symlinks for mount file inexpected path

Noor, Ahsan — 2013-06-19T10:54:16

From: Noor <noor_ahsan-nmGgyN9QBj3QT0dZR+AlfA< at >public.gmane.org>

* mounting ecryptfs drive was failing because it was looking for mount.ecryptfs
  binary in /sbin/ however in our file-system, it was present in /usr/sbin/. So,
  create symlinks of required binaries in /sbin/ as well

Signed-off-by: Noor Ahsan <noor_ahsan-nmGgyN9QBj3QT0dZR+AlfA< at >public.gmane.org>
---
 .../ecryptfs-utils/ecryptfs-utils_100.bb           |    4 ++++
 1 file changed, 4 insertions(+)

diff --git a/recipes-support-ivi/ecryptfs-utils/ecryptfs-utils_100.bb b/recipes-support-ivi/ecryptfs-utils/ecryptfs-utils_100.bb
index e23f32c..c05cd84 100644
--- a/recipes-support-ivi/ecryptfs-utils/ecryptfs-utils_100.bb
+++ b/recipes-support-ivi/ecryptfs-utils/ecryptfs-utils_100.bb
< at >< at > -40,4 +40,8 < at >< at > do_install_append() {
         install -d ${D}${systemd_unitdir}/system/
         install -m 0644 ${WORKDIR}/ecryptfs.service ${D}${systemd_unitdir}/system
     fi
+
+    install -d ${D}${base_sbindir}
+    ln -sf ${sbindir}/mount.ecryptfs ${D}${base_sbin

[PATCH] ecryptfs-utils: Modify systemd service file to'simple'.

Noor, Ahsan — 2013-06-19T10:53:31

From: Noor <noor_ahsan-nmGgyN9QBj3QT0dZR+AlfA< at >public.gmane.org>

Signed-off-by: Mikhail Durnev <mikhail_durnev-nmGgyN9QBj3QT0dZR+AlfA< at >public.gmane.org>
Signed-off-by: Noor Ahsan <noor_ahsan-nmGgyN9QBj3QT0dZR+AlfA< at >public.gmane.org>
---
 .../ecryptfs-utils/ecryptfs-utils/ecryptfs.service |    4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/recipes-support-ivi/ecryptfs-utils/ecryptfs-utils/ecryptfs.service b/recipes-support-ivi/ecryptfs-utils/ecryptfs-utils/ecryptfs.service
index ba12aa3..52f3397 100644
--- a/recipes-support-ivi/ecryptfs-utils/ecryptfs-utils/ecryptfs.service
+++ b/recipes-support-ivi/ecryptfs-utils/ecryptfs-utils/ecryptfs.service
< at >< at > -3,9 +3,7 < at >< at > Description=A userspace daemon that runs as the user perform file operations und
 After=udev.service
 
 [Service]
-Type=oneshot
-ExecStart=/usr/bin/ecryptfsd
-RemainAfterExit=yes
+ExecStart=/usr/bin/ecryptfsd -f
 
 [Install]
 WantedBy=multi-user.target