[yocto] [PATCH V2][meta-cgl] pacemaker: Upgrade 1.1.16 -> 1.1.19

2018-08-20 Thread changqing.li 
From: Changqing Li 

1. Upgrade pacemaker to 1.1.19
2. fence_legacy/fence_pcmk in package pacemaker requires
   /usr/bin/perl, but no providers found in
   RDEPENDS_pacemaker, so add it

Signed-off-by: Changqing Li 
---
 ...-pacemaker-fix-compile-error-of-musl-libc.patch | 56 ++
 .../pacemaker/0001-pacemaker-fix-xml-config.patch  | 19 +---
 .../{pacemaker_1.1.16.bb => pacemaker_1.1.19.bb}   |  9 ++--
 3 files changed, 74 insertions(+), 10 deletions(-)
 create mode 100644 
meta-cgl-common/recipes-cgl/pacemaker/pacemaker/0001-pacemaker-fix-compile-error-of-musl-libc.patch
 rename meta-cgl-common/recipes-cgl/pacemaker/{pacemaker_1.1.16.bb => 
pacemaker_1.1.19.bb} (93%)

diff --git 
a/meta-cgl-common/recipes-cgl/pacemaker/pacemaker/0001-pacemaker-fix-compile-error-of-musl-libc.patch
 
b/meta-cgl-common/recipes-cgl/pacemaker/pacemaker/0001-pacemaker-fix-compile-error-of-musl-libc.patch
new file mode 100644
index 000..f8cbb7e
--- /dev/null
+++ 
b/meta-cgl-common/recipes-cgl/pacemaker/pacemaker/0001-pacemaker-fix-compile-error-of-musl-libc.patch
@@ -0,0 +1,56 @@
+From 51b0df9242bb1e3eb41362381472a00727910f64 Mon Sep 17 00:00:00 2001
+From: Changqing Li 
+Date: Fri, 10 Aug 2018 15:08:31 +0800
+Subject: [PATCH] pacemaker: fix compile error of musl libc
+
+Upstream-Status: Pending
+
+Signed-off-by: Changqing Li 
+---
+ include/crm/stonith-ng.h | 1 +
+ lib/cib/cib_remote.c | 3 ---
+ tools/crm_mon.c  | 2 +-
+ 3 files changed, 2 insertions(+), 4 deletions(-)
+
+diff --git a/include/crm/stonith-ng.h b/include/crm/stonith-ng.h
+index 56c1ec7..a637b47 100644
+--- a/include/crm/stonith-ng.h
 b/include/crm/stonith-ng.h
+@@ -28,6 +28,7 @@
+ #  include 
+ #  include 
+ #  include 
++#  include 
+ 
+ /* TO-DO: Work out how to drop this requirement */
+ #  include 
+diff --git a/lib/cib/cib_remote.c b/lib/cib/cib_remote.c
+index 4d7b93b..8be8ecc 100644
+--- a/lib/cib/cib_remote.c
 b/lib/cib/cib_remote.c
+@@ -53,9 +53,6 @@ typedef void gnutls_session_t;
+ #endif
+ 
+ #include 
+-#ifndef ON_BSD
+-#  include 
+-#endif
+ 
+ #define DH_BITS 1024
+ 
+diff --git a/tools/crm_mon.c b/tools/crm_mon.c
+index 7c63803..1ae6c21 100644
+--- a/tools/crm_mon.c
 b/tools/crm_mon.c
+@@ -553,7 +553,7 @@ main(int argc, char **argv)
+ 
+ #if !defined (ON_DARWIN) && !defined (ON_BSD)
+ /* prevent zombies */
+-signal(SIGCLD, SIG_IGN);
++signal(SIGCHLD, SIG_IGN);
+ #endif
+ 
+ if (crm_ends_with_ext(argv[0], ".cgi") == TRUE) {
+-- 
+2.7.4
+
diff --git 
a/meta-cgl-common/recipes-cgl/pacemaker/pacemaker/0001-pacemaker-fix-xml-config.patch
 
b/meta-cgl-common/recipes-cgl/pacemaker/pacemaker/0001-pacemaker-fix-xml-config.patch
index c27052d..72c3a1e 100644
--- 
a/meta-cgl-common/recipes-cgl/pacemaker/pacemaker/0001-pacemaker-fix-xml-config.patch
+++ 
b/meta-cgl-common/recipes-cgl/pacemaker/pacemaker/0001-pacemaker-fix-xml-config.patch
@@ -1,27 +1,29 @@
-From a55e235f56bc6e894e79fa200c39678e06ef985e Mon Sep 17 00:00:00 2001
-From: Bian Naimeng 
-Date: Fri, 3 Jul 2015 15:48:58 +0900
+From ac1ff1d538d2be205fbcc9676c6497a1395b71d8 Mon Sep 17 00:00:00 2001
+From: Changqing Li 
+Date: Fri, 10 Aug 2018 14:59:33 +0800
 Subject: [PATCH] pacemaker: fix xml config
 
 Signed-off-by: Bian Naimeng 
 
+update to version 1.1.19
+Signed-off-by: Changqing Li 
 ---
  configure.ac | 17 ++---
  1 file changed, 6 insertions(+), 11 deletions(-)
 
 diff --git a/configure.ac b/configure.ac
-index 7195f9b..5e420f2 100644
+index 3bf1914..345caeb 100644
 --- a/configure.ac
 +++ b/configure.ac
-@@ -557,7 +557,6 @@ AC_PATH_PROGS(TAR, tar)
+@@ -555,7 +555,6 @@ AC_PATH_PROGS(TAR, tar)
  AC_PATH_PROGS(MD5, md5)
  AC_PATH_PROGS(TEST, test)
- AC_PATH_PROGS(PKGCONFIG, pkg-config)
+ PKG_PROG_PKG_CONFIG
 -AC_PATH_PROGS(XML2CONFIG, xml2-config)
  AC_PATH_PROGS(VALGRIND_BIN, valgrind, /usr/bin/valgrind)
  AC_DEFINE_UNQUOTED(VALGRIND_BIN, "$VALGRIND_BIN", Valgrind command)
  
-@@ -807,17 +806,13 @@ dnl AC_CHECK_HEADERS(netinet/icmp6.h)
+@@ -805,17 +804,13 @@ dnl AC_CHECK_HEADERS(netinet/icmp6.h)
  dnl AC_CHECK_HEADERS(netinet/ip6.h)
  dnl AC_CHECK_HEADERS(netinet/ip_icmp.h)
  
@@ -45,3 +47,6 @@ index 7195f9b..5e420f2 100644
  
  AC_CHECK_HEADERS(libxml/xpath.h)
  AC_CHECK_HEADERS(libxslt/xslt.h)
+-- 
+2.7.4
+
diff --git a/meta-cgl-common/recipes-cgl/pacemaker/pacemaker_1.1.16.bb 
b/meta-cgl-common/recipes-cgl/pacemaker/pacemaker_1.1.19.bb
similarity index 93%
rename from meta-cgl-common/recipes-cgl/pacemaker/pacemaker_1.1.16.bb
rename to meta-cgl-common/recipes-cgl/pacemaker/pacemaker_1.1.19.bb
index 8726111..181c65f 100644
--- a/meta-cgl-common/recipes-cgl/pacemaker/pacemaker_1.1.16.bb
+++ b/meta-cgl-common/recipes-cgl/pacemaker/pacemaker_1.1.19.bb
@@ -24,8 +24,11 @@ SRC_URI = 
"https://github.com/ClusterLabs/${BPN}/archive/Pacemaker-${PV}.zip \
file://volatiles \
file://tmpfiles \
   "
-SRC_URI[md5sum] = "6f60f733823d31acbef4556fb749c457"
-SRC_URI[sha256sum] =

Re: [yocto] ptest-runner "No ptests found."

2018-08-20 Thread Nader Hariri 
Yes, I expect to find in my image ptests for systemd and zlib because these 
recipes are ptest-enabled.

In fact, after some trials, I got to understand that the problem is related to  
EXTRA_IMAGE_FEATURES += "ptest-pkgs" , because  I replaced it with 
IMAGE_FEATURES_append = " ptest-pkgs" in local.conf and to my surprise I found 
all -ptests packages from all the ptest-enabled recipes in my image.

So,  contrary to what is stated in the ptest wiki and the yocto documentation, 
using EXTRA_IMAGE_FEATURES doesn't install ptests packages (from ptest-enabled 
recipes) in my image, and I can't figure out why ..


Nader

De : Alexander Kanavin 
Envoyé : lundi 20 août 2018 14:09
À : Nader Hariri
Cc : yocto@yoctoproject.org
Objet : Re: [yocto] ptest-runner "No ptests found."

2018-08-16 16:07 GMT+02:00 Nader Hariri :
> Hi, I am new to Yocto. I am working on ptest-runner.
>
> I followed the wiki https://wiki.yoctoproject.org/wiki/Ptest , but when I
> boot to my image and run ptest-runner I have the output : "No ptests found."
>
> Is this normal ? I thought that
>
> DISTRO_FEATURES_append = " ptest"
>
> and
>
> EXTRA_IMAGE_FEATURES += "ptest-pkgs"
>
>  would install all the ptests for me in my image, apparently I am wrong but
> could you please explain to me why this is not the case i.e why ptests are
> not automatically installed in the image even though I included the above
> lines in my local.conf ?

Please note that ptests are only supported by a (small) subset of
recipes. If none of the packages that are in your image are
ptest-enabled, then no ptests will go to the image. Is there a recipe
in particular for which you expected ptests to be in the image, and
they're not?

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

Re: [yocto] opkg

2018-08-20 Thread Khem Raj 
On Mon, Aug 20, 2018 at 2:41 PM Phillip Warren  wrote:
>
> Hi, I'm currently working on the pyro branch (2.3.4) and have a need
> to support opkg list-upgradable; however, when I execute opkg
> list-upgradable, I receive the following error:
>
> Collected errors:
>  * opkg_list_upgradable_cmd: list-upgradable command not available
> with external solver enabled
>
> The pyro opkg version is:
> ~# opkg --version
> opkg version 0.3.4 (libsolv 0.6.26)
>
> What is the simplest way to enable the list-upgradeable option for opkg?
>
> 1. Write a .bbappend to apply the patch to the 0.3.4 source that
> enables this functionality? Where might I locate this patch?

usually this is ok and upstreamable, but may not be always possible if
change is quite intrusive
you might look into opkg git here
http://git.yoctoproject.org/cgit/cgit.cgi/opkg

particularly this commit
http://git.yoctoproject.org/cgit/cgit.cgi/opkg/commit/?id=cc624806a6179c2d3d7b3eec4260e50ab0653c5d

be aware that it looks like it might need some other commits too.

> 2. Fast-forward opkg 0.3.4 to a newer version? What's the approved way
> to do this within the yocto environment?
>

sometimes this might be fine, we wont accept it upstream without a
solid reasoning but it could serve your
purpose and you can maintain it in your local project. Although be
aware that it has not been integrated with
older versions of yocto so there could be loose ends.

> Thanks!
> Phillip Warren
> --
> ___
> 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] bitbake firefox using meta-browser layer

2018-08-20 Thread Takuro Ashie 

Hi.

| mozbuild.configure.options.InvalidOptionError: Unknown option: --build |

Please try removing "--build=${BUILD_SYS}" from EXTRA_OECONF in 
meta-browser/classes/mozilla.bbclass.

This option is removed in recent firefox.

# But it's a bit weird, I don't met this error on firefox 52.9.0, it's 
reproduced on firefox 60 though.
# 
https://github.com/OSSystems/meta-browser/pull/160/files#diff-3d50dfec940b3c4b146aae90e6224125R11


On 2018年08月20日 22:56, Pandey, Kamal wrote:


I was trying to compile the Firefox browser for a custom embedded 
device. But it is falling giving the following error:


cd 
/home/iepl/work/yocto_build/poky/build/tmp/work/aarch64-pdm3-linux/firefox/52.9.0esr-r0/firefox-52.9.0esr/firefox-build-dir


| 
/home/iepl/work/yocto_build/poky/build/tmp/work/aarch64-pdm3-linux/firefox/52.9.0esr-r0/firefox-52.9.0esr/configure 
--target=aarch64-pdm3-linux --host=x86_64-linux 
--with-toolchain-prefix=aarch64-pdm3-linux- --build=x86_64-linux 
--prefix=/usr


| Reexecuting in the virtualenv

| Adding configure options from 
/home/iepl/work/yocto_build/poky/build/tmp/work/aarch64-pdm3-linux/firefox/52.9.0esr-r0/mozconfig


|   --enable-application=browser

|   --target=aarch64-pdm3-linux

|   --prefix=/usr

|   --enable-application=browser

|   --enable-official-branding

|   --disable-elf-hack

|   --disable-gold

|   --disable-strip

|   --disable-install-strip

|   --with-system-nss

|   --with-system-nspr

|   --with-system-zlib

|   --with-system-bz2

|   --with-system-libevent

|   --with-system-libvpx

|   --with-system-icu

|   --enable-system-ffi

|   --enable-system-pixman

|   --enable-startup-notification

|   --enable-pulseaudio

|   --disable-tests

|   --disable-necko-wifi

|   --disable-gconf

|   --disable-crashreporter

|   --disable-updater

|   --disable-debug-symbols

| checking for a shell... 
/home/iepl/work/yocto_build/poky/build/tmp/hosttools/sh


| checking for host system type... x86_64-pc-linux-gnu

| checking for target system type... aarch64-pdm3-linux-gnu

| Traceback (most recent call last):

|   File 
"/home/iepl/work/yocto_build/poky/build/tmp/work/aarch64-pdm3-linux/firefox/52.9.0esr-r0/firefox-52.9.0esr/configure.py", 
line 107, in 


| sys.exit(main(sys.argv))

|   File 
"/home/iepl/work/yocto_build/poky/build/tmp/work/aarch64-pdm3-linux/firefox/52.9.0esr-r0/firefox-52.9.0esr/configure.py", 
line 26, in main


| sandbox.run(os.path.join(os.path.dirname(__file__), 'moz.configure'))

|   File 
"/home/iepl/work/yocto_build/poky/build/tmp/work/aarch64-pdm3-linux/firefox/52.9.0esr-r0/firefox-52.9.0esr/python/mozbuild/mozbuild/configure/__init__.py", 
line 359, in run


| raise InvalidOptionError('Unknown option: %s' % without_value)

| mozbuild.configure.options.InvalidOptionError: Unknown option: --build

| *** Fix above errors and then restart with\

|    "make -f client.mk build"

| client.mk:375: recipe for target 'configure' failed

| make: *** [configure] Error 1

| ERROR: oe_runmake failed

| WARNING: exit code 1 from a shell command.

| ERROR: Function failed: do_configure (log file is located at 
/home/iepl/work/yocto_build/poky/build/tmp/work/aarch64-pdm3-linux/firefox/52.9.0esr-r0/temp/log.do_configure.5847)


ERROR: Task 
(/home/iepl/work/yocto_build/meta-browser/recipes-browser/firefox/firefox_52.9.0esr.bb:do_configure) 
failed with exit code '1'


Can anybody provide me a solution or at least a  hint, so that I can 
move forward.


Best Regards

Kamal Pandey

Junior Software Engineer

ifm_logo_sqrsifm engineering pvt. ltd.

Survey No. 1/10/16, 3rd floor, Above SBI, Bavdhan Branch, N.D.A. Road, 
Bavdhan, Pune, India - 411021 | Web: www.ifm.com 
| Phone: +91-20-22951910 Extn:215 | CIN: 
U29213PN2010FTC13676






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

[yocto] opkg

2018-08-20 Thread Phillip Warren 
Hi, I'm currently working on the pyro branch (2.3.4) and have a need
to support opkg list-upgradable; however, when I execute opkg
list-upgradable, I receive the following error:

Collected errors:
 * opkg_list_upgradable_cmd: list-upgradable command not available
with external solver enabled

The pyro opkg version is:
~# opkg --version
opkg version 0.3.4 (libsolv 0.6.26)

What is the simplest way to enable the list-upgradeable option for opkg?

1. Write a .bbappend to apply the patch to the 0.3.4 source that
enables this functionality? Where might I locate this patch?
2. Fast-forward opkg 0.3.4 to a newer version? What's the approved way
to do this within the yocto environment?

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

Re: [yocto] ptest-runner "No ptests found."

2018-08-20 Thread Nader Hariri 
I ran 'bitbake -e ' as you have suggested. I can see from the logs that 
the variable IMAGE_FEATURES does get appended the value of 
${EXTRA_IMAGE_FEATURES}, however I still have no -ptest packages in my image. 
Is there anything wrong in my logs?


# $IMAGE_FEATURES [3 operations]
#   set? 
/home/nader/poky-docker/workdir/poky/meta/conf/distro/include/default-distrovars.inc:23
# ""
#   set /home/nader/poky-docker/workdir/poky/meta/conf/documentation.conf:210
# [doc] "The primary list of features to include in an image. Configure 
this variable in an image recipe."
#   append /home/nader/poky-docker/workdir/poky/meta/conf/bitbake.conf:806
# "${EXTRA_IMAGE_FEATURES}"
# pre-expansion value:
#   " ${EXTRA_IMAGE_FEATURES}"
IMAGE_FEATURES="  ptest-pkgs"


Nader

De : Alexander Kanavin 
Envoyé : lundi 20 août 2018 15:26
À : Nader Hariri
Cc : yocto@yoctoproject.org
Objet : Re: [yocto] ptest-runner "No ptests found."

2018-08-20 14:07 GMT+02:00 Nader Hariri :
> So,  contrary to what is stated in the ptest wiki and the yocto
> documentation, using EXTRA_IMAGE_FEATURES doesn't install ptests packages
> (from ptest-enabled recipes) in my image, and I can't figure out why ..

You can run 'bitbake -e ' to figure out why
EXTRA_IMAGE_FEATURES has no effect. In my tests (poky master) it seems
to work as intended:

#
# $IMAGE_FEATURES [8 operations]
#   append /home/alexander/development/meta-qt5/conf/layer.conf:36
# [validitems] "qtcreator-debug"
#   set? 
/home/alexander/development/poky/meta/conf/distro/include/default-distrovars.inc:24
# ""
#   set /home/alexander/development/poky/meta/conf/documentation.conf:208
# [doc] "The primary list of features to include in an image.
Configure this variable in an image recipe."
#   append /home/alexander/development/poky/meta/conf/bitbake.conf:812
# "${EXTRA_IMAGE_FEATURES}"
#   set? /home/alexander/development/poky/meta/classes/image.bbclass:34
# ""
#   set /home/alexander/development/poky/meta/classes/image.bbclass:35
# [type] "list"
#   append /home/alexander/development/poky/meta/classes/image.bbclass:36
# [validitems] "debug-tweaks read-only-rootfs empty-root-password
allow-empty-password allow-root-login post-install-logging"
#   set image.bbclass:166
[__anon_168__home_alexander_development_poky_meta_classes_image_bbclass]
# "debug-tweaks"
# pre-expansion value:
#   "debug-tweaks"
IMAGE_FEATURES="debug-tweaks"


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

[yocto] Yocto Project Unassigned Bugs - Help Needed

2018-08-20 Thread Jolley, Stephen K 
All,



The triage team meets weekly and does its best to handle the bugs reported into 
the bugzilla. The number of people attending that meeting has fallen, as have 
the number of people available to help fix bugs. One of the things we hear 
users report is they don't know how to help. We (the triage team) are therefore 
going to start reporting out the currently 314 unassigned bugs.



We're hoping people may be able to spare some time now and again to help out 
with these.



Bugs are split into two types, "true bugs" where things don't work as they 
should and "enhancements" which are features we'd want to add to the system.



There are also roughly three different "priority" classes right now, "2.6", 
"2.99" and "Future", the more pressing/urgent issues being in "2.6".



Please review this link and if a bug is something you would be able to help 
with either take ownership of the bug, or send me (stephen.k.jol...@intel.com) 
an e-mail with the bug number you would like and I will assign it to you 
(please make sure you have a bugzilla account).



The list is at: https://wiki.yoctoproject.org/wiki/Bug_Triage#Unassigned_Bugs


Thanks,

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

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

Re: [linux-yocto] [PATCH] bsp: Add tiny config entries for intel-x86

2018-08-20 Thread Bruce Ashfield 

merged.

Bruce

On 08/16/2018 10:18 AM, He Zhe wrote:

Signed-off-by: He Zhe 
---
  bsp/intel-x86/intel-x86-32-tiny.scc | 8 
  bsp/intel-x86/intel-x86-64-tiny.scc | 7 +++
  2 files changed, 15 insertions(+)
  create mode 100644 bsp/intel-x86/intel-x86-32-tiny.scc
  create mode 100644 bsp/intel-x86/intel-x86-64-tiny.scc

diff --git a/bsp/intel-x86/intel-x86-32-tiny.scc 
b/bsp/intel-x86/intel-x86-32-tiny.scc
new file mode 100644
index ..8949e4f3
--- /dev/null
+++ b/bsp/intel-x86/intel-x86-32-tiny.scc
@@ -0,0 +1,8 @@
+define KMACHINE intel-x86-32
+define KTYPE tiny
+define KARCH x86
+
+include ktypes/tiny/tiny.scc
+branch intel-x86
+
+include bsp/intel-x86/intel-x86-32.scc
diff --git a/bsp/intel-x86/intel-x86-64-tiny.scc 
b/bsp/intel-x86/intel-x86-64-tiny.scc
new file mode 100644
index ..696d3fcb
--- /dev/null
+++ b/bsp/intel-x86/intel-x86-64-tiny.scc
@@ -0,0 +1,7 @@
+define KMACHINE intel-x86-64
+define KTYPE tiny
+define KARCH x86
+
+include ktypes/tiny/tiny.scc
+
+include bsp/intel-x86/intel-x86-64.scc



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

Re: [yocto] bitbake firefox using meta-browser layer

2018-08-20 Thread Alexander Kanavin 
2018-08-20 15:56 GMT+02:00 Pandey, Kamal :

> cd
> /home/iepl/work/yocto_build/poky/build/tmp/work/aarch64-pdm3-linux/firefox/52.9.0esr-r0/firefox-52.9.0esr/firefox-build-dir
>
>
> | /home/iepl/work/yocto_build/poky/build/tmp/work/aarch64-
> pdm3-linux/firefox/52.9.0esr-r0/firefox-52.9.0esr/configure
> --target=aarch64-pdm3-linux --host=x86_64-linux 
> --with-toolchain-prefix=aarch64-pdm3-linux-
> --build=x86_64-linux --prefix=/usr
> | mozbuild.configure.options.InvalidOptionError: Unknown option: --build
>
> | *** Fix above errors and then restart with\
> Can anybody provide me a solution or at least a  hint, so that I can move
> forward.
>
>
>
>

The hint is in these lines. Mozilla's configure script thinks --build is
not a valid option, so you need to figure out where it's coming from, and
why it doesn't work.

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

[yocto] bitbake firefox using meta-browser layer

2018-08-20 Thread Pandey, Kamal 
I was trying to compile the Firefox browser for a custom embedded device. But 
it is falling giving the following error:

cd 
/home/iepl/work/yocto_build/poky/build/tmp/work/aarch64-pdm3-linux/firefox/52.9.0esr-r0/firefox-52.9.0esr/firefox-build-dir
| 
/home/iepl/work/yocto_build/poky/build/tmp/work/aarch64-pdm3-linux/firefox/52.9.0esr-r0/firefox-52.9.0esr/configure
 --target=aarch64-pdm3-linux --host=x86_64-linux 
--with-toolchain-prefix=aarch64-pdm3-linux- --build=x86_64-linux --prefix=/usr
| Reexecuting in the virtualenv
| Adding configure options from 
/home/iepl/work/yocto_build/poky/build/tmp/work/aarch64-pdm3-linux/firefox/52.9.0esr-r0/mozconfig
|   --enable-application=browser
|   --target=aarch64-pdm3-linux
|   --prefix=/usr
|   --enable-application=browser
|   --enable-official-branding
|   --disable-elf-hack
|   --disable-gold
|   --disable-strip
|   --disable-install-strip
|   --with-system-nss
|   --with-system-nspr
|   --with-system-zlib
|   --with-system-bz2
|   --with-system-libevent
|   --with-system-libvpx
|   --with-system-icu
|   --enable-system-ffi
|   --enable-system-pixman
|   --enable-startup-notification
|   --enable-pulseaudio
|   --disable-tests
|   --disable-necko-wifi
|   --disable-gconf
|   --disable-crashreporter
|   --disable-updater
|   --disable-debug-symbols
| checking for a shell... 
/home/iepl/work/yocto_build/poky/build/tmp/hosttools/sh
| checking for host system type... x86_64-pc-linux-gnu
| checking for target system type... aarch64-pdm3-linux-gnu
| Traceback (most recent call last):
|   File 
"/home/iepl/work/yocto_build/poky/build/tmp/work/aarch64-pdm3-linux/firefox/52.9.0esr-r0/firefox-52.9.0esr/configure.py",
 line 107, in 
| sys.exit(main(sys.argv))
|   File 
"/home/iepl/work/yocto_build/poky/build/tmp/work/aarch64-pdm3-linux/firefox/52.9.0esr-r0/firefox-52.9.0esr/configure.py",
 line 26, in main
| sandbox.run(os.path.join(os.path.dirname(__file__), 'moz.configure'))
|   File 
"/home/iepl/work/yocto_build/poky/build/tmp/work/aarch64-pdm3-linux/firefox/52.9.0esr-r0/firefox-52.9.0esr/python/mozbuild/mozbuild/configure/__init__.py",
 line 359, in run
| raise InvalidOptionError('Unknown option: %s' % without_value)
| mozbuild.configure.options.InvalidOptionError: Unknown option: --build
| *** Fix above errors and then restart with\
|"make -f client.mk build"
| client.mk:375: recipe for target 'configure' failed
| make: *** [configure] Error 1
| ERROR: oe_runmake failed
| WARNING: exit code 1 from a shell command.
| ERROR: Function failed: do_configure (log file is located at 
/home/iepl/work/yocto_build/poky/build/tmp/work/aarch64-pdm3-linux/firefox/52.9.0esr-r0/temp/log.do_configure.5847)
ERROR: Task 
(/home/iepl/work/yocto_build/meta-browser/recipes-browser/firefox/firefox_52.9.0esr.bb:do_configure)
 failed with exit code '1'

Can anybody provide me a solution or at least a  hint, so that I can move 
forward.

Best Regards
Kamal Pandey
Junior Software Engineer
[ifm_logo_sqrs]ifm engineering pvt. ltd.
Survey No. 1/10/16, 3rd floor, Above SBI, Bavdhan Branch, N.D.A. Road, Bavdhan, 
Pune, India - 411021 | Web: www.ifm.com | Phone: 
+91-20-22951910 Extn:215 | CIN: U29213PN2010FTC13676

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

Re: [yocto] [PATCH] runtime: add BSP test case for usb storage

2018-08-20 Thread Mike Looijmans 
I would not write to flash media in this test. It's pointless, if you can read 
the the device, it means that you can already send commands and data to it, 
and reading will thus test data going in both directions already. Writing to 
the media will just wear it out, and if there's a problem unmounting it, it 
may lead to a corrupted filesystem and yield unpredictable future results.



On 19-08-18 17:22, mohamad.noor.alim.hus...@intel.com wrote:

From: Mohamad Noor Alim Hussin 

Contain test cases to test mount/unmount the usb stick on target
platform such as minnowboard and beaglebone. The test assume that
the usb storage device such as usb thumb drive was plugged into
the target device otherwise the test for would failed. It also test
to read and write from usb thumb drive. Usb test cases start with
mount the usb thumb drive then write and read from it. Lastly, it
will unmount it. If the usb thumb drive unable to mount due to corrupt
of partition or not exists, then the mount test will failed and the
following test would skip.

This test need to enable flag 'HARDWARE_TEST = "1"' on conf/local.conf
file in order to run on target device. This test should be skip on qemu.

Signed-off-by: Mohamad Noor Alim Hussin 
---
  meta/lib/oeqa/runtime/cases/usb.py | 54 ++
  1 file changed, 54 insertions(+)
  create mode 100644 meta/lib/oeqa/runtime/cases/usb.py

diff --git a/meta/lib/oeqa/runtime/cases/usb.py 
b/meta/lib/oeqa/runtime/cases/usb.py
new file mode 100644
index 000..3e17645
--- /dev/null
+++ b/meta/lib/oeqa/runtime/cases/usb.py
@@ -0,0 +1,54 @@
+from oeqa.runtime.case import OERuntimeTestCase
+from oeqa.core.decorator.depends import OETestDepends
+from oeqa.core.decorator.oeid import OETestID
+from oeqa.core.decorator.data import skipIfNotDataVar
+
+class USBTest(OERuntimeTestCase):
+@classmethod
+def setUpClass(cls):
+cls.hw_test_path = '~/test'
+cls.usb_path = os.path.join(cls.hw_test_path, 'stick')
+cls.usb_file = os.path.join(cls.usb_path, 'hello_stick')
+src = os.path.join(cls.tc.runtime_files_dir, 'bsp-test-helper')
+cls.tc.target.run('mkdir -p %s' % (cls.usb_path))
+cls.tc.target.copyTo(src, '/usr/bin')
+
+@classmethod
+def tearDownClass(cls):
+cls.tc.target.run('rm -rf %s' % (cls.hw_test_path))
+
+@skipIfNotDataVar('HARDWARE_TEST','1',
+'Usb test only run on platform. It will skip on qemu.')
+@OETestID(216)
+def test_usb_mount(self):
+command = ('bsp-test-helper --mount pendrive %s' % (self.usb_path))
+status, output = self.target.run(command)
+msg = ('Unable to mount USB stick. '
+'Status and output:%s and %s.' % (status, output))
+self.assertEqual(status, 0, msg = msg)
+
+@OETestID(217)
+@OETestDepends(['usb.USBTest.test_usb_write_file'])
+def test_usb_read_file(self):
+command = ('cat %s' % (self.usb_file))
+status, output = self.target.run(command)
+msg = ('Unable to read file from USB stick. '
+'Status and output:%s and %s.' % (status, output))
+self.assertEqual(status, 0, msg = msg)
+
+@OETestDepends(['usb.USBTest.test_usb_mount'])
+@OETestID(219)
+def test_usb_write_file(self):
+command = ('echo hello_world > %s' % (self.usb_file))
+status, output = self.target.run(command)
+msg = ('Status and  output:%s and %s.' % (status, output))
+self.assertEqual(status, 0, msg = msg)
+
+@OETestDepends(['usb.USBTest.test_usb_mount'])
+@OETestID(218)
+def test_usb_unmount(self):
+command = ('bsp-test-helper --umount %s' % (self.usb_path))
+status, output = self.target.run(command)
+msg = ('Unable to unmount USB stick. '
+'Status and output:%s and %s.' % (status, output))
+self.assertEqual(status, 0, msg = msg)



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

Re: [yocto] coreutils postinstall warning

2018-08-20 Thread Seth Bollinger 
On Mon, Aug 20, 2018 at 8:31 AM Alexander Kanavin 
wrote:

> 2018-08-20 15:16 GMT+02:00 Seth Bollinger :
> > We've been seeing the following warning for a while now.  Is this
> expected?
> >
> > WARNING: manuf-image-1.0-r0 do_rootfs: Intentionally failing postinstall
> > scriptlets of ['coreutils'] to defer them to first boot is deprecated.
> > Please place them into pkg_postinst_ontarget_${PN} ().
> >
> > From what I can see, it's being caused by update-alternatives.  Is there
> a
> > workaround for this?
>
> You need to investigate further, specifically why the postinst
> scriptlet is failing. Usually log.do_rootfs should give a hint.
>

This seems to be the issue.  I should mention this is sumo coreutils.

update-alternatives: renaming link link from /bin/link to /usr/bin/link
mv: cannot stat '/bin/link': No such file or directory
warning: %post(coreutils-8.29-r0.7.aarch64) scriptlet failed, exit status 1

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

Re: [yocto] coreutils postinstall warning

2018-08-20 Thread Alexander Kanavin 
2018-08-20 15:16 GMT+02:00 Seth Bollinger :
> We've been seeing the following warning for a while now.  Is this expected?
>
> WARNING: manuf-image-1.0-r0 do_rootfs: Intentionally failing postinstall
> scriptlets of ['coreutils'] to defer them to first boot is deprecated.
> Please place them into pkg_postinst_ontarget_${PN} ().
>
> From what I can see, it's being caused by update-alternatives.  Is there a
> workaround for this?

You need to investigate further, specifically why the postinst
scriptlet is failing. Usually log.do_rootfs should give a hint.

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

[yocto] coreutils postinstall warning

2018-08-20 Thread Seth Bollinger 
Hello All,

We've been seeing the following warning for a while now.  Is this expected?

WARNING: manuf-image-1.0-r0 do_rootfs: Intentionally failing postinstall
scriptlets of ['coreutils'] to defer them to first boot is deprecated.
Please place them into pkg_postinst_ontarget_${PN} ().

>From what I can see, it's being caused by update-alternatives.  Is there a
workaround for this?

Thanks,

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

[yocto] Fwd: Doubts about image "equalness"

2018-08-20 Thread Alan Martinovic 
Hey Matthias,
thanks for the response

> it seems a non trivial task to generate an image out
> of another image by hand. So much, that can get messed up (permissions,
> owner...).

I don't see it as that big of a problem.
In our case it would end up mounting the production image and editing
config files
to i.e.
enable ssh, point to a different logging server, have the debug log level...

The overhead is that it would have to be done manually after the production
image is build, where as believing in yocto would mean a single build step :)


> We try to
> automatize the tests as much as possible. If a test on production fails,
> we retest with debug image to see what went wrong...


For us the case problematic case is the beta testing that happens in
field with selected customers. Can't automate that much :)

> We opt to build both images through
yocto / openembedded.

Have you so far experienced issues in which the images behaved differently
besides the obvious changes that you wanted?

Be Well,
Alan

On Mon, Aug 20, 2018 at 1:46 PM, Matthias Schoepfer
 wrote:
> Hi Alan,
>
> we face the same problems here. We opt to build both images through
> yocto / openembedded. If you look at the tools and steps needed, to
> generate an image, it seems a non trivial task to generate an image out
> of another image by hand. So much, that can get messed up (permissions,
> owner...).
>
> I think, there is no way around to test production image. We try to
> automatize the tests as much as possible. If a test on production fails,
> we retest with debug image to see what went wrong...
>
> Regards,
>
> Matthias
>
>
> On 08/17/2018 10:35 AM, Alan Martinovic wrote:
>> Hi,
>> I'm hoping to get opinions on a doubt regarding a certain yocto related
>> problem.
>>
>> We have a following images in place:
>>
>> * production-image.bb
>> * core features, max security
>>
>> * beta-image.bb
>> * require production-image.bb
>> * added logging, reduced security for dev intervention
>>
>>
>> At the moment, we first build the beta end if all is good we again build the
>> production.
>> This means we need to build and test twice even when no flaws are found in 
>> the
>> beta image.
>>
>> We do that because, not knowing the internals of yocto enough,
>> it seems to risky to run the tests on the beta-image and afterwards
>> just ship the production-image assuming they are the same.
>>
>> Because of that, a second approach has been suggested in which yocto
>> doesn't build the beta-image, but it gets created by manually modifying the
>> built production-image binary.
>>
>> The core problem is we don't know the core of yocto that well to vouch
>> for the yocto option, on the other hand, this could be just a
>> psychological problem
>> and the manual approach is as dangerous if not worse :)
>>
>> Did anyone how similar problems?
>> Would like to hear your opinions on how you approached them?
>>
>> Be Well,
>> Alan
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] ptest-runner "No ptests found."

2018-08-20 Thread Alexander Kanavin 
2018-08-20 14:07 GMT+02:00 Nader Hariri :
> So,  contrary to what is stated in the ptest wiki and the yocto
> documentation, using EXTRA_IMAGE_FEATURES doesn't install ptests packages
> (from ptest-enabled recipes) in my image, and I can't figure out why ..

You can run 'bitbake -e ' to figure out why
EXTRA_IMAGE_FEATURES has no effect. In my tests (poky master) it seems
to work as intended:

#
# $IMAGE_FEATURES [8 operations]
#   append /home/alexander/development/meta-qt5/conf/layer.conf:36
# [validitems] "qtcreator-debug"
#   set? 
/home/alexander/development/poky/meta/conf/distro/include/default-distrovars.inc:24
# ""
#   set /home/alexander/development/poky/meta/conf/documentation.conf:208
# [doc] "The primary list of features to include in an image.
Configure this variable in an image recipe."
#   append /home/alexander/development/poky/meta/conf/bitbake.conf:812
# "${EXTRA_IMAGE_FEATURES}"
#   set? /home/alexander/development/poky/meta/classes/image.bbclass:34
# ""
#   set /home/alexander/development/poky/meta/classes/image.bbclass:35
# [type] "list"
#   append /home/alexander/development/poky/meta/classes/image.bbclass:36
# [validitems] "debug-tweaks read-only-rootfs empty-root-password
allow-empty-password allow-root-login post-install-logging"
#   set image.bbclass:166
[__anon_168__home_alexander_development_poky_meta_classes_image_bbclass]
# "debug-tweaks"
# pre-expansion value:
#   "debug-tweaks"
IMAGE_FEATURES="debug-tweaks"


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

Re: [yocto] ptest-runner "No ptests found."

2018-08-20 Thread Alexander Kanavin 
2018-08-16 16:07 GMT+02:00 Nader Hariri :
> Hi, I am new to Yocto. I am working on ptest-runner.
>
> I followed the wiki https://wiki.yoctoproject.org/wiki/Ptest , but when I
> boot to my image and run ptest-runner I have the output : "No ptests found."
>
> Is this normal ? I thought that
>
> DISTRO_FEATURES_append = " ptest"
>
> and
>
> EXTRA_IMAGE_FEATURES += "ptest-pkgs"
>
>  would install all the ptests for me in my image, apparently I am wrong but
> could you please explain to me why this is not the case i.e why ptests are
> not automatically installed in the image even though I included the above
> lines in my local.conf ?

Please note that ptests are only supported by a (small) subset of
recipes. If none of the packages that are in your image are
ptest-enabled, then no ptests will go to the image. Is there a recipe
in particular for which you expected ptests to be in the image, and
they're not?

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

Re: [yocto] Issue with Doc-utils

2018-08-20 Thread Alexander Kanavin 
2018-08-18 11:06 GMT+02:00 Sarayu Sivanandam :

> | make[2]: *** [docbook2man.html] Segmentation fault (core dumped)
> | make[2]: *** Waiting for unfinished jobs
> | Makefile:458: recipe for target 'api.html' failed
> | make[2]: *** [api.html] Segmentation fault (core dumped)
> | Makefile:458: recipe for target 'docbook2texi.html' failed
> | make[2]: *** [docbook2texi.html] Segmentation fault (core dumped)
> | Makefile:458: recipe for target 'backend-spec.html' failed
> | make[2]: *** [backend-spec.html] Segmentation fault (core dumped)

You need to find the coredump and inspect it with gdb. That's not a
specific yocto failure.

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

[yocto] PyBuild based OpenEmbedded/BitBake recipe

2018-08-20 Thread bernardo araujo rodrigues 
Hey everyone.

I need to port PhantomJS  to be cross
compiled inside the OpenEmbedded/BitBake system.

Looking at PhantomJS' github repo (https://github.com/ariya/phantomjs), I
realized it's a PyBuild based project. However, I couldn't find any BitBake
class like the setuptools or pypi that would support the build.py script.

Does anyone know whether porting PyBuild projects to BitBake is even
possible? If not, why?
Regards,
Bernardo Araujo Rodrigues

Electronics Engineer | Engenheiro Eletrônico
Electrical and Computer Engineering Masters Candidate | Mestrando em
Engenharia Elétrica e de Computação.

Mobile | Celular: +1 626 545 6598
Skype: bernardoaraujor44
GitHub: https://github.com/bernardoaraujor
LinkedIn: https://www.linkedin.com/in/bernardoaraujor/
ResearchGate: https://www.researchgate.net/profile/Bernardo_Rodrigues3
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Issue with Doc-utils

2018-08-20 Thread Sarayu Sivanandam 
Hi ,

I am trying to compile docbook utils with the below recipe
recipes-devtools/docbook-utils/docbook-utils-native_0.6.14.bb

on my latest ubuntu setup ( 18.04)  and i am seeing the below errors. Can
you please help me with the same.

Log data follows:
| DEBUG: Executing shell function do_compile
| NOTE: make -j 4
| Making all in backends
| make[1]: Entering directory
'/home/sarayu/code/yocto_arm/QorIQ-SDK-V2.0-20160527-yocto/build_ls1043ardb/tmp/work/x86_64-linux/docbook-utils-native/0.6.14-r3/build/backends'
| make[1]: Nothing to be done for 'all'.
| make[1]: Leaving directory
'/home/sarayu/code/yocto_arm/QorIQ-SDK-V2.0-20160527-yocto/build_ls1043ardb/tmp/work/x86_64-linux/docbook-utils-native/0.6.14-r3/build/backends'
| Making all in bin
| make[1]: Entering directory
'/home/sarayu/code/yocto_arm/QorIQ-SDK-V2.0-20160527-yocto/build_ls1043ardb/tmp/work/x86_64-linux/docbook-utils-native/0.6.14-r3/build/bin'
| make[1]: Nothing to be done for 'all'.
| make[1]: Leaving directory
'/home/sarayu/code/yocto_arm/QorIQ-SDK-V2.0-20160527-yocto/build_ls1043ardb/tmp/work/x86_64-linux/docbook-utils-native/0.6.14-r3/build/bin'
| Making all in doc
| make[1]: Entering directory
'/home/sarayu/code/yocto_arm/QorIQ-SDK-V2.0-20160527-yocto/build_ls1043ardb/tmp/work/x86_64-linux/docbook-utils-native/0.6.14-r3/build/doc'
| Making all in refentry
| make[2]: Entering directory
'/home/sarayu/code/yocto_arm/QorIQ-SDK-V2.0-20160527-yocto/build_ls1043ardb/tmp/work/x86_64-linux/docbook-utils-native/0.6.14-r3/build/doc/refentry'
| make[2]: Nothing to be done for 'all'.
| make[2]: Leaving directory
'/home/sarayu/code/yocto_arm/QorIQ-SDK-V2.0-20160527-yocto/build_ls1043ardb/tmp/work/x86_64-linux/docbook-utils-native/0.6.14-r3/build/doc/refentry'
| Making all in man
| make[2]: Entering directory
'/home/sarayu/code/yocto_arm/QorIQ-SDK-V2.0-20160527-yocto/build_ls1043ardb/tmp/work/x86_64-linux/docbook-utils-native/0.6.14-r3/build/doc/man'
| make[2]: Nothing to be done for 'all'.
| make[2]: Leaving directory
'/home/sarayu/code/yocto_arm/QorIQ-SDK-V2.0-20160527-yocto/build_ls1043ardb/tmp/work/x86_64-linux/docbook-utils-native/0.6.14-r3/build/doc/man'
| Making all in HTML
| make[2]: Entering directory
'/home/sarayu/code/yocto_arm/QorIQ-SDK-V2.0-20160527-yocto/build_ls1043ardb/tmp/work/x86_64-linux/docbook-utils-native/0.6.14-r3/build/doc/HTML'
|
SGML_CATALOG_FILES=/home/sarayu/code/yocto_arm/QorIQ-SDK-V2.0-20160527-yocto/build_ls1043ardb/tmp/sysroots/x86_64-linux/etc/sgml/catalog
\
|
SGML_SEARCH_PATH=/home/sarayu/code/yocto_arm/QorIQ-SDK-V2.0-20160527-yocto/build_ls1043ardb/tmp/work/x86_64-linux/docbook-utils-native/0.6.14-r3/docbook-utils-0.6.14:/home/sarayu/code/yocto_arm/QorIQ-SDK-V2.0-20160527-yocto/build_ls1043ardb/tmp/work/x86_64-linux/docbook-utils-native/0.6.14-r3/docbook-utils-0.6.14/doc:..
\
| jade -t sgml -i html -d
/home/sarayu/code/yocto_arm/QorIQ-SDK-V2.0-20160527-yocto/build_ls1043ardb/tmp/work/x86_64-linux/docbook-utils-native/0.6.14-r3/docbook-utils-0.6.14/docbook-utils.dsl\#html
\
| -V '%use-id-as-filename%'
/home/sarayu/code/yocto_arm/QorIQ-SDK-V2.0-20160527-yocto/build_ls1043ardb/tmp/work/x86_64-linux/docbook-utils-native/0.6.14-r3/docbook-utils-0.6.14/doc/docbook-utils.sgml
|
SGML_CATALOG_FILES=/home/sarayu/code/yocto_arm/QorIQ-SDK-V2.0-20160527-yocto/build_ls1043ardb/tmp/sysroots/x86_64-linux/etc/sgml/catalog
\
|
SGML_SEARCH_PATH=/home/sarayu/code/yocto_arm/QorIQ-SDK-V2.0-20160527-yocto/build_ls1043ardb/tmp/work/x86_64-linux/docbook-utils-native/0.6.14-r3/docbook-utils-0.6.14:/home/sarayu/code/yocto_arm/QorIQ-SDK-V2.0-20160527-yocto/build_ls1043ardb/tmp/work/x86_64-linux/docbook-utils-native/0.6.14-r3/docbook-utils-0.6.14/doc:..
\
| jade -t sgml -i html -d
/home/sarayu/code/yocto_arm/QorIQ-SDK-V2.0-20160527-yocto/build_ls1043ardb/tmp/work/x86_64-linux/docbook-utils-native/0.6.14-r3/docbook-utils-0.6.14/docbook-utils.dsl\#html
\
| -V '%use-id-as-filename%'
/home/sarayu/code/yocto_arm/QorIQ-SDK-V2.0-20160527-yocto/build_ls1043ardb/tmp/work/x86_64-linux/docbook-utils-native/0.6.14-r3/docbook-utils-0.6.14/doc/docbook-utils.sgml
|
SGML_CATALOG_FILES=/home/sarayu/code/yocto_arm/QorIQ-SDK-V2.0-20160527-yocto/build_ls1043ardb/tmp/sysroots/x86_64-linux/etc/sgml/catalog
\
|
SGML_SEARCH_PATH=/home/sarayu/code/yocto_arm/QorIQ-SDK-V2.0-20160527-yocto/build_ls1043ardb/tmp/work/x86_64-linux/docbook-utils-native/0.6.14-r3/docbook-utils-0.6.14:/home/sarayu/code/yocto_arm/QorIQ-SDK-V2.0-20160527-yocto/build_ls1043ardb/tmp/work/x86_64-linux/docbook-utils-native/0.6.14-r3/docbook-utils-0.6.14/doc:..
\
| jade -t sgml -i html -d
/home/sarayu/code/yocto_arm/QorIQ-SDK-V2.0-20160527-yocto/build_ls1043ardb/tmp/work/x86_64-linux/docbook-utils-native/0.6.14-r3/docbook-utils-0.6.14/docbook-utils.dsl\#html
\
| -V '%use-id-as-filename%'

Re: [yocto] Yocto userbase in numbers?

2018-08-20 Thread Joe Steeve 
On Thu, 2018-08-09 at 21:43 +0100, Richard Purdie wrote:
> Even if you just look at the fields the project is used in based on the
> project's members like Comcast, the automotive industry (e.g.
> Automotive Grade Linux), several major OS vendors (Windriver, Mentor
> Graphics, Montavista, ENEA) and in TVs (LG), the deployment of the
> project is significant

We shipped a Yocto built netboot target for a customer which has already seen
~1M machines so far :P

-- 
Joe Steeve
HiPro IT Solutions Private Limited
http://www.hipro.co.in/


signature.asc
Description: This is a digitally signed message part
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto