date:20170922

[yocto] Fwd: do_configure error

2017-09-22 Thread mohammed aqdam

-- Forwarded message --
From: "mohammed aqdam" 
Date: Sep 21, 2017 6:59 PM
Subject: do_configure error
To: "yocto" 
Cc:

Hi all,
i was trying to build rpi-test-image for my rpi3.

i'm getting the following error...

root@pcz-ee207837-2:/u/my_poky/poky-2/poky/build# bitbake -k rpi-test-image
Loading cache: 100%
|###
##|
Time: 0:00:01
Loaded 3160 entries from dependency cache.
NOTE: Resolving any missing task queue dependencies

Build Configuration:
BB_VERSION= "1.34.0"
BUILD_SYS = "x86_64-linux"
NATIVELSBSTRING   = "universal-4.8"
TARGET_SYS= "arm-poky-linux-gnueabi"
MACHINE   = "raspberrypi3"
DISTRO= "poky"
DISTRO_VERSION= "2.3.1"
TUNE_FEATURES = "arm armv7ve vfp thumb neon vfpv4
callconvention-hard cortexa7"
TARGET_FPU= "hard"
meta
meta-poky
meta-yocto-bsp= "pyro:4a39979c8d1e560fa54240e99734a651dfbaa63a"
meta-raspberrypi  = "pyro:8ba2d6fc80b31c87d25c87c863e2a77752b07c3c"
meta-qt5  = "pyro:c6aa602d0640040b470ee81de39726276ddc0ea3"
meta-qt5-extra= "master:05d63591612623ce7751f5536690c40998188ad2"
meta-oe
meta-networking
meta-python
meta-multimedia   = "pyro:5e82995148a2844c6f483ae5ddd1438d87ea9fb7"

Initialising tasks: 100%
|###
#|
Time: 0:00:11
NOTE: Executing SetScene Tasks
NOTE: Executing RunQueue Tasks
 configure: error: you should not run configure as root (set
FORCE_UNSAFE_CONFIGURE=1 in environment to bypass this check)
| See `config.log' for more details
| ERROR: Function failed: do_configure (log file is located at
/u/my_poky/poky-2/poky/build/tmp/work/x86_64-linux/
coreutils-native/8.26-r0/temp/log.do_configure.17147)
ERROR: Task (virtual:native:/u/my_poky/poky-2/poky/meta/recipes-core/
coreutils/coreutils_8.26.bb:do_configure)
failed with exit code '1'
NOTE: Tasks Summary: Attempted 4168 tasks of which 4167 didn't need to
be rerun and 1 failed.

Summary: 1 task failed:
  virtual:native:/u/my_poky/poky-2/poky/meta/recipes-core/
coreutils/coreutils_8.26.bb:do_configure
Summary: There were 2 ERROR messages shown, returning a non-zero exit code.

i checked for same branch while cloning the data, except for the
qt5-extra layer all are pyro.

what is that i'm missing?
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] libgcrypt building fails for armv6 binaries.

2017-09-22 Thread akuster



On 09/22/2017 09:15 PM, Yusuke Mitsuki wrote:
> Hello yocto
>
> libgcrypt has problem that build for armv6.
> bitbake said error messages at do_compile as follows:
> ...(snip)...
> | ../../libgcrypt-1.8.0/cipher/rijndael-armv8-aarch32-ce.S: Assembler 
> messages:
> | ../../libgcrypt-1.8.0/cipher/rijndael-armv8-aarch32-ce.S:1165:
> Error: selected processor does not support `rbit r8,lr' in ARM mode
> | ../../libgcrypt-1.8.0/cipher/rijndael-armv8-aarch32-ce.S:1165:
> Error: selected processor does not support `rbit r9,r9' in ARM mode
> | ../../libgcrypt-1.8.0/cipher/rijndael-armv8-aarch32-ce.S:1165:
> Error: selected processor does not support `rbit r10,r10' in ARM mode
> | ../../libgcrypt-1.8.0/cipher/rijndael-armv8-aarch32-ce.S:1165:
> Error: selected processor does not support `rbit r11,r11' in ARM mode
> | ../../libgcrypt-1.8.0/cipher/rijndael-armv8-aarch32-ce.S:1165:
> Error: selected processor does not support `rbit r8,lr' in ARM mode
> | ../../libgcrypt-1.8.0/cipher/rijndael-armv8-aarch32-ce.S:1166:
> Error: selected processor does not support `rbit r8,lr' in ARM mode
> | ../../libgcrypt-1.8.0/cipher/rijndael-armv8-aarch32-ce.S:1166:
> Error: selected processor does not support `rbit r9,r9' in ARM mode
> | ../../libgcrypt-1.8.0/cipher/rijndael-armv8-aarch32-ce.S:1166:
> Error: selected processor does not support `rbit r10,r10' in ARM mode
> | ../../libgcrypt-1.8.0/cipher/rijndael-armv8-aarch32-ce.S:1166:
> Error: selected processor does not support `rbit r11,r11' in ARM mode
> | ../../libgcrypt-1.8.0/cipher/rijndael-armv8-aarch32-ce.S:1166:
> Error: selected processor does not support `rbit r8,lr' in ARM mode
> | ../../libgcrypt-1.8.0/cipher/rijndael-armv8-aarch32-ce.S:1167:
> Error: selected processor does not support `rbit r8,lr' in ARM mode
> | ../../libgcrypt-1.8.0/cipher/rijndael-armv8-aarch32-ce.S:1167:
> Error: selected processor does not support `rbit r9,r9' in ARM mode
> ...(snip)...
>
> I googled about this problem then I found the clue at here.
> https://mail-index.netbsd.org/pkgsrc-bugs/2017/08/01/msg062410.html
>
> I thought it fixed at libcrypt_1.8.1.
>
> I tried update to 1.8.1. It seems fine.
> So I suggest the libgcrypt updating for 1.8.1.
It may be too late to update  as we are in the stabilization phase of
the next release.
>
> By the way, I created the patch for this problem.
The is great and much appreciated.

> But I am not sure, where to send to this patch?
Yes it is a bit confusing and we should revisit the documentation.
> I could not found the guidelines of contributing [meta].
> I should send to OE-Core's ML? or  here directly?

The oe-core ML is the appropriate place.


>
> And, Would you let me know what strings of options to git send-email I
> should to set?
if you want to us git send mail, I use the following.

git send-email -1 -M --to  openembedded-c...@lists.openembedded.org
--subject-prefix=PATCH

regards,
Armin

> Thanks.


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

[yocto] libgcrypt building fails for armv6 binaries.

2017-09-22 Thread Yusuke Mitsuki

Hello yocto

libgcrypt has problem that build for armv6.
bitbake said error messages at do_compile as follows:
...(snip)...
| ../../libgcrypt-1.8.0/cipher/rijndael-armv8-aarch32-ce.S: Assembler messages:
| ../../libgcrypt-1.8.0/cipher/rijndael-armv8-aarch32-ce.S:1165:
Error: selected processor does not support `rbit r8,lr' in ARM mode
| ../../libgcrypt-1.8.0/cipher/rijndael-armv8-aarch32-ce.S:1165:
Error: selected processor does not support `rbit r9,r9' in ARM mode
| ../../libgcrypt-1.8.0/cipher/rijndael-armv8-aarch32-ce.S:1165:
Error: selected processor does not support `rbit r10,r10' in ARM mode
| ../../libgcrypt-1.8.0/cipher/rijndael-armv8-aarch32-ce.S:1165:
Error: selected processor does not support `rbit r11,r11' in ARM mode
| ../../libgcrypt-1.8.0/cipher/rijndael-armv8-aarch32-ce.S:1165:
Error: selected processor does not support `rbit r8,lr' in ARM mode
| ../../libgcrypt-1.8.0/cipher/rijndael-armv8-aarch32-ce.S:1166:
Error: selected processor does not support `rbit r8,lr' in ARM mode
| ../../libgcrypt-1.8.0/cipher/rijndael-armv8-aarch32-ce.S:1166:
Error: selected processor does not support `rbit r9,r9' in ARM mode
| ../../libgcrypt-1.8.0/cipher/rijndael-armv8-aarch32-ce.S:1166:
Error: selected processor does not support `rbit r10,r10' in ARM mode
| ../../libgcrypt-1.8.0/cipher/rijndael-armv8-aarch32-ce.S:1166:
Error: selected processor does not support `rbit r11,r11' in ARM mode
| ../../libgcrypt-1.8.0/cipher/rijndael-armv8-aarch32-ce.S:1166:
Error: selected processor does not support `rbit r8,lr' in ARM mode
| ../../libgcrypt-1.8.0/cipher/rijndael-armv8-aarch32-ce.S:1167:
Error: selected processor does not support `rbit r8,lr' in ARM mode
| ../../libgcrypt-1.8.0/cipher/rijndael-armv8-aarch32-ce.S:1167:
Error: selected processor does not support `rbit r9,r9' in ARM mode
...(snip)...

I googled about this problem then I found the clue at here.
https://mail-index.netbsd.org/pkgsrc-bugs/2017/08/01/msg062410.html

I thought it fixed at libcrypt_1.8.1.

I tried update to 1.8.1. It seems fine.
So I suggest the libgcrypt updating for 1.8.1.

By the way, I created the patch for this problem.
But I am not sure, where to send to this patch?
I could not found the guidelines of contributing [meta].
I should send to OE-Core's ML? or  here directly??

And, Would you let me know what strings of options to git send-email I
should to set?

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

Re: [linux-yocto] [linux-yocto-4.8][PATCH] mm/workingset.c: fix implicit declaration of __list_lru_init_key

2017-09-22 Thread akuster808

Cal,


On 09/22/2017 03:48 PM, California Sullivan wrote:
> __list_lru_init_key does not exist. We're looking for __list_lru_init as
> shown in the patch "26690f5 mm: workingset: fix premature shadow node
> shrinking with cgroups".
>
> Signed-off-by: California Sullivan 

I believe this fix is already in latest 4.8 preempt-base.

http://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto-4.8/commit/mm/workingset.c?h=standard/preempt-rt/base=26690f5a8bdf03966c5db20181089f86f8ca8eef

I am working on updating morty to the latest versions.

- armin

> ---
>
> This is for the standard/preempt-rt/base branch. Standard/base is OK.
>
>  mm/workingset.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/mm/workingset.c b/mm/workingset.c
> index 1856fdb..5e953eb 100644
> --- a/mm/workingset.c
> +++ b/mm/workingset.c
> @@ -493,7 +493,7 @@ static int __init workingset_init(void)
>   pr_info("workingset: timestamp_bits=%d max_order=%d bucket_order=%u\n",
>  timestamp_bits, max_order, bucket_order);
>  
> - ret = __list_lru_init_key(&__workingset_shadow_nodes, true, 
> _nodes_key);
> + ret = __list_lru_init(&__workingset_shadow_nodes, true, 
> _nodes_key);
>   if (ret)
>   goto err;
>   ret = register_shrinker(_shadow_shrinker);


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

Re: [yocto] RFC: Backwards compatibility checking sstate-cache

2017-09-22 Thread Joshua Lock


On 22/09/17 15:00, Mike Looijmans wrote:
I think this remark in the referenced link is the best summary of "what 
could be improved":


"""the biggest weakness of the sstate signature bits, in my opinion, is 
that it only tracks inputs, not outputs. If task A depends on B, and the 
metadata input to B changes, then A will be rebuilt, even if the 
*output* of B didn't change as a result of the change to its metadata."""


For example, if someone fixes a bug in gcc that only applies to MIPS, 
then builds that only target an ARM machine shouldn't be affected. Much 
worse than that, I have a dependency like:

gcc -> ... -> python -> bitstream tool -> FPGA image

so this means that a change in gcc causes Python to rebuild, which 
causes the bitstream tool to be rebuilt and produce idential output, and 
that triggers a roughly 31-hour build of lots of FPGA images. These are 
the ones we really want to break. A binary output compare would help a 
lot, even if 80% of the libraries fail to create reproducible output, I 
may still be spared those 31 hours...


I think tracking digital output is technically feasible, and won't 
require any change to existing recipes.


Also think about "feed" setups. When I see my settop reporting "331 
packages need updating"... It'd be great if that could be avoided.




That's what packagefeed-stability.bbclass is for. Work on binary 
reproducibility will improve things here too.


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

[linux-yocto] [linux-yocto-4.8][PATCH] mm/workingset.c: fix implicit declaration of __list_lru_init_key

2017-09-22 Thread California Sullivan

__list_lru_init_key does not exist. We're looking for __list_lru_init as
shown in the patch "26690f5 mm: workingset: fix premature shadow node
shrinking with cgroups".

Signed-off-by: California Sullivan 
---

This is for the standard/preempt-rt/base branch. Standard/base is OK.

 mm/workingset.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/mm/workingset.c b/mm/workingset.c
index 1856fdb..5e953eb 100644
--- a/mm/workingset.c
+++ b/mm/workingset.c
@@ -493,7 +493,7 @@ static int __init workingset_init(void)
pr_info("workingset: timestamp_bits=%d max_order=%d bucket_order=%u\n",
   timestamp_bits, max_order, bucket_order);
 
-   ret = __list_lru_init_key(&__workingset_shadow_nodes, true, 
_nodes_key);
+   ret = __list_lru_init(&__workingset_shadow_nodes, true, 
_nodes_key);
if (ret)
goto err;
ret = register_shrinker(_shadow_shrinker);
-- 
2.9.5

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

[yocto] Workdir of qmake5 recipes in Pyro

2017-09-22 Thread Svein Seldal


Hi

I have a qt5 recipe which is built for a imx6 system with 
MACHINE=lm_cm-poky-linux-gnueabi). The recipe sp.bb contains:


include qmake5
# PACKAGE_ARCH = "${MACHINE_ARCH}"

When I build this on Krogoth I find the build for my recipe under:

   tmp/work/cortexa9hf-neon-poky-linux-gnueabi/sp/

I notice that qtbase is found under:

   tmp/work/cortexa9hf-neon-mx6qdl-poky-linux-gnueabi/qtbase/

When I've changed Poky to Pyro, I noticed that my recipe is now build in:

   tmp/work/cortexa9hf-neon-mx6qdl-poky-linux-gnueabi/sp/

but I haven't made any changes to my recipe. All of my other non-qt 
recipes still place their build output in the other directory.


Why does this change happen? Am I missing something, e.g. a PACKAGE_ARCH 
statement?



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

Re: [yocto] release management

2017-09-22 Thread Svein Seldal

I have also been slightly puzzled over the meticulousness and 
determinism of Yocto on recipe level, but the left-to-yourself thinking 
for the top-level meta-level and configuration management.

We have chosen to make a custom configuration management (CM) and 
lightweight build system on top of Yocto. Firstly, we have mixed SCM, 
mixing both git and hg, and the CM contains a manifest of the sources 
and can handle proper checkout (which repo does too for git).

Secondly, the CM provides a standardized unified location for setting 
configuration options and control of what artifacts to generate. This is 
then independent of what sub-system, like Yocto, is being run behind the 
scenes. Included in this is organization specific systems, such as 
central defining of system version and build numbers.

The CM also contains some postprocessors for Yocto. In the versions of 
Yocto we use, Yocto cannot generate artifacts for more than one MACHINE 
for each bitbake invocation. We must pack all these output artifacts 
into a common releasable end-user image and upload it to our PLM system. 
This part I have not been able to do (cleanly) from a recipe since it 
spans multiple MACHINES.

So our conclusion is that you need to know what Yocto is good at and 
what it can do, and perhaps rely on other systems where this is 
required. YMMV

Best regards,
Svein

On 19. aug. 2017 00:58, Chris Z. wrote:

Hi,

Regarding submodule for layers. This is good when no one beside you use 
it. Especially  with yocto layers. But when dev starts to use it. You or 
other support team will be faced against wall of problems with basic 
understanding of git submodules and index. But google starts to invest 
some funds in submodules instead repo usage. So it can be a game changer 
in favor of git submodules.

 From own experience (dev team of 80 persons) we decided to leave 
submodules in favor of repo tool. But we had the same conclusion at 
first. Why to use other tool were git provides submodules. Further 
development and expansion of layers are pro the repo tool manifest file. 
But that is from my own exp. And it was good change.

Br,
Chris Z

15.08.2017 15:16 "Joshua Watt" > napisał(a):

On Tue, 2017-08-15 at 09:25 +0200, Mike Looijmans wrote:
 > On 14-08-17 21:10, Gunnar Andersson wrote:
 > >
 > > Hey Russell
 > >
 > > I don't claim to be an authority on best practices but I will share
 > > some
 > > thoughts.
 > >
 > > On Sun, 2017-08-13 at 06:58 -0400, Russell Peterson wrote:
 > > > Hello.
 > > >
 > > > As I learn more about yocto and more importantly gain practical
 > > > experience
 > > > with it I have started to think about my release structure.  Is
 > > > there a
 > > > “best practices” document or something like that that speaks to
 > > > this?
 > > > For example, how does everyone deal with “external” meta layer
 > > > dependencies?  My software uses poky and meta-openembedded, of
 > > > course.
 > >
 > > We simply use a parent project [1] that includes git submodules,
 > > one per
 > > yocto layer.  I'm of the opinion that if git (only) can be used,
 > > why
 > > introduce other tools?   But it requires you to learn and master
 > > that
 > > feature.
 > >
 >
 > We arrived at exactly the same setup. One parent repository that
 > contains the
 > project-unique recipes, and submodules for the layers it needs.
 >
 > It's a lot better than attempting to script things. For one thing,
 > git will
 > tell you the state of the submodules.
 >
 > If I rembemer correctly, Android builds use a tool to manage the
 > layer
 > repositories. I didn't much like it though. And "yet another tool"...

It's called "repo" https://code.google.com/archive/p/git-repo/
.

In my experience git submodules work fine if you follow the core
workflow of adding new submodules and updating them to newer versions.
The workflows for deleting, renaming, changed upstream repostiory, etc.
for submodules is IHMO pretty bad. Pretty much every time I've tried
that it has resulted in a borked local repository that I either had to
manually go into the .git directory and fix, or just start over with a
fresh clone (perhaps I'm just bad at it or newer versions of git are
better?). Not to say you shouldn't use them, just be aware of some of
the catches so you can match the tool to your expected workflow.

For my $0.02: We use git submodules to manage the multiple yocto trees
we are pulling in and also keep "parallel" layers for each with the
local changes we want to make in .bbappends, where possible (following
the strategy of no modifying the original). We do (particularly for
older versions of Yocto) make changes to the core since we

Re: [yocto] RFC: Backwards compatibility checking sstate-cache

2017-09-22 Thread Mike Looijmans

I think this remark in the referenced link is the best summary of "what could 
be improved":


"""the biggest weakness of the sstate signature bits, in my opinion, is that 
it only tracks inputs, not outputs. If task A depends on B, and the metadata 
input to B changes, then A will be rebuilt, even if the *output* of B didn't 
change as a result of the change to its metadata."""


For example, if someone fixes a bug in gcc that only applies to MIPS, then 
builds that only target an ARM machine shouldn't be affected. Much worse than 
that, I have a dependency like:

gcc -> ... -> python -> bitstream tool -> FPGA image

so this means that a change in gcc causes Python to rebuild, which causes the 
bitstream tool to be rebuilt and produce idential output, and that triggers a 
roughly 31-hour build of lots of FPGA images. These are the ones we really 
want to break. A binary output compare would help a lot, even if 80% of the 
libraries fail to create reproducible output, I may still be spared those 31 
hours...


I think tracking digital output is technically feasible, and won't require any 
change to existing recipes.


Also think about "feed" setups. When I see my settop reporting "331 packages 
need updating"... It'd be great if that could be avoided.



On 01-07-17 09:48, Martin Jansa wrote:
I haven't tried the patches, but I really like this idea (I was suggesting 
something like that since 2011 
http://permalink.gmane.org/gmane.comp.handhelds.openembedded.core/10327) and 
I'm glad you weren't discouraged attempting to do this.


It also implements 3) b) idea from 
https://bugzilla.yoctoproject.org/show_bug.cgi?id=5970 , you might be 
interested read that ticket.


Thanks

On Fri, Jun 30, 2017 at 11:48 AM, Michael Ho > wrote:


Hi, at BMW Car IT we are working on an experimental feature to improve 
sstate
cache hits and we are looking for comments on the approach who might have 
some
insights to the problem and seeing if anyone is interested in the feature 
for
mainline.

The sstate-cache of a recipe is tied closely to its build dependencies, as 
the
signature generated for a task includes all parent task's signatures as
part of
the signature information. This means that when changes occur in the parent
recipes, even if insignificant, all children recipes that have valid sstate
cache must invalidate their sstate cache objects.

What this patchset does is propose to add another optional variable to
recipes,
CDEPENDS, which acts like DEPENDS for all RunQueue purposes but for 
signature
generation it excludes any parent tasks that come from dependencies listed 
in
it. This is to break the signature change domino effect.

This patchset also proposes modifying RunQueue to then be able to run a
compatibility checker during task execution phase for recipes and tasks
that use
CDEPENDS and allow for deciding to re-execute a task despite being covered 
by
sstate-cache.

The patchset is based on the jethro branch for the poky repository, as this 
is
the branch that we are using.  If the general idea sounds good, we can
consider
porting it to master.

Included is an patch that adds an example recipe and compatibility checker,
where compatibility is based on the file checksums of the parent recipes
packages. An example recipe, cdepends-test1, generates a compatibility 
report
containing the file checksums of all files that it packages and which file
paths
they are at. Another recipe, cdepends-test2, can then strip this 
compatibility
report to the minimal files it needs to be consistent and can compare the
latest
checksums it used to configure/compile/install with and if they have 
changed,
trigger a rebuild. If not, the previous version restored from sstate-cache 
is
used.

We are still experimenting with the usages of this, including the use of
having
abi-compliance-checker to compare the ABI of shared libraries as a
compatibility
checker during RunQueue and using the results to avoid rebuilding child
recipes
when the .so files they depend on are still compatible. Example use cases of
this are allowing recipes which provide multiple shared libraries to change 
a
single .so file without rebuilding all its children that depend on the other
shared libraries but not the one that changed.

We're aware of the SIGGEN_EXCLUDERECIPES_ABISAFE feature but feel it
didn't meet
the feature requirements of what this compatibility checker callback is 
doing,
although maybe when porting to master we could refactor to make better use 
of
the work already done there. The current implementation is a bit hacky but
comments would be appreciated in regards to if the concept is feasible and 
if
people are interested in making use of it and their use cases.

Kind regards,

Re: [yocto] Path to current bb-file or layer

2017-09-22 Thread Svein Seldal




On 22. sep. 2017 13:42, Richard Purdie wrote:

A better way to get what you're after may be to look at the contents
of BBINCLUDED.


Ah, yes. Perfect. You got me onto a lead: Setting SP_BASEDIR := 
"${LAYERDIR}" in layer.conf and then access this variable from the 
bbclass file.


Although I would like to suggest that bitbake should have a FILE-ish 
variable that points to the actual running current file. Especially when 
bbclass files is thought to act as generic black-box-ish collection of 
funtions.


Thank you Richard


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

Re: [yocto] Path to current bb-file or layer

2017-09-22 Thread Richard Purdie

On Fri, 2017-09-22 at 13:04 +0200, Svein Seldal wrote:
> On 22. sep. 2017 10:30, Richard Purdie wrote:
> > Its all about when your code is executed. Try putting:
> > 
> > SP_BASEVERSION := "${@read_spbaseversion(d)}"
> > 
> > in the bbclass file. I suspect that will give you the bbclass file
> > name.
> > 
> > By default everything is deferred expansion so your code would give
> you
> > the final .bb as that is the context the code is run in.
> 
> In local.conf I put:
> 
>  INHERIT += "sp-version"
> 
> In classes/sp-version.bbclass
> 
>  def read_spbaseversion(d):
> # The goal of this function is to read and
> # parse a file from the layer
>  bb.warn("MYSELF: ", d.getVar('FILE', False))
>  return '0'
> 
>  SP_BASEVERSION := "${@read_spbaseversion(d)}"
> 
> Then both on Krogoth and Pyro, the following command returns:
> 
>  $ bitbake -e |tee var.txt |grep MYSELF
> 
> WARNING: MYSELF: /home/s/bughunt-pyro/build/conf/bblayers.conf
> WARNING: MYSELF: /home/s/bughunt-pyro/build/conf/bblayers.conf
>  bb.warn("MYSELF: ", d.getVar('FILE', False))
> 
> Likewise:
> 
>  $ bitbake -e sp-image |tee sp-image.txt |grep MYSELF
> 
> WARNING: MYSELF: /home/s/bughunt-pyro/build/conf/bblayers.conf
> WARNING: MYSELF: /home/s/bughunt-pyro/build/conf/bblayers.conf
> WARNING: MYSELF: /home/s/bughunt-pyro/build/conf/bblayers.conf
>  bb.warn("MYSELF: ", d.getVar('FILE', False))
> 
> 
> Is there an alternative to d.getVar() to access the "other" versions
> of the variable?

I suspect I'm misremembering the places that FILE gets reset in the
bitbake parser. It probably changes for conf and bb files and maybe inc
files but not bbclass files.

Why it does that is before my time with the codebase and I've never
really dared change it.

A better way to get what you're after may be to look at the contents
of BBINCLUDED.

Cheers,

Richard


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

Re: [yocto] Path to current bb-file or layer

2017-09-22 Thread Svein Seldal



On 22. sep. 2017 10:30, Richard Purdie wrote:

> Its all about when your code is executed. Try putting:
> 
> SP_BASEVERSION := "${@read_spbaseversion(d)}"
> 
> in the bbclass file. I suspect that will give you the bbclass file
> name.
> 
> By default everything is deferred expansion so your code would give you
> the final .bb as that is the context the code is run in.

In local.conf I put:

 INHERIT += "sp-version"

In classes/sp-version.bbclass

 def read_spbaseversion(d):
# The goal of this function is to read and
# parse a file from the layer
 bb.warn("MYSELF: ", d.getVar('FILE', False))
 return '0'

 SP_BASEVERSION := "${@read_spbaseversion(d)}"

Then both on Krogoth and Pyro, the following command returns:

 $ bitbake -e |tee var.txt |grep MYSELF

WARNING: MYSELF: /home/s/bughunt-pyro/build/conf/bblayers.conf
WARNING: MYSELF: /home/s/bughunt-pyro/build/conf/bblayers.conf
 bb.warn("MYSELF: ", d.getVar('FILE', False))

Likewise:

 $ bitbake -e sp-image |tee sp-image.txt |grep MYSELF

WARNING: MYSELF: /home/s/bughunt-pyro/build/conf/bblayers.conf
WARNING: MYSELF: /home/s/bughunt-pyro/build/conf/bblayers.conf
WARNING: MYSELF: /home/s/bughunt-pyro/build/conf/bblayers.conf
 bb.warn("MYSELF: ", d.getVar('FILE', False))


Is there an alternative to d.getVar() to access the "other" versions of 
the variable?


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

[linux-yocto] [kernel-cache][PATCH] cgl: Add cgl features

2017-09-22 Thread zhe.he

From: He Zhe 

Add features for Carrier Grade Linux
https://wiki.linuxfoundation.org/cgl/start

Signed-off-by: He Zhe 
---
 cfg/dmm.cfg  |  1 +
 cfg/dmm.scc  |  4 
 cfg/drbd.cfg |  1 +
 cfg/drbd.scc |  4 
 cfg/fs/ocfs2.cfg | 15 +++
 cfg/fs/ocfs2.scc |  4 
 cfg/iscsi.cfg| 14 ++
 cfg/iscsi.scc|  6 ++
 cfg/net/ip_vs.cfg| 36 
 cfg/net/ip_vs.scc|  4 
 cfg/net/l2tp.cfg | 15 +++
 cfg/net/l2tp.scc |  4 
 cfg/net/macvlan.cfg  | 14 ++
 cfg/net/macvlan.scc  |  4 
 features/aoe/aoe.cfg |  1 +
 features/aoe/aoe.scc |  4 
 features/audit/audit.cfg |  6 ++
 features/audit/audit.scc |  4 
 features/mip6/mip6.cfg   |  8 
 features/mip6/mip6.scc   |  5 +
 features/pstore/pstore.cfg   |  3 +++
 features/pstore/pstore.scc   |  4 
 features/qdisc/qdisc_stats.cfg   |  1 +
 features/qdisc/qdisc_stats.scc   |  1 +
 features/quota/quota.cfg |  5 +
 features/quota/quota.scc |  4 
 features/selinux/selinux-dev.cfg |  3 +++
 features/selinux/selinux-dev.scc |  3 +++
 features/selinux/selinux.cfg | 11 +++
 features/selinux/selinux.scc |  4 
 features/udp/udp_stats.cfg   |  1 +
 features/udp/udp_stats.scc   |  1 +
 32 files changed, 195 insertions(+)
 create mode 100644 cfg/dmm.cfg
 create mode 100644 cfg/dmm.scc
 create mode 100644 cfg/drbd.cfg
 create mode 100644 cfg/drbd.scc
 create mode 100644 cfg/fs/ocfs2.cfg
 create mode 100644 cfg/fs/ocfs2.scc
 create mode 100644 cfg/iscsi.cfg
 create mode 100644 cfg/iscsi.scc
 create mode 100644 cfg/net/ip_vs.cfg
 create mode 100644 cfg/net/ip_vs.scc
 create mode 100644 cfg/net/l2tp.cfg
 create mode 100644 cfg/net/l2tp.scc
 create mode 100644 cfg/net/macvlan.cfg
 create mode 100644 cfg/net/macvlan.scc
 create mode 100644 features/aoe/aoe.cfg
 create mode 100644 features/aoe/aoe.scc
 create mode 100644 features/audit/audit.cfg
 create mode 100644 features/audit/audit.scc
 create mode 100644 features/mip6/mip6.cfg
 create mode 100644 features/mip6/mip6.scc
 create mode 100644 features/pstore/pstore.cfg
 create mode 100644 features/pstore/pstore.scc
 create mode 100644 features/qdisc/qdisc_stats.cfg
 create mode 100644 features/qdisc/qdisc_stats.scc
 create mode 100644 features/quota/quota.cfg
 create mode 100644 features/quota/quota.scc
 create mode 100644 features/selinux/selinux-dev.cfg
 create mode 100644 features/selinux/selinux-dev.scc
 create mode 100644 features/selinux/selinux.cfg
 create mode 100644 features/selinux/selinux.scc
 create mode 100644 features/udp/udp_stats.cfg
 create mode 100644 features/udp/udp_stats.scc

diff --git a/cfg/dmm.cfg b/cfg/dmm.cfg
new file mode 100644
index 000..e8645a2
--- /dev/null
+++ b/cfg/dmm.cfg
@@ -0,0 +1 @@
+CONFIG_DM_MULTIPATH=y
diff --git a/cfg/dmm.scc b/cfg/dmm.scc
new file mode 100644
index 000..49fc19a
--- /dev/null
+++ b/cfg/dmm.scc
@@ -0,0 +1,4 @@
+define KFEATURE_DESCRIPTION "Device Mapper Multipath Support"
+define KFEATURE_COMPATIBILITY all
+
+kconf non-hardware dmm.cfg
diff --git a/cfg/drbd.cfg b/cfg/drbd.cfg
new file mode 100644
index 000..475b821
--- /dev/null
+++ b/cfg/drbd.cfg
@@ -0,0 +1 @@
+CONFIG_BLK_DEV_DRBD=y
diff --git a/cfg/drbd.scc b/cfg/drbd.scc
new file mode 100644
index 000..a6de3b8
--- /dev/null
+++ b/cfg/drbd.scc
@@ -0,0 +1,4 @@
+define KFEATURE_DESCRIPTION "DRBD Block Device Support"
+define KFEATURE_COMPATIBILITY all
+
+kconf non-hardware drbd.cfg
diff --git a/cfg/fs/ocfs2.cfg b/cfg/fs/ocfs2.cfg
new file mode 100644
index 000..8d7caf3
--- /dev/null
+++ b/cfg/fs/ocfs2.cfg
@@ -0,0 +1,15 @@
+#.
+#WARNING
+#
+# This file is a kernel configuration fragment, and not a full kernel
+# configuration file.  The final kernel configuration is made up of
+# an assembly of processed fragments, each of which is designed to
+# capture a specific part of the final configuration (e.g. platform
+# configuration, feature configuration, and board specific hardware
+# configuration).  For more information on kernel configuration, please
+# consult the product documentation.
+#
+#.
+
+CONFIG_OCFS2_FS=m
+CONFIG_OCFS2_FS_O2CB=m
diff --git a/cfg/fs/ocfs2.scc b/cfg/fs/ocfs2.scc
new file mode 100644
index 000..4516d66
--- /dev/null
+++ b/cfg/fs/ocfs2.scc
@@ -0,0 +1,4 @@
+define KFEATURE_DESCRIPTION "OCFS2 file system support"
+define KFEATURE_COMPATIBILITY all
+
+kconf non-hardware ocfs2.cfg
diff --git a/cfg/iscsi.cfg

Re: [yocto] QA cycle report for 2.3.2 rc1

2017-09-22 Thread Joshua Lock




On 22/09/17 00:42, Cruz, Libertad wrote:

=== QA-Hints

QA needs help from Joshua and the official AB so that we may run the 
Ubuntu 17.04 distro testing, if you have an Ubuntu 17.04 worker. With 
the objective that the report would be complete before CCB session 
finishes analyzing the results from this release.


Apologies, I missed this detail (thanks Richard for pointing it out). 
I've triggered an nightly-oe-selftest on ubuntu1704:


https://autobuilder.yocto.io/builders/nightly-oe-selftest/builds/536

Joshua
-
Intel Corporation (UK) Limited
Registered No. 1134945 (England)
Registered Office: Pipers Way, Swindon SN3 1RJ
VAT No: 860 2173 47

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Path to current bb-file or layer

2017-09-22 Thread Richard Purdie

On Fri, 2017-09-22 at 10:17 +0200, Svein Seldal wrote:
> On 21. sep. 2017 23:36, Richard Purdie wrote:
>  > You mean like ${FILE} ?
>  >
>  > $ bitbake bash -e | grep ^FILE=
>  > FILE="/media/build1/poky/meta/recipes-extended/bash/bash_4.4.bb"
> 
> To me ${FILE} seems to be pointing towards the receipe, and not the 
> current .bbclass file as you'd expect.
> 
> If I put this in local.conf
> 
>  INHERIT += "sp-version"
>  SP_BASEVERSION = "${@read_spbaseversion(d)}"
> 
> And in sp-version.bbclass:
> 
>  def read_spbaseversion(d):
>  bb.warn("SVEIN FILE: ", d.getVar('FILE', False))
>   return '0'
> 
> If I do bitbake -e, I get
> 
>  WARNING: SVEIN FILE: /home/s/build-sp-
> image/build/conf/bblayers.conf
> 
> Later the read_spbaseversion is used from within recipe (although
> they 
> don't need to as this variable goes into the global scope, but for
> the 
> sake of the demonstration). Then the value being prined is:
> 
> WARNING: /home/s/build-sp-image/meta-sp/sp/sp.bb: SVEIN OPEN: 
> /home/s/build-sp-image/meta-sp/sp/sp.bb
> 
> Hence, ${FILE} seems to point to the current file scope, like a
> recipe, 
> and not any class files that the recipe might take use of.

Its all about when your code is executed. Try putting:

SP_BASEVERSION := "${@read_spbaseversion(d)}"

in the bbclass file. I suspect that will give you the bbclass file
name.

By default everything is deferred expansion so your code would give you
the final .bb as that is the context the code is run in.

Cheers,

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

Re: [yocto] Path to current bb-file or layer

2017-09-22 Thread Svein Seldal

On 21. sep. 2017 23:36, Richard Purdie wrote:
> You mean like ${FILE} ?
>
> $ bitbake bash -e | grep ^FILE=
> FILE="/media/build1/poky/meta/recipes-extended/bash/bash_4.4.bb"

To me ${FILE} seems to be pointing towards the receipe, and not the 
current .bbclass file as you'd expect.

If I put this in local.conf

INHERIT += "sp-version"
SP_BASEVERSION = "${@read_spbaseversion(d)}"

And in sp-version.bbclass:

def read_spbaseversion(d):
bb.warn("SVEIN FILE: ", d.getVar('FILE', False))
return '0'

If I do bitbake -e, I get

WARNING: SVEIN FILE: /home/s/build-sp-image/build/conf/bblayers.conf

Later the read_spbaseversion is used from within recipe (although they 
don't need to as this variable goes into the global scope, but for the 
sake of the demonstration). Then the value being prined is:

WARNING: /home/s/build-sp-image/meta-sp/sp/sp.bb: SVEIN OPEN: 
/home/s/build-sp-image/meta-sp/sp/sp.bb

Hence, ${FILE} seems to point to the current file scope, like a recipe, 
and not any class files that the recipe might take use of.

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

[yocto] Fwd: do_configure error

Re: [yocto] libgcrypt building fails for armv6 binaries.

[yocto] libgcrypt building fails for armv6 binaries.

Re: [linux-yocto] [linux-yocto-4.8][PATCH] mm/workingset.c: fix implicit declaration of __list_lru_init_key

Re: [yocto] RFC: Backwards compatibility checking sstate-cache

[linux-yocto] [linux-yocto-4.8][PATCH] mm/workingset.c: fix implicit declaration of __list_lru_init_key

[yocto] Workdir of qmake5 recipes in Pyro

Re: [yocto] release management

Re: [yocto] RFC: Backwards compatibility checking sstate-cache

Re: [yocto] Path to current bb-file or layer

Re: [yocto] Path to current bb-file or layer

Re: [yocto] Path to current bb-file or layer

[linux-yocto] [kernel-cache][PATCH] cgl: Add cgl features

Re: [yocto] QA cycle report for 2.3.2 rc1

Re: [yocto] Path to current bb-file or layer

Re: [yocto] Path to current bb-file or layer

16 matches

Site Navigation

Mail list logo

Footer information