Re: [yocto] yocto eclipse ADT for mars

[Esponde, Joel]

Hi,



On my side, I had to add the luna site as a first step before being able to 
install ADT with Eclipse Mars:

Luna - http://download.eclipse.org/releases/luna

ADT plugin is dependent of a version of plugin that is only available in 
Eclipse Luna.

Once the site added, Eclipse should automatically manage dependencies and 
install the components needed by ADT.



Joël Esponde

Honeywell | Sensing and Productivity Solutions



> -Message d'origine-

> De : yocto-boun...@yoctoproject.org [mailto:yocto-

> boun...@yoctoproject.org] De la part de Shaun Savage

> Envoyé : mardi 7 juin 2016 02:03

> À : yocto@yoctoproject.org

> Objet : [yocto] yocto eclipse ADT for mars

>

> Hi all

>

> I am trying to get eclipse working with eclipse mars.2 release 4.5.2.  I have

> patched yocto to build on Ubuntu 16.04. Now I am trying to install yocto ADT

> on eclipse.  The problem is rse.terminal has been deprecated.

> Now there is local-shell, telnet and ssh.

> I have tried to build adt from the mars-master branch, but the

> rse.internal.terminal is still there.

>

> What can I do?

>

> shaun

>

> --

> ___

> 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] 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] Per image customizations

[Paul Eggleton]

On Tue, 07 Jun 2016 00:10:58 Oleksandr Poznyak wrote:
> Unfortunately You can't have two *.bbappend files per one package (recipe).

Let's clarify that for the benefit of others reading along - you absolutely 
*can* have multiple bbappends per recipe. To answer the original question 
though, no you cannot have bbappends conditionally applied based on what image 
is being built - you cannot have other recipes built differently based on the 
image being built *period*. Other than what gets shared via the sysroot, 
recipes are largely independent of eachother, and that's by design.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Per image customizations

[Oleksandr Poznyak]

Thanks, Paul. You are absolutely correct.

On Tue, Jun 7, 2016 at 1:20 PM, Paul Eggleton  wrote:

> On Tue, 07 Jun 2016 00:10:58 Oleksandr Poznyak wrote:
> > Unfortunately You can't have two *.bbappend files per one package
> (recipe).
>
> Let's clarify that for the benefit of others reading along - you absolutely
> *can* have multiple bbappends per recipe. To answer the original question
> though, no you cannot have bbappends conditionally applied based on what
> image
> is being built - you cannot have other recipes built differently based on
> the
> image being built *period*. Other than what gets shared via the sysroot,
> recipes are largely independent of eachother, and that's by design.
>
> Cheers,
> Paul
>
> --
>
> Paul Eggleton
> Intel Open Source Technology Centre
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] DISTRO_FEATURES modification from image recipe?

[piotr.lewicki]

Hi,
Is it possible to manipulate DISTRO_FEATURES from my image recipe file?

In my case I added line:
DISTRO_FEATURES += " systemd"

to local.conf and it worked (added systemd), but when I moved this line 
to my image.bb recipe I got build errors:


ERROR: Required build target 'my-image' has no buildable providers.
Missing or unbuildable dependency chain was: ['my-image', 'my-app', 
'systemd']


I already have in my image recipe line:
DISTRO_FEATURES_append = " gles2"
so I tried to add systemd to it like so:
DISTRO_FEATURES_append = " gles2 systemd"
but it didn't help.

Can you help a me?
What should I put and where to enable distro-feature: systemd without 
manipulating with local.conf? Is that possible?



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

Re: [yocto] DISTRO_FEATURES modification from image recipe?

[Burton, Ross]

On 7 June 2016 at 13:10, piotr.lewicki  wrote:

> Is it possible to manipulate DISTRO_FEATURES from my image recipe file?
>

No.  You should control distro features in your distro configuration or if
they're for local tweaking in your local.conf.  Would it be helpful if you
explained why you want to enable systemd in some images but not others?  In
this case the systemd feature isn't exclusive with sysvinit, you can enable
both and pick on a per-image basis what init system is used.

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

[yocto] [meta-raspberrypi][PATCH] omxplayer: fix compilation with GCC 6

[Jonathan Liu]

Specifying -isystem${STAGING_DIR_HOST}/usr/include in INCLUDES gives:

In file included from utils/PCMRemap.cpp:26:0:
.../build/tmp/sysroots/raspberrypi2/usr/include/c++/6.1.1/cstdlib:75:25: 
fatal error: stdlib.h: No such file or directory
 #include_next 
 ^
compilation terminated.
Makefile:44: recipe for target 'utils/PCMRemap.o' failed

To resolve this, /usr/include shouldn't be specified as it is already a
default include path relative to the sysroot.

See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70129.

Signed-off-by: Jonathan Liu 
---
 recipes-multimedia/omxplayer/omxplayer_git.bb | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/recipes-multimedia/omxplayer/omxplayer_git.bb 
b/recipes-multimedia/omxplayer/omxplayer_git.bb
index 7d3b464..d9460de 100644
--- a/recipes-multimedia/omxplayer/omxplayer_git.bb
+++ b/recipes-multimedia/omxplayer/omxplayer_git.bb
@@ -40,8 +40,7 @@ export LDFLAGS = "-L${S}/ffmpeg_compiled/usr/lib \
   -L${STAGING_DIR_HOST}/lib \
   -L${STAGING_DIR_HOST}/usr/lib \
  "
-export INCLUDES = "-isystem${STAGING_DIR_HOST}/usr/include \
-   
-isystem${STAGING_DIR_HOST}/usr/include/interface/vcos/pthreads \
+export INCLUDES = 
"-isystem${STAGING_DIR_HOST}/usr/include/interface/vcos/pthreads \
-isystem${STAGING_DIR_HOST}/usr/include/freetype2 \

-isystem${STAGING_DIR_HOST}/usr/include/interface/vmcs_host/linux \
-isystem${STAGING_DIR_HOST}/usr/include/dbus-1.0 \
-- 
2.8.3

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

[yocto] Minutes: Yocto Project Technical Team Meeting - Tuesday, June 7, 2016 8:00 AM US Pacific Time

[Jolley, Stephen K]

Attendees: Stephen, Joshua, Bill, Sona, Randy, Ross, Michael,



Agenda:

* Opens collection - 5 min (Stephen)

* Yocto Project status - 5 min (Stephen/team)

*YP 1.8.2 was released 2 weeks ago.

*YP 2.0.2 was released last week.

*YP 2.2 M1 cut off is next Monday.   We have a test build in QA to 
insure all the Python 3 upgrade changes go OK.

https://wiki.yoctoproject.org/wiki/Yocto_Project_v2.2_Status

https://wiki.yoctoproject.org/wiki/Yocto_2.2_Schedule

https://wiki.yoctoproject.org/wiki/Yocto_2.2_Features

* Opens - 10 min

*Discussed the issues we have seen with the Python 3 upgrade.

*Smart package manger changes will most likely push past M1.  Analysis 
is still in process.

*Discussed enhancement 7515 - It is now targeted for M2.

* Team Sharing - 10 min




Thanks,

Stephen K. Jolley
Yocto Project Program Manager
INTEL, MS JF1-255, 2111 N.E. 25th Avenue, Hillsboro, OR 97124
*   Work Telephone:  (503) 712-0534
*Cell:   (208) 244-4460
* Email: stephen.k.jol...@intel.com
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Per image customizations

[Edward Wingate]

On Tue, Jun 7, 2016 at 3:20 AM, Paul Eggleton
 wrote:
> Let's clarify that for the benefit of others reading along - you absolutely
> *can* have multiple bbappends per recipe. To answer the original question
> though, no you cannot have bbappends conditionally applied based on what image
> is being built - you cannot have other recipes built differently based on the
> image being built *period*. Other than what gets shared via the sysroot,
> recipes are largely independent of eachother, and that's by design.

Thank you, I will abandon that line of inquiry.

So I now have recipes that attempt to overwrite inittab with their own
custom version.  These individual recipes are included in different
images and have DEPENDS += " sysvinit-inittab" in them.  However, the
resulting image still has the original inittab from sysvinit-inittab
recipe, not the custom inittab in my new recipes.

My recipes look like this now:

LICENSE = "BSD"
LIC_FILES_CHKSUM = "file://LICENSE;md5=9bea9267288f79f074b2e000d3cf6412"
SRC_URI = "file://LICENSE file://inittab-imageX"
S = "${WORKDIR}"
DEPENDS += " sysvinit-inittab"

FILES_${PN} = "/etc/inittab"

do_install () {
install -d ${D}${sysconfdir}
install -m 0644 -D ${S}/inittab-imageX ${D}${sysconfdir}/inittab
}

Is there something more I'm missing?  Thanks.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] What's this

[Burton, Ross]

On 5 June 2016 at 17:44, Gary Thomas  wrote:

> I just updated my Poky repo and did a rebuild and saw this "error"
> (although it carried on with the build):
> ERROR: base-files-3.0.14-r89 do_install: Taskhash mismatch
> ceb25febc6f11a5cc2b3c4a4b0b2c136 verses 44f498452dfce5875451bca66b230e31
> for
> /local/poky-cutting-edge/meta/recipes-core/base-files/base-files_3.0.14.bb.do_install
> ERROR: Taskhash mismatch ceb25febc6f11a5cc2b3c4a4b0b2c136 verses
> 44f498452dfce5875451bca66b230e31 for
> /local/poky-cutting-edge/meta/recipes-core/base-files/base-files_3.0.14.bb.do_install
>
> What does this mean?  Should I be worried?
>

It means the hash calculated my the bitbake master was different to the
hash calculated when the worker started up.  This usually means that you're
using something like ${TIME} in the recipe but not marking it appropriatly
so the cache ignores it.  Do you have a base-files bbappend that writes a
timestamp?

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

Re: [yocto] What's this

[Burton, Ross]

On 7 June 2016 at 17:02, Burton, Ross  wrote:

> It means the hash calculated my the bitbake master was different to the
> hash calculated when the worker started up.  This usually means that you're
> using something like ${TIME} in the recipe but not marking it appropriatly
> so the cache ignores it.  Do you have a base-files bbappend that writes a
> timestamp?
>

The always wise Joshua reminds me that if your DISTRO_VERSION contains
${DATETIME} then this happens.  If you're doing this then you'll want to
set [vardepsexclude] on DISTRO_VERSION to stop the DATETIME from getting
into the cache (or not put the current date/time into the distro version).

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

Re: [yocto] What's this

[Gary Thomas]

On 2016-06-07 18:02, Burton, Ross wrote:


On 5 June 2016 at 17:44, Gary Thomas mailto:g...@mlbassoc.com>> wrote:

I just updated my Poky repo and did a rebuild and saw this "error"
(although it carried on with the build):
ERROR: base-files-3.0.14-r89 do_install: Taskhash mismatch 
ceb25febc6f11a5cc2b3c4a4b0b2c136 verses
44f498452dfce5875451bca66b230e31 for

/local/poky-cutting-edge/meta/recipes-core/base-files/base-files_3.0.14.bb.do_install
ERROR: Taskhash mismatch ceb25febc6f11a5cc2b3c4a4b0b2c136 verses 
44f498452dfce5875451bca66b230e31 for

/local/poky-cutting-edge/meta/recipes-core/base-files/base-files_3.0.14.bb.do_install

What does this mean?  Should I be worried?


It means the hash calculated my the bitbake master was different to the hash 
calculated when the worker started up.
This usually means that you're using something like ${TIME} in the recipe but 
not marking it appropriatly so the cache
ignores it.  Do you have a base-files bbappend that writes a timestamp?


Sorry, nothing like that in my layers.  Note: this only happened once,
immediately after a poky pull and the builds have been happy since.
Whatever it was only happened that one time (not that that should be
any less concerning...)

--

Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

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

Re: [yocto] What's this

[Gary Thomas]

On 2016-06-07 18:20, Burton, Ross wrote:


On 7 June 2016 at 17:02, Burton, Ross mailto:ross.bur...@intel.com>> wrote:

It means the hash calculated my the bitbake master was different to the 
hash calculated when the worker started up.
This usually means that you're using something like ${TIME} in the recipe 
but not marking it appropriatly so the
cache ignores it.  Do you have a base-files bbappend that writes a 
timestamp?


The always wise Joshua reminds me that if your DISTRO_VERSION contains 
${DATETIME} then this happens.  If you're doing
this then you'll want to set [vardepsexclude] on DISTRO_VERSION to stop the 
DATETIME from getting into the cache (or not
put the current date/time into the distro version).



Ah, that's probably it.  Exactly how do I set that exclusion?

--

Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

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

[yocto] [PULL] fixes in Dependency Explorer

[Woronicz, Bartosz ( NSN - PL/Wroclaw)]

--
Kind regards,
Bartosz Woronicz
Engineer, Software Configuration (SCM)
Nokia Networks - PL/Wroclaw

>From 11f4a3e137e2eda76c8dce44c053d0db68d6b208 Mon Sep 17 00:00:00 2001
From: Bartosz Wieslaw Woronicz 
Date: Tue, 7 Jun 2016 17:08:16 +0200
Subject: [PATCH 1/2] depexp: remove the requirement for -g flag

---
 bitbake/lib/bb/ui/depexp.py | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/bitbake/lib/bb/ui/depexp.py b/bitbake/lib/bb/ui/depexp.py
index 240aafc..6a6bfd5 100644
--- a/bitbake/lib/bb/ui/depexp.py
+++ b/bitbake/lib/bb/ui/depexp.py
@@ -202,9 +202,6 @@ def main(server, eventHandler, params):
 print(cmdline['msg'])
 return 1
 cmdline = cmdline['action']
-if not cmdline or cmdline[0] != "generateDotGraph":
-print("This UI requires the -g option")
-return 1
 ret, error = server.runCommand(["generateDepTreeEvent", cmdline[1], cmdline[2]])
 if error:
 print("Error running command '%s': %s" % (cmdline, error))
-- 
2.5.0

>From 12215390bb16980c6aae5039c7cc6f6eceb1fa4e Mon Sep 17 00:00:00 2001
From: Bartosz Wieslaw Woronicz 
Date: Tue, 7 Jun 2016 17:09:16 +0200
Subject: [PATCH 2/2] depexp: fix progress bar

---
 bitbake/lib/bb/ui/depexp.py | 14 --
 1 file changed, 12 insertions(+), 2 deletions(-)

diff --git a/bitbake/lib/bb/ui/depexp.py b/bitbake/lib/bb/ui/depexp.py
index 6a6bfd5..0778f9d 100644
--- a/bitbake/lib/bb/ui/depexp.py
+++ b/bitbake/lib/bb/ui/depexp.py
@@ -264,7 +264,6 @@ def main(server, eventHandler, params):
 continue
 
 if isinstance(event, bb.event.CacheLoadCompleted):
-bardialog.hide()
 continue
 
 if isinstance(event, bb.event.ParseStarted):
@@ -277,6 +276,17 @@ def main(server, eventHandler, params):
 
 gtk.gdk.threads_leave()
 
+if isinstance(event, bb.event.TreeDataPreparationStarted):
+bardialog.set_title("Processing tree data")
+bardialog.vbox.remove(pbar)
+bardialog.vbox.pack_start(
+gtk.Label(str="Generating dependency graph data... please wait..."))
+bardialog.show_all()
+continue
+
+if isinstance(event, bb.event.TreeDataPreparationProgress):
+continue
+
 if isinstance(event, bb.event.ParseProgress):
 x = event.current
 gtk.gdk.threads_enter()
@@ -286,13 +296,13 @@ def main(server, eventHandler, params):
 continue
 
 if isinstance(event, bb.event.ParseCompleted):
-bardialog.hide()
 continue
 
 if isinstance(event, bb.event.DepTreeGenerated):
 gtk.gdk.threads_enter()
 dep.parse(event._depgraph)
 gtk.gdk.threads_leave()
+bardialog.hide()
 
 if isinstance(event, bb.command.CommandCompleted):
 continue
-- 
2.5.0

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

Re: [yocto] Per image customizations

[Paul Eggleton]

On Tue, 07 Jun 2016 08:57:24 Edward Wingate wrote:
> On Tue, Jun 7, 2016 at 3:20 AM, Paul Eggleton
> 
>  wrote:
> > Let's clarify that for the benefit of others reading along - you
> > absolutely
> > *can* have multiple bbappends per recipe. To answer the original question
> > though, no you cannot have bbappends conditionally applied based on what
> > image is being built - you cannot have other recipes built differently
> > based on the image being built *period*. Other than what gets shared via
> > the sysroot, recipes are largely independent of eachother, and that's by
> > design.
>
> Thank you, I will abandon that line of inquiry.
> 
> So I now have recipes that attempt to overwrite inittab with their own
> custom version.  These individual recipes are included in different
> images and have DEPENDS += " sysvinit-inittab" in them.  However, the
> resulting image still has the original inittab from sysvinit-inittab
> recipe, not the custom inittab in my new recipes.
> 
> My recipes look like this now:
> 
> LICENSE = "BSD"
> LIC_FILES_CHKSUM = "file://LICENSE;md5=9bea9267288f79f074b2e000d3cf6412"
> SRC_URI = "file://LICENSE file://inittab-imageX"
> S = "${WORKDIR}"
> DEPENDS += " sysvinit-inittab"
> 
> FILES_${PN} = "/etc/inittab"
> 
> do_install () {
> install -d ${D}${sysconfdir}
> install -m 0644 -D ${S}/inittab-imageX ${D}${sysconfdir}/inittab
> }
> 
> Is there something more I'm missing?  Thanks.

So what this will give you is alternative packages to be installed instead of 
sysvinit-inittab in your image. Have you verified (by way of the image 
manifest written next to the image file) that this package is actually being 
installed? What steps have you taken to ensure that it does get installed in 
preference to sysvinit-inittab?

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] What's this

[Paul Eggleton]

On Tue, 07 Jun 2016 17:20:12 Burton, Ross wrote:
> On 7 June 2016 at 17:02, Burton, Ross  wrote:
> > It means the hash calculated my the bitbake master was different to the
> > hash calculated when the worker started up.  This usually means that
> > you're
> > using something like ${TIME} in the recipe but not marking it appropriatly
> > so the cache ignores it.  Do you have a base-files bbappend that writes a
> > timestamp?
> 
> The always wise Joshua reminds me that if your DISTRO_VERSION contains
> ${DATETIME} then this happens.  If you're doing this then you'll want to
> set [vardepsexclude] on DISTRO_VERSION to stop the DATETIME from getting
> into the cache (or not put the current date/time into the distro version).

I think we need to handle this situation better - if it's really worth 
producing an error about then it's worth producing an error message that 
people can actually understand, particularly as it's recently added 
validation.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] What's this

[Joshua G Lock]

On Tue, 2016-06-07 at 18:58 +0200, Gary Thomas wrote:
> On 2016-06-07 18:20, Burton, Ross wrote:
> > 
> > On 7 June 2016 at 17:02, Burton, Ross  > > wrote:
> > 
> > It means the hash calculated my the bitbake master was
> > different to the hash calculated when the worker started up.
> > This usually means that you're using something like ${TIME} in
> > the recipe but not marking it appropriatly so the
> > cache ignores it.  Do you have a base-files bbappend that
> > writes a timestamp?
> > 
> > 
> > The always wise Joshua reminds me that if your DISTRO_VERSION
> > contains ${DATETIME} then this happens.  If you're doing
> > this then you'll want to set [vardepsexclude] on DISTRO_VERSION to
> > stop the DATETIME from getting into the cache (or not
> > put the current date/time into the distro version).
> > 
> 
> Ah, that's probably it.  Exactly how do I set that exclusion?

Assuming DISTRO_VERSION includes DATETIME

    DISTRO_VERSION[vardepsexclude] = "DATETIME"

see for example:

http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta-poky/conf/dist
ro/poky.conf#n14

Regards,

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

[yocto] Secure remote access

[Juan Carlos Trujillo]

Has anyone used successfully any secure remote access utility (like Weaved
for RPi) on Yocto?
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] What's this

[Richard Purdie]

On Wed, 2016-06-08 at 09:24 +1200, Paul Eggleton wrote:
> On Tue, 07 Jun 2016 17:20:12 Burton, Ross wrote:
> > On 7 June 2016 at 17:02, Burton, Ross 
> > wrote:
> > > It means the hash calculated my the bitbake master was different
> > > to the
> > > hash calculated when the worker started up.  This usually means
> > > that
> > > you're
> > > using something like ${TIME} in the recipe but not marking it
> > > appropriatly
> > > so the cache ignores it.  Do you have a base-files bbappend that
> > > writes a
> > > timestamp?
> > 
> > The always wise Joshua reminds me that if your DISTRO_VERSION
> > contains
> > ${DATETIME} then this happens.  If you're doing this then you'll
> > want to
> > set [vardepsexclude] on DISTRO_VERSION to stop the DATETIME from
> > getting
> > into the cache (or not put the current date/time into the distro
> > version).
> 
> I think we need to handle this situation better - if it's really
> worth 
> producing an error about then it's worth producing an error message
> that 
> people can actually understand, particularly as it's recently added 
> validation.

It was silently running into problems due to this all along but not
reporting it. Its now reporting it which is better than silently things
behaving strangely.

Its very hard for bitbake to know why the hashes differ, it only knows
the values afterwards and hence that they've changed, the information
about how that hash was constructed is not present in any of bitbake's
caches. That implies to have better messages we need to write out more
data.

I did add a patch to make bitbake write out data to allow
reconstruction of basehash (which is part of taskhash). Sadly the
parsing performance was diabolical (10 times slower). I think that
could perhaps be improved if the files don't require an atomic move
during creation but I haven't had time to look further at it.

So whilst I do agree, what is the price people are willing to pay to
have those better messages?

Cheers,

Richard




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

Re: [yocto] Per image customizations

[Edward Wingate]

On Tue, Jun 7, 2016 at 1:47 PM, Paul Eggleton
 wrote:
>
> So what this will give you is alternative packages to be installed instead of
> sysvinit-inittab in your image.

I was under the (mistaken) impression that my recipe will run in
addition to, not instead of, sysvinit-inittab (occurring after it and
overwriting its inittab with my custom version).

> Have you verified (by way of the image manifest written next to the image 
> file) that this package
> is actually being installed?

The manifest shows both sysvinit-inittab and my package being
installed in the image, but sysvinit-inittab's inittab apparently
takes precedence over mine.

> What steps have you taken to ensure that it does get installed in preference 
> to sysvinit-inittab?

None, due to my mistaken impression.  After investigating your kind
inference with help of Yocto manual, I replaced in my recipe:
DEPENDS += " sysvinit-inittab"
with:
RREPLACES_${PN} = "sysvinit-inittab"

and it appears to be working now.  I've been using Yocto for a year
now, but still feel like I'm barely scratching the surface of it.  I
tend to get things to work by floundering about, so even though it
does works, I would appreciate knowing if this was the most proper
course of action.  Thanks!
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Per image customizations

[Paul Eggleton]

On Tue, 07 Jun 2016 16:07:26 Edward Wingate wrote:
> On Tue, Jun 7, 2016 at 1:47 PM, Paul Eggleton
>  wrote:
> > So what this will give you is alternative packages to be installed instead
> > of sysvinit-inittab in your image.
> 
> I was under the (mistaken) impression that my recipe will run in
> addition to, not instead of, sysvinit-inittab (occurring after it and
> overwriting its inittab with my custom version).

The recipe will build in addition to sysvinit-inittab yes, but do_install for 
that recipe is just assembling the files ready for packaging - it doesn't 
directly install files into the image. When it comes time to assemble the 
image, all that is being done when you distil it down is that we install a 
bunch of packages.

> > Have you verified (by way of the image manifest written next to the image
> > file) that this package is actually being installed?
> 
> The manifest shows both sysvinit-inittab and my package being
> installed in the image, but sysvinit-inittab's inittab apparently
> takes precedence over mine.

Hmm, that is strange, because as they install the same file they ought to 
conflict. Perhaps as suggested elsewhere in this thread this is a bug (or at 
least undesirable behaviour) in rpm.

> > What steps have you taken to ensure that it does get installed in
> > preference to sysvinit-inittab?
>
> None, due to my mistaken impression.  After investigating your kind
> inference with help of Yocto manual, I replaced in my recipe:
> DEPENDS += " sysvinit-inittab"
> with:
> RREPLACES_${PN} = "sysvinit-inittab"
> 
> and it appears to be working now.  I've been using Yocto for a year
> now, but still feel like I'm barely scratching the surface of it.  I
> tend to get things to work by floundering about, so even though it
> does works, I would appreciate knowing if this was the most proper
> course of action.  Thanks!

I guess here you are getting into functionality that is not very well-defined, 
and you're also dealing with behaviour of the package manager rather than the 
build system itself (though I appreciate the lines are blurred from usage 
perspective). I guess it would help though if we would document a working 
procedure to do this kind of thing as it does come up from time to time.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] New warning

[Gary Thomas]

I'm seeing a lot of these:
  NOTE: /local/poky-cutting-edge/meta-xyz/.../some-pkg_2.38.0.bb: base_contains is deprecated, please use 
bb.utils.contains instead.


This is all well and good and I'll clean them up as I go.  That
said, why is the same NOTE printed [at least] twice for every recipe
even when the file contains 'base_contains' only once?

--

Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

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

Re: [yocto] New warning

[Christopher Larson]

On Tue, Jun 7, 2016 at 7:55 PM, Gary Thomas  wrote:

> I'm seeing a lot of these:
>   NOTE: /local/poky-cutting-edge/meta-xyz/.../some-pkg_2.38.0.bb:
> base_contains is deprecated, please use bb.utils.contains instead.
>
> This is all well and good and I'll clean them up as I go.  That
> said, why is the same NOTE printed [at least] twice for every recipe
> even when the file contains 'base_contains' only once?
>

I haven't checked the code, but the most likely explanation is the error is
a parse or expansion time one, and bitbake parses the recipe anew when
running each task, after the up front parse which is used to generate the
runqueue. *shrug*. It's a downside of showing messages in anything but task
execution context.
-- 
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto