Re: [yocto] How to use same user in two recipes?

[Maxin B. John]

Hi Fabien,

Good to know that it helps here.

On Wed, Oct 11, 2017 at 07:48:46PM +0200, Fabien Lahoudere wrote:
> Maxin,
> 
> Is this patch submitted or applied for next release?

Submitted the patch to oe-core mailing list today:
http://lists.openembedded.org/pipermail/openembedded-core/2017-October/143288.html

> Thanks
> On Wed, 2017-10-11 at 14:37 +0300, Maxin B. John wrote:
> > Hi Fabien,
> > 
> > On Wed, 2017-10-11 at 13:06 +0300, Henrik Lindblom wrote:
> > > > I think you'll want RDEPENDS instead of DEPENDS in your recipe. DEPENDS 
> > > > implies build time
> > > > dependencies (e.g. libraries) while RDEPENDS actually gets the 
> > > > component installed as a
> > > > runtime
> > > > dependency.
> > > > 
> > > Thanks Henrik
> > > I tried to add RDEPENDS too without success. The problem is that users 
> > > and groups are not
> > > installed
> > > IIUC.
> > 
> > Could you apply this patch and see if it helps here ?
> > 
> > Best Regards,
> > Maxin
> -- 
> Fabien

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

[yocto] Layer versions at runtime

[Alan Martinovic]

I've noticed that bitbake prints the git commit versions of the layers when
the build starts.

meta-python   = "HEAD:b40116cf457b88a2db14b86fda9627fb34d56ae6"
meta-mender-core  = "HEAD:c3b1b465ce3a27fc7b03a6b7ef596348835cff57"
meta-go   = "HEAD:514b2a80a2a4235687e92fb28328bb3e7c2d6c74"

Does this information find it's way into the rootfs?
If not, any suggestions on how to achieve this?

The goal is to have this info available while the image is running.

Be Well,
Alan
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Layer versions at runtime

[Ayoub Zaki]

Hi,

That's easy to do :


do_install_append () {

    for layer in ${BBLAYERS}; do
    cd $layer
    echo -n "$(basename $layer) = "  >> ${D}${sysconfdir}/gitinfo
    git rev-parse HEAD >> ${D}${sysconfdir}/gitinfo
    done
}


add it in a recipe or add it to os-release.bbappend


On 12.10.2017 11:05, Alan Martinovic wrote:
I've noticed that bitbake prints the git commit versions of the layers 
when the build starts.


meta-python       = "HEAD:b40116cf457b88a2db14b86fda9627fb34d56ae6"
meta-mender-core  = "HEAD:c3b1b465ce3a27fc7b03a6b7ef596348835cff57"
meta-go           = "HEAD:514b2a80a2a4235687e92fb28328bb3e7c2d6c74"

Does this information find it's way into the rootfs?
If not, any suggestions on how to achieve this?

The goal is to have this info available while the image is running.

Be Well,
Alan




--
Ayoub Zaki
Embedded Systems Consultant

Vaihinger Straße 2/1
D-71634 Ludwigsburg

Tel. : +4971415074546
Mobile   : +4917662901545
Email: ayoub.z...@embexus.com
Homepage : https://embexus.com

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

[yocto] Navigating the layer labyrinth

[Bernd]

I am a new user for a few weeks now, trying to make a customized image
for a toradex colibri-vf module, so far I have succeeded in the
following disciplines:

* adding the 3rd party layers that I need
* making my own layers
* using a .bbappend to patch the device tree
* using a .bbappend to workaround a bug(?) in one of the freescale layers
* writing my own recipe to install a python script
* writing recipes for pulling additional python packages with pypi and
setuptools3
* writing my own image recipe
* making it boot and run on the target platform

During this learning experience I have made the following observations
of circumstances that made it especially hard for me to get things
done, I'm not yet really sure if this is a documentation issue or if
it is really a missing feature but I feel I could have had a much
*much* easier time learning and understanding the concepts and
relationships and the inner workings of existing layers upon which I
want to build my system if the following things were possible (and/or
if they are already possible they should be documented in the very
first chapter of the documentation):

* Finding the *file path* of an existing recipe (or append file or
class) *by its name* and also all existing .bbappends for it, i
imagine something simple like bitbake --show-paths foo-bar would
output me the small list of absolute paths of recipe files by the name
foo-bar and all matching .bbappend files in the order in which they
would be applied, it would show me only this small list of paths and
not dump 100kb of unrelated information along with it. This would be
incredibly helpful when I need to inspect an existing recipe in order
to understand how I can bbappend it or even just to see and understand
what it actually does.

* A simple way to track the assignment of a certain variable, to
inspect its contents and if it refers to other variables then
recursively show their contents too (and also the path of the bb file
where this happens), and also show which other recipes will directly
and indirectrly depend on this variable further down the line, I
imagine this should output two tree-like structures where one can see
at one glance how and where all the contents of that variable come
from and where they are going to be used. Again this should be a
simple command that formats and outputs that (and only that)
information in a well formatted and compact tree-like representation.

* The absolute killer application would be an IDE or an editor plugin
where I open any .bb file and can then just CTRL-click on any include,
require, inherit, depend, rdepend, or any variable name and it would
open another editor containing that recipe file where it is defined
and/or populate a sidebar with a list or a tree of direct and indirect
references to that name, backward and forward, and I could just click
on any node of that tree an and it would open the file in the editor
and jump to that line of code. Such a thing would be an incredibly
helpful tool, it would make even the most complex and tangled
labyrinth of recipes navigable with ease.

Please tell me that such a thing already exists and I just have not
found it yet.

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

[yocto] possible to append or patch existing machine .conf file?

[Bernd]

Suppose I have the following bugfix patch for a 3rd party machine conf
file I am using:

diff --git a/conf/machine/colibri-vf.conf b/conf/machine/colibri-vf.conf
index 3ddef79..ba47488 100644
--- a/conf/machine/colibri-vf.conf
+++ b/conf/machine/colibri-vf.conf
@@ -35,6 +35,6 @@ MKUBIFS_ARGS = " -c 8112 -e 124KiB -m 2KiB -F"
 UBINIZE_ARGS = " -p 128KiB -m 2048 -s 2048"
 UBI_VOLNAME = "rootfs"

-SERIAL_CONSOLE ?= "115200 ttyLP0"
+SERIAL_CONSOLE = "115200 ttyLP0"

 MACHINE_FEATURES += "usbgadget usbhost vfat alsa touchscreen"

Is there a proper way to somehow temporarily add something to my layer
to apply this patch until it makes its way upstream and into the
branch I am using? Or should I make my own machine file, include the
original one and then change the variable?

So far I have not found any elegant way to otherwise force this
variable to its correct value in my image recipe, the only way I have
found to work around this bug is to .bbappend the inittab recipe where
this variable is actually used and change the value of another
variable (SERIAL_CONSOLES, note the S at the end) which is derived
from SERIAL_CONSOLE right there in this bbappend file. This seems to
help.

But while doing this I have also noticed a strange anomaly in the
output of bitbake -e:

* When I change the variable in my image recipe then bitbake -e will
show another "set" access and both variables SERIAL_CONSOLE and
SERIAL_CONSOLES will have the correct value as intended by me but the
produced image will have the **wrong** entry in its inittab.

* When I bbappend the inittab recipe to set SERIAL_CONSOLES right
there where it is used then my final image will have a correct inittab
and the serial console will work bit there is **no** mention of that
variable change in the output of bitbake -e

* Only when I change the machine conf file iitself to set the variable
then bitbake -e and the produced image both show the correct entry.
Why does it behave that way?
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Navigating the layer labyrinth

[Aaron Schwartz]

 Hello,

I am not sure if you've found the OpenEmbedded Layer Index [0] yet, but
that's a good resource and an example of what can be done.  I believe the
source code is available [1] and I've toyed with the idea of getting it
working locally (although I've not had the time to do so).

That could be a part of what you're looking for, at least.

Hope that helps,
Aaron



0) https://layers.openembedded.org/layerindex/branch/master/recipes/
1) http://git.yoctoproject.org/cgit/cgit.cgi/layerindex-web/tree/layerindex


On Thu, Oct 12, 2017 at 5:34 AM, Bernd  wrote:

> I am a new user for a few weeks now, trying to make a customized image
> for a toradex colibri-vf module, so far I have succeeded in the
> following disciplines:
>
> * adding the 3rd party layers that I need
> * making my own layers
> * using a .bbappend to patch the device tree
> * using a .bbappend to workaround a bug(?) in one of the freescale layers
> * writing my own recipe to install a python script
> * writing recipes for pulling additional python packages with pypi and
> setuptools3
> * writing my own image recipe
> * making it boot and run on the target platform
>
> During this learning experience I have made the following observations
> of circumstances that made it especially hard for me to get things
> done, I'm not yet really sure if this is a documentation issue or if
> it is really a missing feature but I feel I could have had a much
> *much* easier time learning and understanding the concepts and
> relationships and the inner workings of existing layers upon which I
> want to build my system if the following things were possible (and/or
> if they are already possible they should be documented in the very
> first chapter of the documentation):
>
> * Finding the *file path* of an existing recipe (or append file or
> class) *by its name* and also all existing .bbappends for it, i
> imagine something simple like bitbake --show-paths foo-bar would
> output me the small list of absolute paths of recipe files by the name
> foo-bar and all matching .bbappend files in the order in which they
> would be applied, it would show me only this small list of paths and
> not dump 100kb of unrelated information along with it. This would be
> incredibly helpful when I need to inspect an existing recipe in order
> to understand how I can bbappend it or even just to see and understand
> what it actually does.
>
> * A simple way to track the assignment of a certain variable, to
> inspect its contents and if it refers to other variables then
> recursively show their contents too (and also the path of the bb file
> where this happens), and also show which other recipes will directly
> and indirectrly depend on this variable further down the line, I
> imagine this should output two tree-like structures where one can see
> at one glance how and where all the contents of that variable come
> from and where they are going to be used. Again this should be a
> simple command that formats and outputs that (and only that)
> information in a well formatted and compact tree-like representation.
>
> * The absolute killer application would be an IDE or an editor plugin
> where I open any .bb file and can then just CTRL-click on any include,
> require, inherit, depend, rdepend, or any variable name and it would
> open another editor containing that recipe file where it is defined
> and/or populate a sidebar with a list or a tree of direct and indirect
> references to that name, backward and forward, and I could just click
> on any node of that tree an and it would open the file in the editor
> and jump to that line of code. Such a thing would be an incredibly
> helpful tool, it would make even the most complex and tangled
> labyrinth of recipes navigable with ease.
>
> Please tell me that such a thing already exists and I just have not
> found it yet.
>
> Bernd
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>



-- 

Aaron Schwartz
Production
Logic Supply
Direct: +1 802 861 2300 Ext. 530
Main: +1 802 861 2300
www.logicsupply.com

Google+  | Twitter
 | LinkedIn
 | YouTube

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

Re: [yocto] Navigating the layer labyrinth

[Alexander Kanavin]

On 10/12/2017 12:34 PM, Bernd wrote:

* Finding the *file path* of an existing recipe (or append file or
class) *by its name* and also all existing .bbappends for it, i
imagine something simple like bitbake --show-paths foo-bar would
output me the small list of absolute paths of recipe files by the name
foo-bar and all matching .bbappend files in the order in which they
would be applied, it would show me only this small list of paths and
not dump 100kb of unrelated information along with it. This would be
incredibly helpful when I need to inspect an existing recipe in order
to understand how I can bbappend it or even just to see and understand
what it actually does.

* A simple way to track the assignment of a certain variable, to
inspect its contents and if it refers to other variables then
recursively show their contents too (and also the path of the bb file
where this happens), and also show which other recipes will directly
and indirectrly depend on this variable further down the line, I
imagine this should output two tree-like structures where one can see
at one glance how and where all the contents of that variable come
from and where they are going to be used. Again this should be a
simple command that formats and outputs that (and only that)
information in a well formatted and compact tree-like representation.


I think bitbake -e could be of some help with these two things. It's not 
particularly compact, but it tells you the full story.


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

Re: [yocto] Navigating the layer labyrinth

[Joshua Lock]

On 12/10/17 10:34, Bernd wrote:

I am a new user for a few weeks now, trying to make a customized image
for a toradex colibri-vf module, so far I have succeeded in the
following disciplines:

* adding the 3rd party layers that I need
* making my own layers
* using a .bbappend to patch the device tree
* using a .bbappend to workaround a bug(?) in one of the freescale layers
* writing my own recipe to install a python script
* writing recipes for pulling additional python packages with pypi and
setuptools3
* writing my own image recipe
* making it boot and run on the target platform

During this learning experience I have made the following observations
of circumstances that made it especially hard for me to get things
done, I'm not yet really sure if this is a documentation issue or if
it is really a missing feature but I feel I could have had a much
*much* easier time learning and understanding the concepts and
relationships and the inner workings of existing layers upon which I
want to build my system if the following things were possible (and/or
if they are already possible they should be documented in the very
first chapter of the documentation):

* Finding the *file path* of an existing recipe (or append file or
class) *by its name* and also all existing .bbappends for it, i
imagine something simple like bitbake --show-paths foo-bar would
output me the small list of absolute paths of recipe files by the name
foo-bar and all matching .bbappend files in the order in which they
would be applied, it would show me only this small list of paths and
not dump 100kb of unrelated information along with it. This would be
incredibly helpful when I need to inspect an existing recipe in order
to understand how I can bbappend it or even just to see and understand
what it actually does.


bitbake-layers supports at least some of this functionality:

$ bitbake-layers -h
NOTE: Starting bitbake server...
usage: bitbake-layers [-d] [-q] [-F] [--color COLOR] [-h]  ...

BitBake layers utility

optional arguments:
  -d, --debug   Enable debug output
  -q, --quiet   Print only errors
  -F, --force   Force add without recipe parse verification
  --color COLOR Colorize output (where COLOR is auto, always, 
never)

  -h, --helpshow this help message and exit

subcommands:
  
add-layer   Add a layer to bblayers.conf.
remove-layerRemove a layer from bblayers.conf.
flatten flatten layer configuration into a separate output
directory.
layerindex-fetchFetches a layer from a layer index along with its
dependent layers, and adds them to 
conf/bblayers.conf.

layerindex-show-depends
Find layer dependencies from layer index.
show-layers show current configured layers.
show-overlayed  list overlayed recipes (where the same recipe 
exists

in another layer)
show-recipeslist available recipes, showing the layer they are
provided by
show-appendslist bbappend files and recipe files they apply to
show-cross-depends  Show dependencies between recipes that cross layer
boundaries.
create-layerCreate a basic layer

Use bitbake-layers  --help to get help on a specific command

Thanks,

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

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

[Michael Ho]

Hi Richard (and all),

@Richard: Thanks for the input regarding the topic and apologies for not 
replying until now, I was a bit buried under workload and simultaneously 
completing my Masters studies. I also wanted to take some time to digest your 
comments amid working on this CDEPENDS concept, and I just want to say that I'm 
very open to finding another way to implement this concept of rebuild avoidance 
in Yocto.

I think the idea of a non-invasive approach can be a bit tricky, but your idea 
of a secondary sstate signature and mapping table sounds workable to me. (In 
fact, as I slowly developed out this concept, I think it's almost required). 
One point though with the removal of the metadata changes is that the view of 
"what is compatible" will be concrete and cannot differ among children. 
Sometimes you have only specific children of a recipe that can handle 
compatibility changes (and at different levels of compatibility) while others 
cannot handle any change at all, and that is why I developed with the metadata 
changes as a basis. But definitely, yes, the change to metadata makes things 
more complex and does in a sense impose policy, which I understand would be 
undesirable. Maybe we can figure out an approach that avoids metadata changes 
but keeps this ability to differ compatibility handling among children.

Currently I have a working proof of concept (I've developed out the earlier 
shared patches further) that I'd like to share soon and demonstrate. It still 
needs some further refinement but I think it's showing some interesting results 
already. I'll think further about the topic and see what I can come up with 
that matches your line of thoughts.

@Martin Jansa: Thank you for the comments and information, it's good to know 
that there's some interest from the community to look into this idea.

@Mike Looijmans: Yes, that's essentially the problem I want to resolve with 
this proof of concept, breaking long build chains at points where a clear 
precision cut could've been made depending on whether a rebuild is actually 
required or not (i.e. the bitstream tool not changing). In that case I would 
even use the tool version and assume even if the tool binary has changed, that 
the output result of tool would stay the same so it is compatible in essence 
(and avoid rebuilding 31 hours of stuff).

@Trevor Woerner: Thanks for the suggestion, I was planning to cross-post when I 
had a more stable proof of concept code to share.

Note: I'll be following my colleague, Mario Domenech Goulart (mario-goulart), 
to OEDEM 2017 where I hope to discuss the current concept code and show some 
potential use cases.

Kind regards,
Michael Ho

--
BMW Car IT GmbH
Michael Ho
Spezialist Entwicklung - Linux Software Integration
Lise-Meitner-Str. 14
89081 Ulm

Tel.: +49 731 3780 4071
Mobil: +49 152 5498 0471
Fax: +49-731-37804-001
Mail: michael...@bmw-carit.de
Web: http://www.bmw-carit.de

BMW Car IT GmbH
Gechäftsführer: Kai-Uwe Balszuweit und Alexis Trolin
Sitz und Registergericht: München HRB 134810



From: Richard Purdie 
Sent: 21 September 2017 18:11
To: Michael Ho; yocto@yoctoproject.org
Subject: Re: [yocto] RFC: Backwards compatibility checking sstate-cache

On Fri, 2017-06-30 at 09:48 +, 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.

Sorry I didn't see this before now but it was brought to my attention.

I have given this problem quite some thought off and on. I do worry
that the interface you propose is complex and requires changes
throughout the metadata and those changes impose "policy". One of our
strengths is that we're managed to keep "policy" out of the metadata.

In this context by policy, I mean when a recipe is equivalent and when
it is not.

I do have a counter-proposal of how we could solve this in a less
invasive way. This isn't implemented but wouldn't in theory be hard to
do.

The idea would be to have some kind of equivalence list. The first
built object's sstate checksum would become the definitive checksum and
the object added to the sstate cache.

If a new object is built, it would be compared with the one in sstate.
If deemed equivalent (by whatever policy), a mapping would be added to
the list. If not, there is no mapping and it becomes a new definitive
checksum.

All runqueue would then have to do is present its list of sstate
checksums to the list and convert them (in dependency order) into
canonical checksums.

This list could be a local equivalence file, or an equivalence server
which could resolve list of checksums.

Doing it this way totally isolates the comparison from the metadata
itself and in my vi

Re: [yocto] Layer versions at runtime

[Philip Balister]

Or better yet use
http://www.yoctoproject.org/docs/2.3.2/mega-manual/mega-manual.html#ref-classes-image-buildinfo

to get:

---
Build Configuration:  |
---
DISTRO = nodistro
DISTRO_VERSION = nodistro.0
---
Layer Revisions:  |
---
meta  = master:8ca61a5464743ff85b6d26886112750d6ddd13e0
meta-xilinx   = master:74a0d90e52cca346d05a69bbd628c6ec9e49fbcb
meta-oe   = master:5c9a4a08844c215ebd6f2146f50de753b8e7ecef
meta-networking   = master:5c9a4a08844c215ebd6f2146f50de753b8e7ecef
meta-filesystems  = master:5c9a4a08844c215ebd6f2146f50de753b8e7ecef
meta-python   = master:5c9a4a08844c215ebd6f2146f50de753b8e7ecef
meta-multimedia   = master:5c9a4a08844c215ebd6f2146f50de753b8e7ecef
meta-sdr  = qt5-test:dacc304b01eac7448ec1ebf0b3d0eab761c41a26 --
modified
meta-qt5  = master:2c3ef00f53683fbdce5b390950b49b67da85d3a1
meta-qcom = master:bae28268a9387bb842ab7bbe8200b98c1210604c
meta-raspberrypi  = master:9d84186870a6f9bde44575690105b9bb5e44ca24

Philip

On 10/12/2017 05:11 AM, Ayoub Zaki wrote:
> Hi,
> 
> That's easy to do :
> 
> 
> do_install_append () {
> 
>     for layer in ${BBLAYERS}; do
>     cd $layer
>     echo -n "$(basename $layer) = "  >> ${D}${sysconfdir}/gitinfo
>     git rev-parse HEAD >> ${D}${sysconfdir}/gitinfo
>     done
> }
> 
> 
> add it in a recipe or add it to os-release.bbappend
> 
> 
> On 12.10.2017 11:05, Alan Martinovic wrote:
>> I've noticed that bitbake prints the git commit versions of the layers
>> when the build starts.
>>
>> meta-python       = "HEAD:b40116cf457b88a2db14b86fda9627fb34d56ae6"
>> meta-mender-core  = "HEAD:c3b1b465ce3a27fc7b03a6b7ef596348835cff57"
>> meta-go           = "HEAD:514b2a80a2a4235687e92fb28328bb3e7c2d6c74"
>>
>> Does this information find it's way into the rootfs?
>> If not, any suggestions on how to achieve this?
>>
>> The goal is to have this info available while the image is running.
>>
>> Be Well,
>> Alan
>>
>>
> 
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Yocto Image with custom directory layout

[Ayoub Zaki]

Hi,
I would like to generate an image that contains a custom directories 
layout for expl:



foo/
├── bar1
│   └── bar2
│   ├── config
│   └── data
└── work
    └── var
    └── lib
    ├── config
    └── data

It should contains only those directories an nothing else, is there 
anyway to achieve that ? without using ROOTFS_POSTPROCESS_COMMAND.


I would like to use in a seperate partition.

Thank you !


--
Ayoub Zaki
Embedded Systems Consultant

Vaihinger Straße 2/1
D-71634 Ludwigsburg

Tel. : +4971415074546
Mobile   : +4917662901545
Email: ayoub.z...@embexus.com
Homepage : https://embexus.com

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

Re: [yocto] possible to append or patch existing machine .conf file?

[Andre McCurdy]

On Thu, Oct 12, 2017 at 3:32 AM, Bernd  wrote:
> Suppose I have the following bugfix patch for a 3rd party machine conf
> file I am using:
>
> diff --git a/conf/machine/colibri-vf.conf b/conf/machine/colibri-vf.conf
> index 3ddef79..ba47488 100644
> --- a/conf/machine/colibri-vf.conf
> +++ b/conf/machine/colibri-vf.conf
> @@ -35,6 +35,6 @@ MKUBIFS_ARGS = " -c 8112 -e 124KiB -m 2KiB -F"
>  UBINIZE_ARGS = " -p 128KiB -m 2048 -s 2048"
>  UBI_VOLNAME = "rootfs"
>
> -SERIAL_CONSOLE ?= "115200 ttyLP0"
> +SERIAL_CONSOLE = "115200 ttyLP0"
>
>  MACHINE_FEATURES += "usbgadget usbhost vfat alsa touchscreen"
>
> Is there a proper way to somehow temporarily add something to my layer
> to apply this patch until it makes its way upstream and into the
> branch I am using? Or should I make my own machine file, include the
> original one and then change the variable?

That would be one way. You could also over-ride from any other global
config file, e.g. local.conf or the distro config file (if you have
one).

> So far I have not found any elegant way to otherwise force this
> variable to its correct value in my image recipe

Right, the variable is not used by the image recipe, so setting it
there won't change anything. Variables in an image recipe generally
only relate to how the image is constructed (what packages it contains
and format of the final image - tar.gz, squashfs, etc).

>, the only way I have
> found to work around this bug is to .bbappend the inittab recipe where
> this variable is actually used and change the value of another
> variable (SERIAL_CONSOLES, note the S at the end) which is derived
> from SERIAL_CONSOLE right there in this bbappend file. This seems to
> help.

For variables which are specific to one recipe then over-riding in the
context of that recipe is OK. However, SERIAL_CONSOLES is used in a
few different recipes, so over-riding from a global config file would
necessary to be sure of changing it consistently wherever it's used.

> But while doing this I have also noticed a strange anomaly in the
> output of bitbake -e:
>
> * When I change the variable in my image recipe then bitbake -e will
> show another "set" access and both variables SERIAL_CONSOLE and
> SERIAL_CONSOLES will have the correct value as intended by me but the
> produced image will have the **wrong** entry in its inittab.

If you run bitbake -e for inittab and for the image recipe and compare
the two it should show that setting the variable from within the image
recipe has no effect on the inittab recipe. That's not a bug.

> * When I bbappend the inittab recipe to set SERIAL_CONSOLES right
> there where it is used then my final image will have a correct inittab
> and the serial console will work bit there is **no** mention of that
> variable change in the output of bitbake -e

Similar to above, bitbake -e will give different results for each recipe.

> * Only when I change the machine conf file iitself to set the variable
> then bitbake -e and the produced image both show the correct entry.
> Why does it behave that way?

Because the machine config is a global config file and any variables
it sets are seen by every recipe.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [PATCH 0/1] Send email notification on publication

[Amanda Brindle]

The following changes since commit ad1aac4ea5d4f2b327f7bd9611aed13f7c31ff7e:

  Show note if layer branch hasn't been indexed (2017-10-04 13:49:00 +1300)

are available in the git repository at:

  git://git.yoctoproject.org/layerindex-web 
abrindle/email_notification_publication
  
http://git.yoctoproject.org/cgit.cgi/layerindex-web/log/?h=abrindle/email_notification_publication

Amanda Brindle (1):
  Send email notification on publication

 layerindex/views.py  | 22 +-
 templates/layerindex/publishemail.txt|  7 +++
 templates/layerindex/publishemailsubject.txt |  1 +
 3 files changed, 29 insertions(+), 1 deletion(-)
 create mode 100644 templates/layerindex/publishemail.txt
 create mode 100644 templates/layerindex/publishemailsubject.txt

-- 
2.7.4

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

[yocto] [PATCH 1/1] Send email notification on publication

[Amanda Brindle]

When publishing a layer, send an email notification to all of that
layer's maintainers.

Fixes [YOCTO #11208]

Signed-off-by: Amanda Brindle 
---
 layerindex/views.py  | 22 +-
 templates/layerindex/publishemail.txt|  7 +++
 templates/layerindex/publishemailsubject.txt |  1 +
 3 files changed, 29 insertions(+), 1 deletion(-)
 create mode 100644 templates/layerindex/publishemail.txt
 create mode 100644 templates/layerindex/publishemailsubject.txt

diff --git a/layerindex/views.py b/layerindex/views.py
index bcf6671..35949dd 100644
--- a/layerindex/views.py
+++ b/layerindex/views.py
@@ -5,7 +5,7 @@
 # Licensed under the MIT license, see COPYING.MIT for details
 
 import sys
-from django.shortcuts import get_object_or_404, render
+from django.shortcuts import get_object_or_404, get_list_or_404, render
 from django.http import HttpResponse, HttpResponseRedirect, 
HttpResponseForbidden, Http404
 from django.core.urlresolvers import reverse, reverse_lazy, resolve
 from django.core.exceptions import PermissionDenied
@@ -261,6 +261,26 @@ def _check_url_branch(kwargs):
 def publish(request, name):
 if not (request.user.is_authenticated() and 
request.user.has_perm('layerindex.publish_layer')):
 raise PermissionDenied
+from_email = settings.SUBMIT_EMAIL_FROM
+plaintext = get_template('layerindex/publishemail.txt')
+subjecttext = get_template('layerindex/publishemailsubject.txt')
+e = Context({
+'layer_name': layeritem.name,
+'site_name': request.META['HTTP_HOST'],
+})
+subject = subjecttext.render(e).rstrip()
+layeritem = get_object_or_404(LayerItem, name=name)
+layerbranch = get_object_or_404(LayerBranch, layer=layeritem)
+maintainers = get_list_or_404(LayerMaintainer, layerbranch=layerbranch)
+layer_url = request.build_absolute_uri(reverse('layer_item', 
args=(layerbranch.branch, layeritem.name)))
+for m in maintainers:
+d = Context({
+'maintainer_name': m.name,
+'layer_name': layeritem.name,
+'layer_url': layer_url,
+})
+text_content = plaintext.render(d)
+tasks.send_email.apply_async((subject, text_content, from_email, 
[m.email]))
 return _statuschange(request, name, 'P')
 
 def _statuschange(request, name, newstatus):
diff --git a/templates/layerindex/publishemail.txt 
b/templates/layerindex/publishemail.txt
new file mode 100644
index 000..2500bff
--- /dev/null
+++ b/templates/layerindex/publishemail.txt
@@ -0,0 +1,7 @@
+Hi {{ maintainer_name }},
+
+You are listed as a maintainer for the new layer, {{ layer_name }}. This layer 
has been published. You can view it at the following URL:
+
+ {{ layer_url }}
+
+Thanks!
diff --git a/templates/layerindex/publishemailsubject.txt 
b/templates/layerindex/publishemailsubject.txt
new file mode 100644
index 000..a46eaf2
--- /dev/null
+++ b/templates/layerindex/publishemailsubject.txt
@@ -0,0 +1 @@
+{{layer_name }} was published to {{site_name}}
-- 
2.7.4

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

Re: [yocto] possible to append or patch existing machine .conf file?

[Ayoub Zaki]

Hi,

On 12.10.2017 12:32, Bernd wrote:

Suppose I have the following bugfix patch for a 3rd party machine conf
file I am using:

diff --git a/conf/machine/colibri-vf.conf b/conf/machine/colibri-vf.conf
index 3ddef79..ba47488 100644
--- a/conf/machine/colibri-vf.conf
+++ b/conf/machine/colibri-vf.conf
@@ -35,6 +35,6 @@ MKUBIFS_ARGS = " -c 8112 -e 124KiB -m 2KiB -F"
  UBINIZE_ARGS = " -p 128KiB -m 2048 -s 2048"
  UBI_VOLNAME = "rootfs"

-SERIAL_CONSOLE ?= "115200 ttyLP0"
+SERIAL_CONSOLE = "115200 ttyLP0"

  MACHINE_FEATURES += "usbgadget usbhost vfat alsa touchscreen"

Is there a proper way to somehow temporarily add something to my layer
to apply this patch until it makes its way upstream and into the
branch I am using? Or should I make my own machine file, include the
original one and then change the variable?

you can add to local.conf or distro.conf :

include conf/machine/${MACHINE}-extra.conf

then create in your meta layer or bsp layer :

conf/machine/beaglebone-extra.conf
conf/machine/rasberrypi-extra.conf
conf/machine/xyz-extra.conf

which contains overrides for your machine settings.
Note that is an include and not require, which means that if you machine 
has no *extra.conf then it's simply skkiped ( no overrides)


So far I have not found any elegant way to otherwise force this
variable to its correct value in my image recipe, the only way I have
found to work around this bug is to .bbappend the inittab recipe where
this variable is actually used and change the value of another
variable (SERIAL_CONSOLES, note the S at the end) which is derived
from SERIAL_CONSOLE right there in this bbappend file. This seems to
help.

But while doing this I have also noticed a strange anomaly in the
output of bitbake -e:

* When I change the variable in my image recipe then bitbake -e will
show another "set" access and both variables SERIAL_CONSOLE and
SERIAL_CONSOLES will have the correct value as intended by me but the
produced image will have the **wrong** entry in its inittab.

* When I bbappend the inittab recipe to set SERIAL_CONSOLES right
there where it is used then my final image will have a correct inittab
and the serial console will work bit there is **no** mention of that
variable change in the output of bitbake -e

* Only when I change the machine conf file iitself to set the variable
then bitbake -e and the produced image both show the correct entry.
Why does it behave that way?


--
Ayoub Zaki
Embedded Systems Consultant

Vaihinger Straße 2/1
D-71634 Ludwigsburg

Tel. : +4971415074546
Mobile   : +4917662901545
Email: ayoub.z...@embexus.com
Homepage : https://embexus.com

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

Re: [yocto] Yocto Image with custom directory layout

[Josef Holzmayr]

Hi

On 12.10.2017 19:07, Ayoub Zaki wrote:

Hi,
I would like to generate an image that contains a custom directories 
layout for expl:



foo/
├── bar1
│   └── bar2
│   ├── config
│   └── data
└── work
     └── var
     └── lib
     ├── config
     └── data

It should contains only those directories an nothing else, is there 
anyway to achieve that ? without using ROOTFS_POSTPROCESS_COMMAND.


Should be possible if your image installs only your specific recipes 
that populate those directories. Means: no packagegroup-core-boot, no 
base-passwd, no -> then nothing should bring along other directories.


Greetz
--
Josef Holzmayr
Software Developer Embedded Systems

Tel: +49 8444 9204-48
Fax: +49 8444 9204-50

R-S-I Elektrotechnik GmbH & Co. KG
Woelkestrasse 11
D-85301 Schweitenkirchen
www.rsi-elektrotechnik.de
———
Amtsgericht Ingolstadt – GmbH: HRB 191328 – KG: HRA 170393
Geschäftsführer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg
Ust-IdNr: DE 128592548

_
Amtsgericht Ingolstadt - GmbH: HRB 191328 - KG: HRA 170363
Geschäftsführer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg
USt-IdNr.: DE 128592548

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

Re: [yocto] Yocto Image with custom directory layout

[Ayoub Zaki]

Hi,


On 12.10.2017 20:34, Josef Holzmayr wrote:

Hi

On 12.10.2017 19:07, Ayoub Zaki wrote:

Hi,
I would like to generate an image that contains a custom directories 
layout for expl:



foo/
├── bar1
│   └── bar2
│   ├── config
│   └── data
└── work
 └── var
 └── lib
 ├── config
 └── data

It should contains only those directories an nothing else, is there 
anyway to achieve that ? without using ROOTFS_POSTPROCESS_COMMAND.


Should be possible if your image installs only your specific recipes 
that populate those directories. Means: no packagegroup-core-boot, no 
base-passwd, no -> then nothing should bring along other directories.

I tried that but it does pull other packages even if I set in my image:

IMAGE_FEATURES = ""
IMAGE_LINGUAS = ""
PACKAGE_INSTALL = "my-layout-recipe"

Regards

--
Ayoub Zaki
Embedded Systems Consultant

Vaihinger Straße 2/1
D-71634 Ludwigsburg

Tel. : +4971415074546
Mobile   : +4917662901545
Email: ayoub.z...@embexus.com
Homepage : https://embexus.com

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

Re: [yocto] Yocto Image with custom directory layout

[Josef Holzmayr]

Hi

On 12.10.2017 20:47, Ayoub Zaki wrote:

Hi,


On 12.10.2017 20:34, Josef Holzmayr wrote:

Hi

On 12.10.2017 19:07, Ayoub Zaki wrote:

Hi,
I would like to generate an image that contains a custom directories 
layout for expl:



foo/
├── bar1
│   └── bar2
│   ├── config
│   └── data
└── work
 └── var
 └── lib
 ├── config
 └── data

It should contains only those directories an nothing else, is there 
anyway to achieve that ? without using ROOTFS_POSTPROCESS_COMMAND.


Should be possible if your image installs only your specific recipes 
that populate those directories. Means: no packagegroup-core-boot, no 
base-passwd, no -> then nothing should bring along other directories.

I tried that but it does pull other packages even if I set in my image:

IMAGE_FEATURES = ""
IMAGE_LINGUAS = ""
PACKAGE_INSTALL = "my-layout-recipe"

Regards



Probably you're inheriting from some more complex image class that pulls 
in the undesired packages. Have you already checked bitbake -e to see 
how the variables get expanded?


Greetz

--
Josef Holzmayr
Software Developer Embedded Systems

Tel: +49 8444 9204-48
Fax: +49 8444 9204-50

R-S-I Elektrotechnik GmbH & Co. KG
Woelkestrasse 11
D-85301 Schweitenkirchen
www.rsi-elektrotechnik.de
———
Amtsgericht Ingolstadt – GmbH: HRB 191328 – KG: HRA 170393
Geschäftsführer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg
Ust-IdNr: DE 128592548

_
Amtsgericht Ingolstadt - GmbH: HRB 191328 - KG: HRA 170363
Geschäftsführer: Dr.-Ing. Michael Sorg, Dipl.-Ing. Franz Sorg
USt-IdNr.: DE 128592548

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

[yocto] devtool sdk-install

[Aaron_Wright]

I'm confused as to how the devtool sdk-install command is supposed to 
work. Take for example:

devtool sdk-install cxxtest

This installs all the /usr/lib and /usr/include stuff into the sysroot, 
but doesn't install the /usr/bin stuff required to actually use cxxtest.

So should I install nativesdk-cxxtest instead? Still doesn't work, but I 
was just curious about the nativesdk- prefix.
cxxtest-native doesn't work either.
Does the cxxtest recipe need a SYSROOT_DIRS_append = " ${bindir}" in order 
to get the /usr/bin files installed in the eSDK when someone installs it?



PS - often devtool sdk-install  will act like it is working and 
then print an error at the end:

NOTE: Tasks Summary: Attempted 105 tasks of which 71 didn't need to be 
rerun and all succeeded.
ERROR: Failed to install nativesdk-cxxtest - unavailable



PPS - a google search for devtool sdk-install returns nothing, so 
hopefully the mailing list can help.-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Using kernel fitimage with initramfs

[Manjukumar Harthikote Matha]

Hi All,

Had a question about kernel-fitimage.bbclass. I am enabling the fitimage using 
KERNEL_CLASSES += "kernel-fitimage" and KERNEL_IMAGETYPE = "fitImage".
It works and I see fitimage in my deploy directory without any issues.

However when I enable initramfs along with fitimage, using INITRAMFS_IMAGE = 
"core-image-minimal" and  INITRAMFS_IMAGE_BUNDLE = "1", kernel build fails.
It's mostly from kernel.bbclass because it tries to deploy fitimage 
https://github.com/openembedded/openembedded-core/blob/master/meta/classes/kernel.bbclass#L639
Am I using this featurecorrectly? anyone else facing same issue?

Below is a initial patch which I did to get me across the error, but I am not 
sure if this is the correct answer.

diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index 756707a..d5342b4 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -208,14 +208,16 @@ do_bundle_initramfs () {
# Backing up kernel image relies on its type(regular file or 
symbolic link)
tmp_path=""
for type in ${KERNEL_IMAGETYPES} ; do
-   if [ -h ${KERNEL_OUTPUT_DIR}/$type ] ; then
-   linkpath=`readlink -n 
${KERNEL_OUTPUT_DIR}/$type`
-   realpath=`readlink -fn 
${KERNEL_OUTPUT_DIR}/$type`
-   mv -f $realpath $realpath.bak
-   tmp_path=$tmp_path" 
"$type"#"$linkpath"#"$realpath
-   elif [ -f ${KERNEL_OUTPUT_DIR}/$type ]; then
-   mv -f ${KERNEL_OUTPUT_DIR}/$type 
${KERNEL_OUTPUT_DIR}/$type.bak
-   tmp_path=$tmp_path" "$type"##"
+   if [ "$type" != "fitImage" ]; then
+   if [ -h ${KERNEL_OUTPUT_DIR}/$type ] ; then
+   linkpath=`readlink -n 
${KERNEL_OUTPUT_DIR}/$type`
+   realpath=`readlink -fn 
${KERNEL_OUTPUT_DIR}/$type`
+   mv -f $realpath $realpath.bak
+   tmp_path=$tmp_path" 
"$type"#"$linkpath"#"$realpath
+   elif [ -f ${KERNEL_OUTPUT_DIR}/$type ]; then
+   mv -f ${KERNEL_OUTPUT_DIR}/$type 
${KERNEL_OUTPUT_DIR}/$type.bak
+   tmp_path=$tmp_path" "$type"##"
+   fi
fi
done

use_alternate_initrd=CONFIG_INITRAMFS_SOURCE=${B}/usr/${INITRAMFS_IMAGE_NAME}.cpio
@@ -627,8 +629,10 @@ MODULE_TARBALL_DEPLOY ?= "1"

 kernel_do_deploy() {
for type in ${KERNEL_IMAGETYPES} ; do
-   base_name=${type}-${KERNEL_IMAGE_BASE_NAME}
-   install -m 0644 ${KERNEL_OUTPUT_DIR}/${type} 
${DEPLOYDIR}/${base_name}.bin
+   if [ "$type" != "fitImage" ]; then
+   base_name=${type}-${KERNEL_IMAGE_BASE_NAME}
+   install -m 0644 ${KERNEL_OUTPUT_DIR}/${type} 
${DEPLOYDIR}/${base_name}.bin
+   fi
done
if [ ${MODULE_TARBALL_DEPLOY} = "1" ] && (grep -q -i -e 
'^CONFIG_MODULES=y$' .config); then
mkdir -p ${D}/lib
@@ -637,21 +641,25 @@ kernel_do_deploy() {
fi

for type in ${KERNEL_IMAGETYPES} ; do
-   base_name=${type}-${KERNEL_IMAGE_BASE_NAME}
-   symlink_name=${type}-${KERNEL_IMAGE_SYMLINK_NAME}
-   ln -sf ${base_name}.bin ${DEPLOYDIR}/${symlink_name}.bin
-   ln -sf ${base_name}.bin ${DEPLOYDIR}/${type}
+   if [ "$type" != "fitImage" ]; then
+   base_name=${type}-${KERNEL_IMAGE_BASE_NAME}
+   symlink_name=${type}-${KERNEL_IMAGE_SYMLINK_NAME}
+   ln -sf ${base_name}.bin ${DEPLOYDIR}/${symlink_name}.bin
+   ln -sf ${base_name}.bin ${DEPLOYDIR}/${type}
+   fi
done

cd ${B}
# Update deploy directory
for type in ${KERNEL_IMAGETYPES} ; do
-   if [ -e "${KERNEL_OUTPUT_DIR}/${type}.initramfs" ]; then
-   echo "Copying deploy ${type} kernel-initramfs image and 
setting up links..."
-   initramfs_base_name=${type}-${INITRAMFS_BASE_NAME}
-   initramfs_symlink_name=${type}-initramfs-${MACHINE}
-   install -m 0644 ${KERNEL_OUTPUT_DIR}/${type}.initramfs 
${DEPLOYDIR}/${initramfs_base_name}.bin
-   ln -sf ${initramfs_base_name}.bin 
${DEPLOYDIR}/${initramfs_symlink_name}.bin
+   if [ "$type" != "fitImage" ]; then
+   if [ -e "${KERNEL_OUTPUT_DIR}/${type}.initramfs" ]; then
+   echo "Copying deploy ${type} kernel-initramfs 
image and setting up links..."
+   
initramfs_base_name=${type}-${INITRAM

Re: [yocto] How do I patch binutils for the SDK

[Khem Raj]

On Thu, Oct 12, 2017 at 06:23:03AM +, Paul D. DeRocco wrote:
> I found a bug in the GNU assembler that makes it produce corrupted
> listings, reported it on sourceware bugzilla, and it has been fixed. Now
> I'd like to take those small patches and apply them to the assembler that
> winds up in the SDK. The patches are shown here:
> 
> https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=39865a7f420ab4c
> a4dec6ed27339618a5d5dc366
> 
> The only recipe I found in Pyro that seemed appropriate was
> meta/recipes-devtools/binutils/binutils-crosssdk_2.28.bb, so I created a
> binutils-crosssdk_%.bbappend in my layer with a FILESEXTRAPATHS_prepend
> and a SRC_URI listing the patches, which I put into a binutils
> subdirectory.
> 
> When I ran the populate_sdk task, the patches failed because they didn't
> find the source files, which are supposed to be in a subdirectory called
> gas.
> 
> So I'm wondering, is this the wrong recipe? Does something else build gas?
> Or am I just doing this wrong? The workings of the build system are pretty
> opaque and mysterious.

You can apply the patch to all binutils variants, its fine. Send a patch or if 
you
want, file a ticket in bugzilla and we will take care.

> 
> -- 
> 
> Ciao,   Paul D. DeRocco
> Paulmailto:pdero...@ix.netcom.com
> 
> -- 
> ___
> 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] [meta-security][PATCH] openscape: fix ptest compile errors and update

[Armin Kuster]

update to 1.2.15

plus
ERROR: openscap-1.2.14-r0 do_package_qa: QA Issue: 
/usr/lib/openscap/ptest/tests/probes/process58/all.sh contained in package 
openscap-ptest requires /bin/bash, but no providers found in 
RDEPENDS_openscap-ptest? [file-rdeps]
ERROR: openscap-1.2.14-r0 do_package_qa: QA Issue: 
/usr/lib/openscap/ptest/tests/xmldiff.pl contained in package openscap-ptest 
requires /usr/bin/perl, but no providers found in RDEPENDS_openscap-ptest? 
[file-rdeps]
ERROR: openscap-1.2.14-r0 do_package_qa: QA Issue: 
/usr/lib/openscap/ptest/tests/nist/test_worker.py contained in package 
openscap-ptest requires /usr/bin/python2, but no providers found in 
RDEPENDS_openscap-ptest? [file-rdeps]

Signed-off-by: Armin Kuster 
---
 .../openscap/{openscap_1.2.14.bb => openscap_1.2.15.bb}   | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)
 rename meta-security-compliance/recipes-openscap/openscap/{openscap_1.2.14.bb 
=> openscap_1.2.15.bb} (94%)

diff --git 
a/meta-security-compliance/recipes-openscap/openscap/openscap_1.2.14.bb 
b/meta-security-compliance/recipes-openscap/openscap/openscap_1.2.15.bb
similarity index 94%
rename from 
meta-security-compliance/recipes-openscap/openscap/openscap_1.2.14.bb
rename to meta-security-compliance/recipes-openscap/openscap/openscap_1.2.15.bb
index 0d26959..4dacfa2 100644
--- a/meta-security-compliance/recipes-openscap/openscap/openscap_1.2.14.bb
+++ b/meta-security-compliance/recipes-openscap/openscap/openscap_1.2.15.bb
@@ -11,7 +11,7 @@ DEPENDS = "autoconf-archive pkgconfig gconf procps curl 
libxml2 rpm \
 
 DEPENDS_class-native = "autoconf-archive-native pkgconfig-native swig-native 
curl-native libxml2-native libxslt-native dpkg-native libgcrypt-native 
nss-native"
 
-SRCREV = "7a924c0eea10d05f512660192c8c4aef447801a6"
+SRCREV = "240930d42611983c65ecae16dbca3248ce130921"
 SRC_URI = "git://github.com/akuster/openscap.git;branch=oe \
file://crypto_pkgconfig.patch \
file://run-ptest \
@@ -66,6 +66,7 @@ do_install_append_class-native () {
 TESTDIR = "tests"
 
 do_compile_ptest() {
+sed -i 's:python2:python:' ${S}/${TESTDIR}/nist/test_worker.py
 echo 'buildtest-TESTS: $(check)' >> ${TESTDIR}/Makefile
 oe_runmake -C ${TESTDIR} buildtest-TESTS
 }
@@ -78,5 +79,6 @@ do_install_ptest() {
 FILES_${PN} += "${PYTHON_SITEPACKAGES_DIR}"
 
 RDEPENDS_${PN} += "libxml2 python libgcc"
+RDEPENDS_${PN}-ptest = "bash perl python"
 
 BBCLASSEXTEND = "native"
-- 
2.7.4

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

Re: [yocto] How to use two recipes to satisfy different PROVIDES -- gpu support

[Khem Raj]

On Thu, Oct 12, 2017 at 03:33:53AM +, Gutierrez, Hernan Ildefonso (Boise 
R&D, FW) wrote:
> Raj,
> 
> Thanks for the response.
> 
> Is there an example of what you mentioned below which is open source?
> 
> So far my two references have been Freescale and Mali. I found mali much 
> simpler than Freescale, however Mali GPU doesn't really have a refactor of 
> mesa, they only do a simple bbappend to mesa with 
> the PROVIDES_remove statement I stated in my original note.

you can also look at meta-raspberrypi


> 
> For reference here:  https://github.com/ARM-software/meta-mali
> 
> --Hernan
> 
> 
> 
> > -Original Message-
> > From: Khem Raj [mailto:raj.k...@gmail.com]
> > Sent: Wednesday, October 11, 2017 7:01 PM
> > To: Gutierrez, Hernan Ildefonso (Boise R&D, FW)
> > 
> > Cc: yocto 
> > Subject: Re: [yocto] How to use two recipes to satisfy different PROVIDES --
> > gpu support
> > 
> > On Wed, Oct 11, 2017 at 3:15 PM, Gutierrez, Hernan Ildefonso (Boise R&D,
> > FW)  wrote:
> > > Hi,
> > >
> > > We have a GPU in our system. We created a recipe to satisfy all the
> > dependencies for core-image-weston (virtual/egl, virtual/libgl, etc.), 
> > except
> > virtual/mesa, which is not provided by our GPU recipe.
> > >
> > > When one builds core-image-weston, the image requires mesa to build as
> > well.
> > >
> > > Our approach to satisfy dependencies is very similar to what Freescale and
> > other vendors with Mali GPU support use, which is through the following
> > statements:
> > >
> > > PREFERRED_PROVIDER_virtual/egl = "my-gpu-recipe"
> > > PREFERRED_PROVIDER_virtual/libgles1 = " my-gpu-recipe "
> > > PREFERRED_PROVIDER_virtual/libgles2 = " my-gpu-recipe "
> > > PREFERRED_PROVIDER_virtual/libgl = "my-gpu-recipe"
> > > PREFERRED_PROVIDER_virtual/mesa = "mesa"
> > >
> > > The way to remove mesa support for virtual/egl, virtual/libgles1, etc. is 
> > > by
> > adding a mesa_%.bbappend where it states explicitly to remove those
> > provides from mesa recipe.
> > >
> > > e.g.
> > > PROVIDES_remove = "virtual/libgles1 virtual/libgles2 virtual/libopenvg
> > virtual/egl"
> > >
> > >
> > > The problem I am running into is that bitbake complains stating that
> > > virtual/mesa is not satisfied (Nothing PROVIDES 'virtual/mesa')
> > >
> > > When I do bitbake-layers show-recipes, I see that mesa recipe is skipped
> > because it gave priority to my-gpu-recipe.
> > >
> > > How can two recipes be used and let bitbake satisfy parts of each recipe?
> > >
> > > Any hints will be appreciated.
> > 
> > there is no easy way to control providers once a recipe is pulled in.
> > you can refactor mesa recipe like we have done for mesa and mesa-gl which
> > will mean adding a another recipe which just builds the needed portions of
> > mesa in each recipe, if your GPU driver provides everything you need to run
> > weston, then you can let it provide everything that mesa provides and
> > bitbake wont pick up mesa at all.
> > 
> > >
> > > Thanks,
> > >
> > > --Hernan
> > > --
> > > ___
> > > 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 do I patch binutils for the SDK

[Paul D. DeRocco]

> From: Khem Raj [mailto:raj.k...@gmail.com] 
> 
> You can apply the patch to all binutils variants, its fine. 
> Send a patch or if you
> want, file a ticket in bugzilla and we will take care.

Yocto's Bugzilla isn't recognizing my password, and when it says that it's
emailed me a password change message, it doesn't show up. However, the
four small patches are in the Sourceware binutils-gdb GIT repo, at the
link I mentioned:

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=39865a7f420ab4c
a4dec6ed27339618a5d5dc366

Just to verify, my binutils-crosssdk_%.bbappend file contains:

FILESEXTRAPATHS_prepend := "${THISDIR}/binutils:"

SRC_URI = " \
file://gas_as.h.patch   \
file://gas_ChangeLog.patch  \
file://gas_input-scrub.c.patch  \
file://gas_listing.c.patch  \
"

and the patches from that Bugzilla page are in a binutils directory. The
errors I get indicate that the patches are being attempted, but aren't
matching up with any source files.

-- 

Ciao,   Paul D. DeRocco
Paulmailto:pdero...@ix.netcom.com


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

Re: [yocto] How do I patch binutils for the SDK

[Khem Raj]

On Thu, Oct 12, 2017 at 8:52 PM, Paul D. DeRocco  wrote:
>> From: Khem Raj [mailto:raj.k...@gmail.com]
>>
>> You can apply the patch to all binutils variants, its fine.
>> Send a patch or if you
>> want, file a ticket in bugzilla and we will take care.
>
> Yocto's Bugzilla isn't recognizing my password, and when it says that it's
> emailed me a password change message, it doesn't show up. However, the
> four small patches are in the Sourceware binutils-gdb GIT repo, at the
> link I mentioned:
>
> https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=39865a7f420ab4c
> a4dec6ed27339618a5d5dc366
>
> Just to verify, my binutils-crosssdk_%.bbappend file contains:
>
> FILESEXTRAPATHS_prepend := "${THISDIR}/binutils:"
>
> SRC_URI = " \
> file://gas_as.h.patch   \
> file://gas_ChangeLog.patch  \
> file://gas_input-scrub.c.patch  \
> file://gas_listing.c.patch  \
> "
>

you can just make 1 patch download

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commitdiff_plain;h=39865a7f420ab4ca4dec6ed27339618a5d5dc366;hp=fe22022617a7122491aa83c893a10a8d861cde73

and delete the hunk which contains changeslog entry and rest should apply
cleanly. And add it to SRC_URI in binutils-2.29.inc

> and the patches from that Bugzilla page are in a binutils directory. The
> errors I get indicate that the patches are being attempted, but aren't
> matching up with any source files.
>
> --
>
> Ciao,   Paul D. DeRocco
> Paulmailto:pdero...@ix.netcom.com
>
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] How do I patch binutils for the SDK

[Paul D. DeRocco]

> From: Khem Raj [mailto:raj.k...@gmail.com] 
> 
> you can just make 1 patch download
> 
> https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=com
mitdiff_plain;h=> 
39865a7f420ab4ca4dec6ed27339618a5d5dc366;hp=fe22022617a7122491aa83c893a10a8d861cde73
> 
> and delete the hunk which contains changeslog entry and rest 
> should apply
> cleanly. And add it to SRC_URI in binutils-2.29.inc

That didn't change anything. (Pyro is using 2.28, BTW.)

The crosssdk recipe is built in 
x86_64-linux/binutils-crosssdk-x86_64-pokysdk-linux/2.28-r0/git. All I see in 
there are a couple of quilt directories containing my patch files, no source 
files. So I decided to run a devshell. Since that doesn't happen until after 
the patches are supplied, that failed, too. So I removed the .bbappend and ran 
the devshell. There they were, a half-bazillion nice source files, including 
the gas directory. So I put the .bbappend back and ran the devshell again, and 
the first thing it did was clean that directory, after which the patches failed 
again.

I have no clue how this build system works. Is the source directory supposed to 
be where the files are patched? What cleans the source directory? I notice that 
after any build, there never seem to be any source files hanging around.

-- 

Ciao,   Paul D. DeRocco
Paulmailto:pdero...@ix.netcom.com

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

Re: [yocto] How do I patch binutils for the SDK

[John Ernberg]

On 10/13/2017 05:52 AM, Paul D. DeRocco wrote:
>> From: Khem Raj [mailto:raj.k...@gmail.com]
>>
>> You can apply the patch to all binutils variants, its fine.
>> Send a patch or if you
>> want, file a ticket in bugzilla and we will take care.
> Yocto's Bugzilla isn't recognizing my password, and when it says that it's
> emailed me a password change message, it doesn't show up. However, the
> four small patches are in the Sourceware binutils-gdb GIT repo, at the
> link I mentioned:
>
> https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=39865a7f420ab4c
> a4dec6ed27339618a5d5dc366
>
> Just to verify, my binutils-crosssdk_%.bbappend file contains:
>
> FILESEXTRAPATHS_prepend := "${THISDIR}/binutils:"
>
> SRC_URI = " \
Looks like you're overriding SRC_URI instead of appending it. Try with 
'+=' instead of just '='.
>  file://gas_as.h.patch   \
>  file://gas_ChangeLog.patch  \
>  file://gas_input-scrub.c.patch  \
>  file://gas_listing.c.patch  \
>  "
>
> and the patches from that Bugzilla page are in a binutils directory. The
> errors I get indicate that the patches are being attempted, but aren't
> matching up with any source files.
>
// John
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] How do I patch binutils for the SDK

[Paul D. DeRocco]

> From: John Ernberg
> 
> Looks like you're overriding SRC_URI instead of appending it. 

I had a feeling I was doing something dumb. Thanks.

-- 

Ciao,   Paul D. DeRocco
Paulmailto:pdero...@ix.netcom.com

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

[yocto] Yocto Project Developer Day at ELCE in Prague

[Jeff Osier-Mixon]

The Yocto Project is a Bronze sponsor of the Embedded Linux Conference in
Prague, starting on 23 October, and we also provide a conference add-on as
we have for the past several years - Yocto Project Developer Day.

DevDay is an inexpensive one-day event that enables you to learn about the
project in either the Introductory track, a detailed technical introduction
to the project taught by Linux Foundation professional trainers, or the
Advanced track, a collection of intermediate and advanced level hands-on
presentations taught by maintainers and other principals in the Yocto
Project. This day is a chance for intensive training as well as one-on-one
contact with the developers who create and maintain the Yocto Project.

In addition, each attendee will receive a development board, with three to
choose from. Lunch is provided.

For more details and a link to register, see the DevDay page at

https://www.yoctoproject.org/devday

Even if you don't attend DevDay, be sure to stop and say hello at the booth
at ELCE!

-- 
Jeff Osier-Mixon - Open Source Community Manager, Intel Corporation
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto