Re: [yocto] [meta-raspberrypi][PATCH 2/2] linux-raspberrypi: build audio driver into kernel

[Alex J Lennon]

On 25/08/2015 07:57, Petter Mabäcker wrote:
>  
> 
> 2015-08-17 11:23 skrev Alex J Lennon:
> 
>> On 17/08/2015 09:11, Petter Mabäcker wrote:
>>> 2015-08-17 09:57 skrev Andrei Gherzan:
 Hello, On Tuesday, August 11, 2015, Petter Mabäcker
 mailto:pet...@technux.se>
 >> wrote:
 2015-08-11 19:04 skrev Alex J Lennon: Signed-off-by: Alex J Lennon
 >>> > ---
 recipes-kernel/linux/linux-raspberrypi.inc | 4  1 file changed,
 4 insertions(+) diff --git
 a/recipes-kernel/linux/linux-raspberrypi.inc
 b/recipes-kernel/linux/linux-raspberrypi.inc index e38d905..8024412
 100644 --- a/recipes-kernel/linux/linux-raspberrypi.inc +++
 b/recipes-kernel/linux/linux-raspberrypi.inc @@ -6,6 +6,10 @@
 SECTION = "kernel" LICENSE = "GPLv2" LIC_FILES_CHKSUM =
 "file://COPYING;md5=d7810fab7487fb0aad327b76f1be7cd7" +SRC_URI += "
 \ + file://build-in-audio.cfg \ + " This one didn't make it. --
 Andrei Gherzan -- -- Andrei Gherzan
>>> Think you got the wrong receiver =) I notified Alex about this some
>>> days ago, Alex can you send up a v2 for this?
>> The build-in-audio.cfg patch was just for testing of fragment support.
>> It's understood that we're not going to have this build into the kernel
>> by default, although I do still need to find some words to add to the
>> README on audio routing setup and so forth.
>>
>> I started testing a build with master over the weekend and it built OK.
>> Just need to find some time to run up a couple of kernels and will
>> resubmit the v2 patch with Petter's enhanced commit message.
>>
>> I don't have an RPiv1 around at the moment but I will probably double
>> check the kernel does still actually build for RPiv1 machine
>>
>> Cheers,
>>
>> Alex
>>> BR, Petter
> 
> Hi Alex, Any news for the v2 changeset? Would be awesome to get the 4.x
> integrated soon.
>

Hi, yeah I got a little sidetracked I'm afraid. Turns out
core-image-sato isn't building in master any more due to a new
dependency on libexpoxy which in turn requires EGL.

Anyway, so I did successfully build 4.x and 3.x kernels for RPiv2 in an
rpi-xxx-image. I just didn't get around to running them up although I
see no reason to think they won't.

I'll try to take a look at this, as I like you would like this signed off :)

Cheers, Alex

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

[yocto] Clang cross compiler with OpenEmbedded

[Khem Raj]

Hi all

We have put together clang as system cross compiler support into OpenEmbedded, 
here is a writeup on how to use it
in your setups.

http://himvis.com/using-clang-with-openembeddedyocto-project/

At present, it is able to compile a lot of packages already and 
core-image-minimal when build mixed with clang and gcc
boots fine on qemux86 and rpi2, I have not tested ppc and mips images yet but 
build wise a lot of packages can be build for ppc/mips too.

Interested ? then please come on board and help porting the packages to work 
with clang

if you find issues or have questions please feel free to send them my way

Thanks
-Khem



signature.asc
Description: Message signed with OpenPGP using GPGMail
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [meta-cgl][PATCH] README: updated maintainers and general content accordingly

[Alexandru . Vaduva]

From: alex 

Signed-off-by: Alexandru.Vaduva 
---
 README | 23 +++
 1 file changed, 7 insertions(+), 16 deletions(-)

diff --git a/README b/README
index d25fb0b..7d48b4c 100644
--- a/README
+++ b/README
@@ -44,7 +44,9 @@ http://git.yoctoproject.org/git/meta-cgl
 Maintenance
 ===
 
-Maintainers: Enea Linux Team 
+Maintainers:
+Alexandru Vaduva 
+Joe MacDonald 
 
 
 Contributing
@@ -61,6 +63,7 @@ here: 
https://wiki.yoctoproject.org/wiki/Contribution_Guidelines
 example:
 git send-email -1 -M --to yocto@yoctoproject.org  
--subject-prefix=meta-cgl][PATCH
 
+
 Table of Contents
 =
 
@@ -84,12 +87,13 @@ other layers needed. Adapt the below list to proper format.
   BBLAYERS:
 
 meta
-meta-cgl
+meta-cgl/meta-cgl-common
 meta-qt3
 meta-openembedded/meta-networking
 meta-openembedded/meta-filesystems
 meta-openembedded/meta-oe
 meta-openembedded/meta-perl
+meta-openembedded/meta-python
 meta-yocto
 meta-yocto-bsp
 meta-virtualization
@@ -105,6 +109,7 @@ Now there is available the "cgl-init-build-env" script 
which could be used to
 automize the above mentione information:
 ./scripts/cgl-checkout -b master -l meta-fsl-ppc
 
+
 II. Misc
 
 
@@ -139,17 +144,3 @@ or programming language operations required in the 
application system at
 a later stage.
 Interface - shared boundary or connection between two dissimilar
 objects, devices or systems.
-
-Users of this layer might experience a problem with openipmi package, if 
this happens then this
-package can be removed from packagegroup-cgl-middleware.bb package group and 
exclude it from the
-image used for building a CGL compliant image.
-The latest tested head for the depending layers were:
-poky:   bb00d83675a1293ee8d7a3ac22cf01243fa2397b
-meta-cloud-services:a06e28ced8f622dbe6d6fbd9bea20b215d8ac938
-meta-openclovis:83b1f76a75266743dc9eb0238039d5b973ad8ac0
-meta-qt3:   3016129d90b7ac8517a5227d819f10ad417b5b45
-meta-security:  b3f08c7b2bdf1bea28b081319d7c135af45f39e3
-meta-selinux:   1699b56fd801f0194b708b4a1d9d95a831a3bbe4
-meta-virtualization:b94455174264240bf8519e4148ea5f1fb38d55c6
-The machine for which this layer was tested are: 'qemuppc' and 'p2020rdb'. 
The latest tested head
-for meta-fsl-ppc layer is:  d953212ae5936a7d969d13801b0c2c1eb65cee6f
-- 
1.9.1

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

Re: [yocto] [meta-cgl][PATCH] README: updated maintainers and general content accordingly

[Joe MacDonald]

Acked-by: Joe MacDonald 

[[meta-cgl][PATCH] README: updated maintainers and general content accordingly] 
On 15.08.25 (Tue 14:00) Alexandru.Vaduva wrote:

> Signed-off-by: Alexandru.Vaduva 
> 
> Author:Alexandru.Vaduva 
> Signed-off-by: Alexandru.Vaduva 
> ---
>  README | 24 
>  1 file changed, 8 insertions(+), 16 deletions(-)
> 
> diff --git a/README b/README
> index d25fb0b..9f6713c 100644
> --- a/README
> +++ b/README
> @@ -44,7 +44,10 @@ http://git.yoctoproject.org/git/meta-cgl
>  Maintenance
>  ===
>  
> -Maintainers: Enea Linux Team 
> +Maintainers:
> +Adrian Dudau 
> +Alexandru Vaduva 
> +Joe MacDonald 
>  
>  
>  Contributing
> @@ -61,6 +64,7 @@ here: 
> https://wiki.yoctoproject.org/wiki/Contribution_Guidelines
>  example:
>  git send-email -1 -M --to yocto@yoctoproject.org  
> --subject-prefix=meta-cgl][PATCH
>  
> +
>  Table of Contents
>  =
>  
> @@ -84,12 +88,13 @@ other layers needed. Adapt the below list to proper 
> format.
>BBLAYERS:
>  
>  meta
> -meta-cgl
> +meta-cgl/meta-cgl-common
>  meta-qt3
>  meta-openembedded/meta-networking
>  meta-openembedded/meta-filesystems
>  meta-openembedded/meta-oe
>  meta-openembedded/meta-perl
> +meta-openembedded/meta-python
>  meta-yocto
>  meta-yocto-bsp
>  meta-virtualization
> @@ -105,6 +110,7 @@ Now there is available the "cgl-init-build-env" script 
> which could be used to
>  automize the above mentione information:
>  ./scripts/cgl-checkout -b master -l meta-fsl-ppc
>  
> +
>  II. Misc
>  
>  
> @@ -139,17 +145,3 @@ or programming language operations required in the 
> application system at
>  a later stage.
>  Interface - shared boundary or connection between two dissimilar
>  objects, devices or systems.
> -
> -Users of this layer might experience a problem with openipmi package, if 
> this happens then this
> -package can be removed from packagegroup-cgl-middleware.bb package group and 
> exclude it from the
> -image used for building a CGL compliant image.
> -The latest tested head for the depending layers were:
> -poky:   bb00d83675a1293ee8d7a3ac22cf01243fa2397b
> -meta-cloud-services:a06e28ced8f622dbe6d6fbd9bea20b215d8ac938
> -meta-openclovis:83b1f76a75266743dc9eb0238039d5b973ad8ac0
> -meta-qt3:   3016129d90b7ac8517a5227d819f10ad417b5b45
> -meta-security:  b3f08c7b2bdf1bea28b081319d7c135af45f39e3
> -meta-selinux:   1699b56fd801f0194b708b4a1d9d95a831a3bbe4
> -meta-virtualization:b94455174264240bf8519e4148ea5f1fb38d55c6
> -The machine for which this layer was tested are: 'qemuppc' and 
> 'p2020rdb'. The latest tested head
> -for meta-fsl-ppc layer is:  d953212ae5936a7d969d13801b0c2c1eb65cee6f
-- 
-Joe MacDonald.
:wq


signature.asc
Description: Digital signature
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] building external modules

[Pierre Yves MORDRET]

Hello,

I have a sporadic compilation issue for a while and I never found out so far 
where it came from until now (perhaps). 
I mean by sporadic that it happens "sometimes" (2% of a time) 
I'm using daisy branch and the build failure happens in a Kernel External. It 
ends up like this:

DEBUG: Executing shell function do_compile
NOTE: make -j 24 -e ...  -C /usr/src/kernel O=/usr/src/kernel 
KBUILD_VERBOSE=1 M= ... modules
   [...]
   arm-rdk-linux-gnueabi-ld -EL-r -o .o [...] ; scripts/mod/modpost 
.o
  /bin/sh: scripts/mod/modpost: Permission denied

Looking at logs and bbclass, I've seen a "make 
scripts"(module.bbclass/do_make_scripts) is issued anytime we build a Kernel 
External module.
Even if there is a "lock" mechanism to prevent race condition during this 
"do_make_scripts", nothing prevent to call "do_make_scripts" from a Ext Mod 1 
during a "do_compile" from a Ext Mod 2.

I think (but not sure) this is another race condition here.
Do I miss something ?

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

Re: [yocto] Packages in packagegroup are not installed in image

[Randy Witt]

On 08/24/2015 07:20 PM, Ng, Mei Yeen wrote:

Hi Randy,

The packagegroups is added into the image as below:

1) Create a bbappend of the image core-image-full-cmdline.bbappend in our new 
layer
2) In the core-image-full-cmdline.bbappend, enable the following lines:

DESCRIPTION = "Custom list of packages for build essentials for commandline 
image"

IMAGE_INSTALL += "packagegroup-core-buildessential-extended"
IMAGE_INSTALL += "packagegroup-core-devtools"


Could you try using _append like below, and see if that gives you the 
consistency you want?


IMAGE_INSTALL_append = " packagegroup-core-buildessential-extended"
IMAGE_INSTALL_append = " packagegroup-core-devtools"


3) Update the local.conf to include EXTRA_IMAGE_FEATURES = "debug-tweaks 
tools-testapps tools-debug"

Thanks,
MY

-Original Message-
From: Randy Witt [mailto:randy.e.w...@linux.intel.com]
Sent: Friday, July 24, 2015 2:00 AM
To: Ng, Mei Yeen; yocto@yoctoproject.org
Cc: Hart, Darren; Witt, Randy E
Subject: Re: [yocto] Packages in packagegroup are not installed in image

Hi Mei,

On 07/15/2015 10:40 AM, Ng, Mei Yeen wrote:

Hi,

I need help for issue where packages in packagegroup that compiles perfectly 
fine with core-images, but when verified in the image, they are not installed 
for some reason.
My understanding was that packages listed under RDEPENDS in the packagegroup 
would get compiled and installed.

Some packages would appear in 1 image and then disappear in the next compiled 
image.
I'm seeing this when compiling with core-image-full-cmdline and core-image-sato.

I have attached the following package group created:

-graphics package group- ldd would not be installed in the image

-build essentials extended package group - gdb were not install, gcc 
and mkdosfs will intermittently not install into the image


Could you perhaps provide the recipe that creates the package group and show 
how you are adding the package group to the image?


Any help to shed some light on this is very much appreciated.

Thanks,
MY







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

[yocto] [PATCH] CheckforGPLv3: Improve find/grep check

[Saul Wold]

Add additional information to help determine what is reporting
the GPLv3 if there is a match

Signed-off-by: Saul Wold 
---
 lib/python2.7/site-packages/autobuilder/buildsteps/CheckForGPLv3.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git 
a/lib/python2.7/site-packages/autobuilder/buildsteps/CheckForGPLv3.py 
b/lib/python2.7/site-packages/autobuilder/buildsteps/CheckForGPLv3.py
index 0cc5b2c..ace6473 100644
--- a/lib/python2.7/site-packages/autobuilder/buildsteps/CheckForGPLv3.py
+++ b/lib/python2.7/site-packages/autobuilder/buildsteps/CheckForGPLv3.py
@@ -28,7 +28,7 @@ class CheckForGPLv3(ShellCommand):
 ShellCommand.__init__(self, **kwargs)
 
 def start(self):
-self.command = 'for x in `find ./build/tmp/deploy/licenses -name 
"license.manifest"`; do cat $x|grep GPLv3; done'
+self.command = 'find ./build/tmp/deploy/licenses -name 
"license.manifest" -exec grep -H -B1 GPLv3 {} \\;'
 self.description = ["Checking to ensure no GPLv3 packages"]
 ShellCommand.start(self)
 
-- 
2.1.0

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

Re: [yocto] [PATCH] CheckforGPLv3: Improve find/grep check

[Khem Raj]

> On Aug 25, 2015, at 3:27 PM, Saul Wold  wrote:
> 
> Add additional information to help determine what is reporting
> the GPLv3 if there is a match
> 
> Signed-off-by: Saul Wold 
> ---
> lib/python2.7/site-packages/autobuilder/buildsteps/CheckForGPLv3.py | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git 
> a/lib/python2.7/site-packages/autobuilder/buildsteps/CheckForGPLv3.py 
> b/lib/python2.7/site-packages/autobuilder/buildsteps/CheckForGPLv3.py
> index 0cc5b2c..ace6473 100644
> --- a/lib/python2.7/site-packages/autobuilder/buildsteps/CheckForGPLv3.py
> +++ b/lib/python2.7/site-packages/autobuilder/buildsteps/CheckForGPLv3.py
> @@ -28,7 +28,7 @@ class CheckForGPLv3(ShellCommand):
> ShellCommand.__init__(self, **kwargs)
> 
> def start(self):
> -self.command = 'for x in `find ./build/tmp/deploy/licenses -name 
> "license.manifest"`; do cat $x|grep GPLv3; done'
> +self.command = 'find ./build/tmp/deploy/licenses -name 
> "license.manifest" -exec grep -H -B1 GPLv3 {} \\;'

how about GPL-3.0 and LGPL-3.0 will that be caught ?

> self.description = ["Checking to ensure no GPLv3 packages"]
> ShellCommand.start(self)
> 
> --
> 2.1.0
> 
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto



signature.asc
Description: Message signed with OpenPGP using GPGMail
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [meta-cgl][PATCH] README: updated maintainers and general content accordingly

[Alexandru . Vaduva]

Signed-off-by: Alexandru.Vaduva 

Author:Alexandru.Vaduva 
Signed-off-by: Alexandru.Vaduva 
---
 README | 24 
 1 file changed, 8 insertions(+), 16 deletions(-)

diff --git a/README b/README
index d25fb0b..9f6713c 100644
--- a/README
+++ b/README
@@ -44,7 +44,10 @@ http://git.yoctoproject.org/git/meta-cgl
 Maintenance
 ===
 
-Maintainers: Enea Linux Team 
+Maintainers:
+Adrian Dudau 
+Alexandru Vaduva 
+Joe MacDonald 
 
 
 Contributing
@@ -61,6 +64,7 @@ here: 
https://wiki.yoctoproject.org/wiki/Contribution_Guidelines
 example:
 git send-email -1 -M --to yocto@yoctoproject.org  
--subject-prefix=meta-cgl][PATCH
 
+
 Table of Contents
 =
 
@@ -84,12 +88,13 @@ other layers needed. Adapt the below list to proper format.
   BBLAYERS:
 
 meta
-meta-cgl
+meta-cgl/meta-cgl-common
 meta-qt3
 meta-openembedded/meta-networking
 meta-openembedded/meta-filesystems
 meta-openembedded/meta-oe
 meta-openembedded/meta-perl
+meta-openembedded/meta-python
 meta-yocto
 meta-yocto-bsp
 meta-virtualization
@@ -105,6 +110,7 @@ Now there is available the "cgl-init-build-env" script 
which could be used to
 automize the above mentione information:
 ./scripts/cgl-checkout -b master -l meta-fsl-ppc
 
+
 II. Misc
 
 
@@ -139,17 +145,3 @@ or programming language operations required in the 
application system at
 a later stage.
 Interface - shared boundary or connection between two dissimilar
 objects, devices or systems.
-
-Users of this layer might experience a problem with openipmi package, if 
this happens then this
-package can be removed from packagegroup-cgl-middleware.bb package group and 
exclude it from the
-image used for building a CGL compliant image.
-The latest tested head for the depending layers were:
-poky:   bb00d83675a1293ee8d7a3ac22cf01243fa2397b
-meta-cloud-services:a06e28ced8f622dbe6d6fbd9bea20b215d8ac938
-meta-openclovis:83b1f76a75266743dc9eb0238039d5b973ad8ac0
-meta-qt3:   3016129d90b7ac8517a5227d819f10ad417b5b45
-meta-security:  b3f08c7b2bdf1bea28b081319d7c135af45f39e3
-meta-selinux:   1699b56fd801f0194b708b4a1d9d95a831a3bbe4
-meta-virtualization:b94455174264240bf8519e4148ea5f1fb38d55c6
-The machine for which this layer was tested are: 'qemuppc' and 'p2020rdb'. 
The latest tested head
-for meta-fsl-ppc layer is:  d953212ae5936a7d969d13801b0c2c1eb65cee6f
-- 
1.9.1

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

Re: [yocto] [oe] Clang cross compiler with OpenEmbedded

[Khem Raj]

Hi Roman

> On Aug 25, 2015, at 3:52 AM, Roman Khimov  wrote:
> 
> В письме от 25 августа 2015 01:03:07 пользователь Khem Raj написал:
>> We have put together clang as system cross compiler support into
>> OpenEmbedded, here is a writeup on how to use it in your setups.
>> 
>> http://himvis.com/using-clang-with-openembeddedyocto-project/
> 
> Do you have any plans to support scan-build analysis?

Yes but its in back burners so patches are welcome! I do use scan-build with 
some native application
projects but thats very simple setup to have.
I think it should be easy enough to add a class to insert the static analysis
given we can configure clang as cross compiler,

Right now my priorities are to use subset of arches e.g. x86/arm

1. Fix compile issues for OE-Core, reach to a point where all packages can 
build we have around 40 failing in world builds
2. Start using compiler-rt and libc++ to provide compiler c/c++ runtime
3. Repeat 1 to 2 with musl
4. Repeat 1 to 3 for remaining architectures
5. Start using other tools e.g. lldb, native linker and integrated as system 
wide

So this can take a while.

> 
> We have had one in Altell but with a gross hack (and even that based on OE
> classic) --- we'd built native clang and then used a special task between
> configure and compile stages that copied its script (run.do_scanbuild) into
> another one, mangled it heavily to override $CC and $CXX, and after that ran
> that script under scan-build (with --use-cc and --use-c++ pointing to the
> proper GCC toolchain), then reconfigured again for normal build.
> 
> That worked with some exceptions and allowed us to make static analysis of our
> whole build, but it was kludgy and not that efficient. I guess that with a
> proper cross-compiling Clang toolchain things could be done way more easily
> right at the compile stage.



signature.asc
Description: Message signed with OpenPGP using GPGMail
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [PATCH][meta-virtualization] openvsitch: set CONFIGUREOPT_DEPTRACK to empty

[rongqing.li]

From: Roy Li 

compilation failed since the needed dirs maybe not created when make
".in" target, fix it by creating the needed dirs before, but mainstream
thinks the needed dirs should be created when do configuration.
at last, find CONFIGUREOPT_DEPTRACK disable the creation, so empty
it
http://openvswitch.org/pipermail/dev/2015-August/059189.html

set CONFIGUREOPT_DEPTRACK to empty, is lower effective, but harmless,
and can fix the parallel building issue;
see oe-core 970e0ae6108[autotools: Disable dependency tracking

Signed-off-by: Roy Li 
---
 recipes-networking/openvswitch/openvswitch.inc | 1 +
 1 file changed, 1 insertion(+)

diff --git a/recipes-networking/openvswitch/openvswitch.inc 
b/recipes-networking/openvswitch/openvswitch.inc
index 58c8352..454aadf 100644
--- a/recipes-networking/openvswitch/openvswitch.inc
+++ b/recipes-networking/openvswitch/openvswitch.inc
@@ -39,6 +39,7 @@ EXTRA_OECONF += "\
TARGET_PYTHON=${bindir}/python \
TARGET_PERL=${bindir}/perl \
"
+CONFIGUREOPT_DEPTRACK = ""
 
 # Don't compile kernel modules by default since it heavily depends on
 # kernel version. Use the in-kernel module for now.
-- 
1.9.1

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