Re: [yocto] [meta-selinux][PATCH] attr: fix ptest failures when selinux enabled

[Kang Kai]

On 2017年09月05日 16:54, kai.k...@windriver.com wrote:

From: Kai Kang 

When selinux is enabled, a file has a default attribute
"security.selinux" and the output of getfattr shows:

   # file: here
   security.selinux="system_u:object_r:lib_t:s0"

That always causes more output of command getfattr than expected.


Ping.


--Kai



Filter out selinux related attribute info, and if the file has only
selinux attribute info, remove its whole output.

Signed-off-by: Kai Kang 
---
  .../fix-ptest-failures-when-selinux-enabled.patch  | 41 ++
  recipes-support/attr/attr_%.bbappend   |  5 +++
  2 files changed, 46 insertions(+)
  create mode 100644 
recipes-support/attr/attr/fix-ptest-failures-when-selinux-enabled.patch
  create mode 100644 recipes-support/attr/attr_%.bbappend

diff --git 
a/recipes-support/attr/attr/fix-ptest-failures-when-selinux-enabled.patch 
b/recipes-support/attr/attr/fix-ptest-failures-when-selinux-enabled.patch
new file mode 100644
index 000..e1eefa7
--- /dev/null
+++ b/recipes-support/attr/attr/fix-ptest-failures-when-selinux-enabled.patch
@@ -0,0 +1,41 @@
+Upstream-Status: Pending
+
+When enable selinux, file has a default attribute:
+
+# file: here
+security.selinux="system_u:object_r:lib_t:s0"
+
+That cause there is always more output than expected.
+
+Filter out selinux related attribute info to make ptest pass.
+
+Signed-off-by: Kai Kang 
+---
+diff --git a/test/run b/test/run
+index cf15252..945741e 100755
+--- a/test/run
 b/test/run
+@@ -132,6 +132,23 @@ sub process_test() {
+print "[$prog_line] \$ ", join(' ',
+  map { s/\s/\\$&/g; $_ } @$p), " -- ";
+my $result = exec_test($prog, $in);
++
++   # filter selinux related attributes info
++   my @strip1;
++   my @strip2;
++   foreach (@$result) {
++   unless (/security.selinux=.*\n/) {
++   push @strip1, $_;
++   }
++   }
++   for (my $i = 0; $i <= $#strip1; $i++) {
++   if ($strip1[$i] =~ /^# file:.*/ && $strip1[$i+1] =~ /^\n$/) {
++   $i++;
++   } else {
++   push @strip2, $strip1[$i];
++   }
++   }
++   $result = \@strip2;
+my @good = ();
+my $nmax = (@$out > @$result) ? @$out : @$result;
+for (my $n=0; $n < $nmax; $n++) {
diff --git a/recipes-support/attr/attr_%.bbappend 
b/recipes-support/attr/attr_%.bbappend
new file mode 100644
index 000..6be8191
--- /dev/null
+++ b/recipes-support/attr/attr_%.bbappend
@@ -0,0 +1,5 @@
+inherit selinux
+
+FILESEXTRAPATHS_prepend := "${THISDIR}/${BPN}:"
+
+SRC_URI += "${@target_selinux(d, 
'file://fix-ptest-failures-when-selinux-enabled.patch')}"



--
Regards,
Neil | Kai Kang

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

[yocto] Release Candidate Build for yocto-2.3.2.rc1 now available.

[Poky Build User]

A release candidate build for yocto-2.3.2.rc1 is now available at:


http://autobuilder.yoctoproject.org/pub/releases/yocto-2.3.2.rc1


Please begin QA on this build as soon as possible.


Build hash information: 
meta-intel : 16aea09d224f3ed2021623d17c3e807f4b8ff18d 
meta-qt4 : 88989ae3abe98b30089e7518d3adabe990c40a10 
refkit : 5014798878609ca828806ef3b826ab86ab4b2ba7 
meta-mingw : 4bdb99650a053f254ccd158a6d0c25c80e79f6ee 
meta-qt3 : f33b73a9563f2dfdfd0ee37b61d65d90197a456f 
meta-gplv2 : 07e5dd2136a2a7cc069ad8c70bb422fa9d5b14f0 
poky : ce26a57e04ad65c02087629701d96448a44e73d5 


This is an automated message from
The Yocto Project Autobuilder
Git: git://git.yoctoproject.org/yocto-autobuilder
Email: joshua.g.l...@intel.com 
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [opkg-devel] [opkg-utils PATCH] opkg-build*: fix empty package name in error message

[Alejandro del Castillo]

merged, thanks!

On 09/02/2017 11:23 AM, Adam Trhon wrote:
> When opkg-build detects illegal character in package name it prints an error
> message with this name. Due to a wrong variable name the package name in the
> error message is empty. The same error occurs in opkg-buildpackage as well.
> This patch fixes both.
> 
> Signed-off-by: Adam Trhon 
> ---
>  opkg-build| 2 +-
>  opkg-buildpackage | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/opkg-build b/opkg-build
> index e02eaca..0fe513a 100755
> --- a/opkg-build
> +++ b/opkg-build
> @@ -108,7 +108,7 @@ You probably want to chown these to a system user: " >&2
>   [ "$?" -ne 0 ] && PKG_ERROR=1
>  
>   if echo $pkg | grep '[^a-z0-9.+-]'; then
> - echo "*** Error: Package name $name contains illegal 
> characters, (other than [a-z0-9.+-])" >&2
> + echo "*** Error: Package name $pkg contains illegal characters, 
> (other than [a-z0-9.+-])" >&2
>   PKG_ERROR=1;
>   fi
>  
> diff --git a/opkg-buildpackage b/opkg-buildpackage
> index 719c9a5..b7c0e8c 100755
> --- a/opkg-buildpackage
> +++ b/opkg-buildpackage
> @@ -66,7 +66,7 @@ pkg_appears_sane_control() {
>   required_field Description >/dev/null
>  
>   if echo $pkg | grep '[^a-z0-9.+-]'; then
> - echo "opkg-build: Error: Package name $name contains illegal 
> characters, (other than [a-z0-9.+-])"
> + echo "opkg-build: Error: Package name $pkg contains illegal 
> characters, (other than [a-z0-9.+-])"
>   PKG_ERROR=1;
>   fi
>  
> 

-- 
Cheers,

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

Re: [yocto] Can yocto build a QEMU image to run under MS Windows ?

[Gutierrez, Hernan Ildefonso (Boise R&D, FW)]

Hi,

I figured that I can directly download QEMU for windows and use in a MS Windows 
box.

Downloads of Qemu for MS Windows:

For windows 64 bits: https://qemu.weilnetz.de/w64/
For Windows 32 bits: https://qemu.weilnetz.de/

I just need to match the QEMU version that Yocto is using under linux so I can 
directly pass kernel/rootfs generated by yocto and Qemu can boot as when one 
runs runqemu  under yocto.

--Hernan



From: yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org] On 
Behalf Of Gutierrez, Hernan Ildefonso (Boise R&D, FW)
Sent: Wednesday, September 06, 2017 3:28 PM
To: yocto@yoctoproject.org
Subject: [yocto] Can yocto build a QEMU image to run under MS Windows ?

Hi,

As the subject states, I am looking to see if Yocto can build a qemu image to 
run under MS windows.

I have used the standard qemuarm/qemuarm64 MACHINES as defined in default 
recipes to run under linux, but I wonder if there is a recipe to build qemu 
which I can deploy to MS windows boxes.

Any pointers will help.

Thanks!

--Hernan Gutierrez

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

Re: [yocto] [meta-xilinx] How to include Xilinx DMA driver

[Fan Zhang]

Hi all

Thank you Robert for the guide. I tried option [1] out of tree driver. 
Got it compiled, and loaded when image boot up. My understand of the dma 
driver is that Linux DMA engine depends on the Xilinx device driver 
(xilinx_cdma.c) and then dma_proxy.c driver depends on the Linux DMA 
engine. Am I correct?


It does seems Xilinx_cdma is loaded succefully, but dmatest didn't. Here 
is the message I've got:



root@microzed-zynq7:~# dmesg | grep dma
[    0.202348] dma-pl330 f8003000.dmac: Loaded driver for PL330 DMAC-241330
[    0.202370] dma-pl330 f8003000.dmac: DBUFF-128x8bytes 
Num_Chans-8 Num_Peri-4 Num_Events-16

[    0.202654] xilinx-vdma 7e20.dma: failed to get axi_clk (4294967294)
[    0.202679] xilinx-vdma: probe of 7e20.dma failed with error -2
[    2.609417] xilinx-cdma 7e20.dma: Xilinx AXI CDMA Engine driver 
Probed!!

[    2.635552] Modules linked in: axidmatest(O+) xilinx_cdma(O)
[    2.659271] PC is at xilinx_axidmatest_probe+0xd8/0x418 [axidmatest]
[    2.916646] [] (xilinx_axidmatest_probe [axidmatest]) from 
[] (platform_drv_probe+0x50/0xb0)
[    3.028812] udevd[674]: worker [687] failed while handling 
'/devices/soc0/dmatest@0'


From these message, I'm guessing there is an issue in configuration of 
the common clock framework. Is the clkc.c needs to be built as an out of 
tree module to be used in Yocto?


Fan

On 08/09/2017 12:20 PM, Robert Berger wrote:

Hi,

On 2017-09-08 19:00, Fan Zhang wrote:

Hi All,

1. How to include xilinx_dma.c driver in to the poky image build?


In case you want to include out-of tree drivers it could work like 
this[1] in case you want in-tree it's just a kernel patch similar to[2].


Apparently you will need to turn on kernel config features. You might 
try something like this[3].


For Yocto/Xilinx specific questions you might want to ask on the 
Xilinx mailing list[4].


[1] 
https://github.com/RobertBerger/meta-mainline/tree/pyro-training-v4.9.x/multi-v7-ml/recipes-zedboard/xilinx-dma


[2] 
https://github.com/RobertBerger/meta-mainline/blob/pyro-training-v4.9.x/multi-v7-ml/recipes-kernel/linux/patch/4.9.x/patches/zedboard-zynq7/zynq-qspi/0001-zynq-zedboard-non-mainline-qspi-support.patch


[3] 
https://github.com/RobertBerger/meta-mainline/tree/pyro-training-v4.9.x/multi-v7-ml/recipes-kernel/linux/config/multi-v7-ml-base/features/zynq-qspi


[4] https://lists.yoctoproject.org/listinfo/meta-xilinx

Regards,

Robert




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

Re: [yocto] yocto layer dependencies

[Leonardo Sandoval]

ktreddy 70  writes:

> I am trying to set up yocto build environment for openlte, meta-sdr
> has most of the openlte depends
> I am getting following error when I try to build sdr, 
>
>
> /build$ bitbake sdr
> Loading cache: 100% |
> #
> ###| Time: 0:00:00
> Loaded 1642 entries from dependency cache.
> ERROR: ParseError at /home/ktreddy/zcu102/sources/poky/../
> meta-openembedded/meta-sdr/recipes-applications/gqrx/gqrx_git.bb:8:
> Could not inherit file classes/qt4x11.bbclass
>
>
> I do have meta-qt4 under meta-openembedded layer  as below.

at bblayers.conf, does BBLAYERS include the above full path of
meta-openembedded/meta-qt4? also, try placing the meta-qt4 at the same
level of meta-openembeded, because these are two independent
repositories (and if you run git clean -fd at meta-openmebeded, you do
not remove meta-qt4 by mistake :) )


>
> zcu102/sources$ ls meta-openembedded/meta-qt4/classes/
> qmake2.bbclass  qmake_base.bbclass  qt4e.bbclass  qt4x11.bbclass
>
>
> could you please help me on why am I getting this error ?
> How can I make one layer visible to another layer ?

Though BBLAYERS. Include any layer you want and depending on the
priority, bitbake will deal with the corresponding metadata (bbappends, etc.)

> Ex:  How can I make meta-sdr visible to openlte ? I mean how can I
> say to openlte that the dependency recipes are available under
> meta-sdr ?
>
> if new recipes are available for a layer how can I get those on to my
> build environment ?

basically the latter answer applies to this one.


>
> Thanks for your help.
>
> [no_pho] Click here to Reply or For
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Using standard SDK to build LKM

[Alberto Spin]

I've build a Standard SDK using yocto

  bitbake angstrom-lxde-image -c populate_sdk

I made sure that the kernel sources are included in the SDK

TOOLCHAIN_TARGET_TASK_append = "kernel-devsrc"

After installing the generated SDK at my workstation (separate machine from my 
build host), I verified that the kernel sources are present

In the directory where the SDK has been installed, the kernel subdirectory has 
been added.

datawatt@O-LINUX-1:~/toolchain/sysroots/armv7at2hf-neon-angstrom-linux-gnueabi/usr/src$
 tree -L 1
.
├── backfire
├── debug
└── kernel

3 directories, 0 files

Next I'm trying to build a simple LKM


  *   First I source the environment setup script

*
I'm using this c-source:

/**
* @filehello.c
* @author  Derek Molloy
* @date4 April 2015
* @version 0.1
* @brief  An introductory "Hello World!" loadable kernel module (LKM) that can 
display a message
* in the /var/log/kern.log file when the module is loaded and removed. The 
module can accept an
* argument when it is loaded -- the name, which appears in the kernel log files.
* @see http://www.derekmolloy.ie/ for a full description and follow-up 
descriptions.
*/

#include  // Macros used to mark up functions e.g., 
__init __exit
#include// Core header for loading LKMs into the 
kernel
#include// Contains types, macros, functions for 
the kernel

MODULE_LICENSE("GPL");  ///< The license type -- this affects 
runtime behavior
MODULE_AUTHOR("Derek Molloy");  ///< The author -- visible when you use 
modinfo
MODULE_DESCRIPTION("A simple Linux driver for the BBB.");  ///< The description 
-- see modinfo
MODULE_VERSION("0.1");  ///< The version of the module

static char *name = "world";///< An example LKM argument -- default 
value is "world"
module_param(name, charp, S_IRUGO); ///< Param desc. charp = char ptr, S_IRUGO 
can be read/not changed
MODULE_PARM_DESC(name, "The name to display in /var/log/kern.log");  ///< 
parameter description

/** @brief The LKM initialization function
*  The static keyword restricts the visibility of the function to within this C 
file. The __init
*  macro means that for a built-in driver (not a LKM) the function is only used 
at initialization
*  time and that it can be discarded and its memory freed up after that point.
*  @return returns 0 if successful
*/
static int __init helloBBB_init(void){
   printk(KERN_INFO "EBB: Hello %s from the BBB LKM!\n", name);
   return 0;
}

/** @brief The LKM cleanup function
*  Similar to the initialization function, it is static. The __exit macro 
notifies that if this
*  code is used for a built-in driver (not a LKM) that this function is not 
required.
*/
static void __exit helloBBB_exit(void){
   printk(KERN_INFO "EBB: Goodbye %s from the BBB LKM!\n", name);
}

/** @brief A module must use the module_init() module_exit() macros from 
linux/init.h, which
*  identify the initialization function at insertion time and the cleanup 
function (as
*  listed above)
*/
module_init(helloBBB_init);
module_exit(helloBBB_exit);

**
And this makefile:

datawatt@O-LINUX-1:~/workspace-lkm/hello$ cat Makefile
obj-m+=hello.o

#KDIR := /lib/modules/$(shell uname -r)/build/

KDIR := $(SDKTARGETSYSROOT)/usr/src/kernel/

all:
make -C $(KDIR) M=$(PWD) modules
clean:
make -C $(KDIR) M=$(PWD) clean


***
Next I start the build process, by executing make and I get an error which I 
can't fix:


datawatt@O-LINUX-1:~/workspace-lkm/hello$ make
make -C 
/home/datawatt/toolchain/sysroots/armv7at2hf-neon-angstrom-linux-gnueabi/usr/src/kernel/
 M=/home/datawatt/workspace-lkm/hello modules
make[1]: Entering directory 
'/home/datawatt/toolchain/sysroots/armv7at2hf-neon-angstrom-linux-gnueabi/usr/src/kernel'
  CC [M]  /home/datawatt/workspace-lkm/hello/hello.o
/bin/sh: scripts/basic/fixdep: No such file or directory
scripts/Makefile.build:264: recipe for target 
'/home/datawatt/workspace-lkm/hello/hello.o' failed
make[2]: *** [/home/datawatt/workspace-lkm/hello/hello.o] Error 1
Makefile:1387: recipe for target '_module_/home/datawatt/workspace-lkm/hello' 
failed
make[1]: *** [_module_/home/datawatt/workspace-lkm/hello] Error 2
make[1]: Leaving directory 
'/home/datawatt/toolchain/sysroots/armv7at2hf-neon-angstrom-linux-gnueabi/usr/src/kernel'
Makefile:8: recipe for target 'all' failed
make: *** [all] Error 2

Any help is appreciated.

Alberto Spin










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

[yocto] Release Candidate Build for yocto-2.2.2.rc1 now available.

[pokybuild]

A release candidate build for yocto-2.2.2.rc1 is now available at:


https://autobuilder.yocto.io/pub/releases/yocto-2.2.2.rc1


Please begin QA on this build as soon as possible.


Build hash information: 
meta-intel : 6add41510412ca196efb3e4f949d403a8b6f35d7 
meta-qt4 : f389368dc86e745df14cab9eeb9a94bc02bd273e 
refkit : 600e05c0379e20240be5a55af949ee296baa01b3 
meta-mingw : 58dda8440c1943c15ee750eb40f0fc651e316f51 
meta-qt3 : f33b73a9563f2dfdfd0ee37b61d65d90197a456f 
meta-gplv2 : d8668018d5d795be2297f878fd871a27edf532bf 
poky : 60402978fe3648bf560b3386c6e9dd661cdf2083 

\nThis is an automated message from\nThe Yocto Project Autobuilder\nGit: 
git://git.yoctoproject.org/yocto-autobuilder\nEmail: pi...@toganlabs.com 
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [opkg-utils PATCH] opkg-build*: fix empty package name in error message

[Adam Trhon]

When opkg-build detects illegal character in package name it prints an error
message with this name. Due to a wrong variable name the package name in the
error message is empty. The same error occurs in opkg-buildpackage as well.
This patch fixes both.

Signed-off-by: Adam Trhon 
---
 opkg-build| 2 +-
 opkg-buildpackage | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/opkg-build b/opkg-build
index e02eaca..0fe513a 100755
--- a/opkg-build
+++ b/opkg-build
@@ -108,7 +108,7 @@ You probably want to chown these to a system user: " >&2
[ "$?" -ne 0 ] && PKG_ERROR=1
 
if echo $pkg | grep '[^a-z0-9.+-]'; then
-   echo "*** Error: Package name $name contains illegal 
characters, (other than [a-z0-9.+-])" >&2
+   echo "*** Error: Package name $pkg contains illegal characters, 
(other than [a-z0-9.+-])" >&2
PKG_ERROR=1;
fi
 
diff --git a/opkg-buildpackage b/opkg-buildpackage
index 719c9a5..b7c0e8c 100755
--- a/opkg-buildpackage
+++ b/opkg-buildpackage
@@ -66,7 +66,7 @@ pkg_appears_sane_control() {
required_field Description >/dev/null
 
if echo $pkg | grep '[^a-z0-9.+-]'; then
-   echo "opkg-build: Error: Package name $name contains illegal 
characters, (other than [a-z0-9.+-])"
+   echo "opkg-build: Error: Package name $pkg contains illegal 
characters, (other than [a-z0-9.+-])"
PKG_ERROR=1;
fi
 
-- 
2.14.1

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

[yocto] yocto layer dependencies

[ktreddy 70]

I am trying to set up yocto build environment for openlte, meta-sdr has
most of the openlte depends
I am getting following error when I try to build sdr,


/build$ bitbake sdr
Loading cache: 100% |#

###| Time: 0:00:00
Loaded 1642 entries from dependency cache.
ERROR: ParseError at /home/ktreddy/zcu102/sources/poky/../meta-openembedded/
meta-sdr/recipes-applications/gqrx/gqrx_git.bb:8: Could not inherit file
classes/qt4x11.bbclass


I do have meta-qt4 under meta-openembedded layer  as below.

zcu102/sources$* ls *meta-openembedded/meta-qt4/classes/
qmake2.bbclass  qmake_base.bbclass  qt4e.bbclass  *qt4x11.bbclass*


could you please help me on why am I getting this error ?
How can I make one layer visible to another layer ?
Ex:  How can I make meta-sdr visible to openlte ? I mean how can I say to
openlte that the dependency recipes are available under meta-sdr ?

if new recipes are available for a layer how can I get those on to my build
environment ?

Thanks for your help.
Click here to Reply or For
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Yocto Project Status WW37’17

[Jolley, Stephen K]

Current Dev Position: YP 2.4 M4

Next Deadline: YP 2.4 Final Cut off is Sept. 18, 2017


SWAT team rotation: Tracy -> Alejandro on Sept. 8, 2017

SWAT team rotation: Alejandro -> Stephano on Sept. 15, 2017.

https://wiki.yoctoproject.org/wiki/Yocto_Build_Failure_Swat_Team


Key Status/Updates:

·We’re continuing with some good bug fixing for M4. Patches are queuing 
whilst we debug some build issues but we should be able to merge a large 
portion of the backlog imminently.

·We continue to see intermittent failures on qemuppc with rcu 
tracebacks in the kernel. We also continue to see some qemu startup issues but 
a patch from Juro looks promising to address these.

·The wrong options were set for the first build on morty and we have 
had a few issues getting the build into QA but QA has started and 2.2.2 should 
be ready for release soon assuming it passes the QA tests.  QA status is at: 
https://wiki.yoctoproject.org/wiki/2.2_QA_Status

·Pyro is also trending well for a new point release soon. Thanks for 
Armin’s hard work on pulling both this and the morty builds together.


Planned upcoming dot releases:

YP 2.2.2 Cut off June 5, 2017 – In QA now.

YP 2.2.2 Release by June, 16 2017

YP 2.3.2 Cut off Sept. 1, 2017

YP 2.3.2 Release by Sept. 15, 2017


Key YP 2.4 Dates are:

YP 2.4 M4 (Final) Cut off is Sept. 18, 2017

YP 2.4 M4 (Final) Release by Oct. 20, 2017


Tracking Metrics:

WDD 2540 (last week 2529)

(https://wiki.yoctoproject.org/charts/combo.html)


Key Status Links for YP:

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

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

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


[If anyone has suggestions for other information you’d like to see on this 
weekly status update, let us know!]


Thanks,

Stephen K. Jolley
Yocto Project Program Manager
INTEL, MS JF1-255, 2111 N.E. 25th Avenue, Hillsboro, OR 97124
•   Work Telephone:(503) 712-0534
•Cell:   (208) 244-4460
• Email:  stephen.k.jol...@intel.com

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

Re: [yocto] [meta-raspberrypi] Could not inherit file classes/pypi.bbclass

[Andrei Gherzan]

On Mon, Sep 11, 2017 at 1:40 PM, yahia farghaly 
wrote:

> ok,thanks it is now building. i have another question, i don't need to use
> the meta-gstreamer1.0 layer if i will use the gstreamer in your multimedia
> layer with *IMAGE_INSTALL_append = gstreamer ?*
>

I personally haven't used that layer and the gstreamer is provided by poky:
https://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/recipes-
multimedia/gstreamer .
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] meta-java on Raspberry Pi 3

[Francesco Giancane]

Hi everyone,

I am having troubles building an image for the Raspberry Pi 3 including Java.

I did the all the standard operations (layer configuration, machine
configuration etc) but eventually bitbake will fail on openjre-8.

Looking at the meta-java in depth I found that the source of failure
is located in ant-native; because it is required to properly build
openjdk till version 8.

Problems are located in build dependencies like classpath-native,
jaxp1.3-native, all required to build ant-native. It seems that the
bootstrap javac tool installed from ecj-bootstrap-native is broken (it
reports a core dump).

Is anyone having the same issues? Can you tell me something about that?

Thank you,
Francesco
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-raspberrypi] Could not inherit file classes/pypi.bbclass

[yahia farghaly]

ok,thanks it is now building. i have another question, i don't need to use
the meta-gstreamer1.0 layer if i will use the gstreamer in your multimedia
layer with *IMAGE_INSTALL_append = gstreamer ?*

On 11 September 2017 at 13:58, Andrei Gherzan  wrote:

>
>
> On 11 Sep 2017 12:51, "yahia farghaly"  wrote:
>
> i cloned the latest pyro version with meta-raspberry pi . i added
> meta-raspberrypi to bblayer and adjust the machine ?= "raspberry pi" when i
> bitbake rpi-hwup-image*.*
>
> it throws me the error of
> *ERROR: ParseError at
> /home/yahia/Desktop/elinux_dev/bake_factory/git_versions/poky/meta-raspberrypi/recipes-devtools/python/rpi-gpio_0.6.3.bb:8
> : Could not inherit file classes/pypi.bbclass*
>
>
> There is a dependency in the README which you missed in the bblayers.
> Namely meta-python.
> --
> Andrei Gherzan
> gpg: rsa4096/D4D94F67AD0E9640 | t: @agherzan
>



-- 
Yahia Farghaly
Graduated from Faculty of Engineering - Electronics and Communications
Department at Cairo University.
Linkedin  - GitHub

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

Re: [yocto] [meta-raspberrypi] Could not inherit file classes/pypi.bbclass

[Andrei Gherzan]

On 11 Sep 2017 12:51, "yahia farghaly"  wrote:

i cloned the latest pyro version with meta-raspberry pi . i added
meta-raspberrypi to bblayer and adjust the machine ?= "raspberry pi" when i
bitbake rpi-hwup-image*.*

it throws me the error of
*ERROR: ParseError at
/home/yahia/Desktop/elinux_dev/bake_factory/git_versions/poky/meta-raspberrypi/recipes-devtools/python/rpi-gpio_0.6.3.bb:8
: Could not inherit file classes/pypi.bbclass*


There is a dependency in the README which you missed in the bblayers.
Namely meta-python.
--
Andrei Gherzan
gpg: rsa4096/D4D94F67AD0E9640 | t: @agherzan
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [meta-raspberrypi] Could not inherit file classes/pypi.bbclass

[yahia farghaly]

i cloned the latest pyro version with meta-raspberry pi . i added
meta-raspberrypi to bblayer and adjust the machine ?= "raspberry pi" when i
bitbake rpi-hwup-image*.*

it throws me the error of
*ERROR: ParseError at
/home/yahia/Desktop/elinux_dev/bake_factory/git_versions/poky/meta-raspberrypi/recipes-devtools/python/rpi-gpio_0.6.3.bb:8
: Could not inherit file classes/pypi.bbclass*


-- 
Yahia Farghaly
Graduated from Faculty of Engineering - Electronics and Communications
Department at Cairo University.
Linkedin  - GitHub




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

Re: [yocto] pyro openembedded gpsd update-rc.d problems with read-only-rootfs

[Burton, Ross]

On 10 September 2017 at 21:35, Dan Walkes 
wrote:

> It looks like because the update-rc.d step fails this setup gets moved
> into a gpsd post install script, which won’t work because I’m
> configured to use a read only root filesystem.  So I need to find a
> way to keep the update-rc.d step from failing.
>

The recipe shouldn't invoke update-alternatives directly, but use the
update-alternatives class instead.

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

Re: [yocto] Suitable machine for yocto

[Chris Tapp]

> On 11 Sep 2017, at 09:24, Usman Haider  wrote:
> 
> 
> 
> On Mon, Sep 11, 2017 at 1:21 PM, Burton, Ross  > wrote:
> On 10 September 2017 at 12:00, Chris Tapp  > wrote:
> I have a similar spec, except I use an SSD for the build area and only 16GB 
> RAM (I don’t see more than about 12GB used during a build) - a build from 
> scratch (excluding download time) takes just under an hour.
> 
> The thing to remember with SSDs is that builds can write *a lot* of data and 
> this can destroy SSDs faster than you'd like.
> 
> Personally I find lots of RAM more cost effective.  If you've got a moderate 
> amount then a slow commit time in fstab lets the kernel batch writes wisely.  
> If you've got plenty of RAM (my machine has 64GB) then a good sized tmpfs 
> (32GB here) mounted at TMPDIR (the local.conf setting, not /tmp) in with 
> rm_work means you literally have no I/O latency.  To persist files either 
> copy them out or for example set DEPLOY_DIR to a real disk.
> 
> Ross
> 
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org 
> https://lists.yoctoproject.org/listinfo/yocto 
> 
> 
> 
> 
> Thanks,
> 
> I'll consider this too. A lot of techincal stuff to learn here on this 
> mailing list :)

One thing you’ll find here is a lot of very knowledgable people who go out of 
their way to help as much as possible - got me going from a cold start very, 
very quickly :-)

A really good example of an excellent opensource project / community.

> Regards,
> Usman

--

Chris Tapp
opensou...@keylevel.com
www.keylevel.com


You can tell you're getting older when your car insurance gets real cheap!

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

Re: [yocto] Suitable machine for yocto

[Usman Haider]

On Mon, Sep 11, 2017 at 1:21 PM, Burton, Ross  wrote:

> On 10 September 2017 at 12:00, Chris Tapp  wrote:
>
>> I have a similar spec, except I use an SSD for the build area and only
>> 16GB RAM (I don’t see more than about 12GB used during a build) - a build
>> from scratch (excluding download time) takes just under an hour.
>>
>
> The thing to remember with SSDs is that builds can write *a lot* of data
> and this can destroy SSDs faster than you'd like.
>
> Personally I find lots of RAM more cost effective.  If you've got a
> moderate amount then a slow commit time in fstab lets the kernel batch
> writes wisely.  If you've got plenty of RAM (my machine has 64GB) then a
> good sized tmpfs (32GB here) mounted at TMPDIR (the local.conf setting, not
> /tmp) in with rm_work means you literally have no I/O latency.  To persist
> files either copy them out or for example set DEPLOY_DIR to a real disk.
>
> Ross
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
>

Thanks,

I'll consider this too. A lot of techincal stuff to learn here on this
mailing list :)

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

Re: [yocto] Suitable machine for yocto

[Usman Haider]

On Mon, Sep 11, 2017 at 11:51 AM, Alex Lennon  wrote:

>
>
> On 11/09/2017 00:56, Mark Hatle wrote:
>
>> On 9/10/17 2:31 PM, Alex Lennon wrote:
>>
>>>
>>> On 10/09/2017 19:17, Mark Hatle wrote:
>>>
 On 9/10/17 11:14 AM, Alex Lennon wrote:

> On 10/09/2017 17:06, Mark Hatle wrote:
>
>> On 9/10/17 2:00 AM, Usman Haider wrote:
>>
>>> Hi,
>>>
>>> Can someone please recommend some good machine for yocto environment
>>> and
>>> building sdks. I am interested in RAM, hard disk space, processor.
>>>
>> You want fast I/O, as much RAM and as many (fast) cores as you can
>> afford.  I
>> don't think there is a single answer as what is 'best'.  It also
>> depends on
>> which Yocto Project versions, and which layers you are using as to
>> which
>> combination is best.
>>
>> I run builds on my laptop, 4-core/8-thread & SSD and 16 GB of ram
>> from a few
>> years ago.  It's fast, but I wouldn't want to do all of my
>> development on it.
>>
>> I've had 8-core/16-thread (32GB ram/standard disk), 16-core/32-thread
>> (72GB
>> ram/SAS-3 RAID), 24-core/48-thread (64GB ram/SATA - software RAID),
>> 72-core/144
>> thread (256 GB ram/hardware raid/SAS-3), and recently upgraded to
>> 96-core/192-thread (256 GB ram/hardware raid/SAS-3).
>>
>> I would not go below quad-core (8-thread) myself.  You can get a quad
>> core, good
>> quality machine for $1000 or less these day.  If you move up to the
>> larger
>> machines, you can even be able to get to a 24-core for less then
>> $5000.  By the
>> time you get to 96-core and all of the googles you are likely talking
>> $5 or
>> more.
>>
>> By clock raid, the 24-core machine is the fastest..  While the
>> 96-core monster
>> can do the builds the quickest.  But when you figure out
>> cost/performance/etc..
>> the 24-core is probably the best performance per dollar, and with
>> adequate RAM
>> (I'd say at least 64GB if not 128GB), and fast I/O you'll probably
>> get the
>> lowest price for the best performance in that category.
>>
>> If you need sheer speed and price is no option, then the (4 CPU w/ 24
>> core each)
>> 96-core monster (or even better) is what you want to go with.  256GB
>> ram would
>> be a minimum with that configuration (I'm not sure if more is
>> actually helpful,
>> I rarely end up in swap -- but I go get into situations where more
>> then 50% of
>> ram is used.)  With that many cores, disk I/O starts to become
>> obvious.  So
>> faster the better... SSDs would be the fastest, but of course the
>> most expensive.
>>
>> If your employer is paying for the machine, you may be able to get a
>> better then
>> normal machine by explaining how much time a faster machine will save
>> and how
>> comparing to your salary a machine is inexpensive.  (If you are a
>> contractor or
>> student, that changes of course.)  :)
>>
>> So my point is really, figure out how much money you have to spend.
>> My rule of
>> thumb is roughly:
>>
>> 1) Buy as many cores as you can.  Try to get a CPU that has
>> Hyperthreading or
>> equivalent to double the effective core count.  Fastest processing
>> speed helps
>> in repetitive cases vs full system builds.
>>
>> So if the choice is a 24 core @ 2.2GHz vs 22 core @ 2.5, I'd probably
>> go with
>> the 22-core.  While if it was 24 core @ 2.2GHz vs 8 core @ 4.2 GHz,
>> I'd go with
>> the 24 core.
>>
>> 2) Try to get at least 1 GB of ram per thread (2 GB per core..)  You
>> can cut
>> back on the ram (if necessary) once you hit 72 threads or so.   (72
>> threads
>> right now seems to cover most of the parallelization in a full system
>> build.
>> There are points in the system where it can parallelize MUCH more,
>> but they are
>> fairly rare.)
>>
>> 3) You need fast disks.  Software RAID works fine, but you likely
>> need to buy at
>> least a couple of disk to boost performance.  SSDs are fast, but lots
>> of builds
>> take space, so fast SATA or even better SAS drives are the best
>> performance per
>> cost.
>>
> This brings to mind a related question I keep coming back to as to the
> economics of a docker (or similar) image running a fast Yocto build in
> the cloud.
>
> i.e. set config params -> bring up server image on plaform A/B/C ->
> perform build taking time X/Y/Z -> store output images -> bring down
> server  == $ ?
>
> I find myself asking what the optimal cost per-build would be using
> this
> approach...
>
 I helped someone do some very -preliminary- figured a few years ago.
 The
 processing was 'cheap', but between storage and network transfer
 costs..

Re: [yocto] Suitable machine for yocto

[Burton, Ross]

On 10 September 2017 at 12:00, Chris Tapp  wrote:

> I have a similar spec, except I use an SSD for the build area and only
> 16GB RAM (I don’t see more than about 12GB used during a build) - a build
> from scratch (excluding download time) takes just under an hour.
>

The thing to remember with SSDs is that builds can write *a lot* of data
and this can destroy SSDs faster than you'd like.

Personally I find lots of RAM more cost effective.  If you've got a
moderate amount then a slow commit time in fstab lets the kernel batch
writes wisely.  If you've got plenty of RAM (my machine has 64GB) then a
good sized tmpfs (32GB here) mounted at TMPDIR (the local.conf setting, not
/tmp) in with rm_work means you literally have no I/O latency.  To persist
files either copy them out or for example set DEPLOY_DIR to a real disk.

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