Re: [yocto] Mpich and yocto ?

[Riko Ho]

Dear Yocto Team Member,

Thanks for the reply,

So :

"YP+distcc/icecream" is equal to MpichCluster ? or that one is inside 
MpichCluster,


I have tested :

https://help.ubuntu.com/community/MpichCluster

I don't have a fancy systems as you said below, but I have a spare 
motherboards, memories and hard drives for a test on a small cluster, at 
least making my compilation time faster and get more space.


Ok, I'll have a look on those links below and keep posted, thanks.



On 27/07/17 09:10, Randy MacLeod wrote:

On 2017-07-26 08:08 PM, Riko Ho wrote:

Dear Yocto Team Member,

The cluster is using Ubuntu.
I haven't checked all the packages on the other computer. I will.

My goal is getting more hardrive space and compiling speed.

How can I relate bitbake with mpicc or other compilers needed by 
yocto (arm-linux-gcc, gcc, etc)?


Do you mean that you want to do part of the build using each node in 
the cluster? That's possible now using distcc/icecream

(https://github.com/icecc/icecream ) but I haven't done it in years
as explained below.

Oh, there's a Stack Overflow entry for YP+distcc/icecream:

https://stackoverflow.com/questions/14472175/distributed-compile-with-bitbake 



and distcc is mentioned in the docs:
   http://www.yoctoproject.org/docs/2.3/dev-manual/dev-manual.html


Anyway, this just distributes the compilation so:
 - build management,
 - recipe download, unpack, patch, configuring and packaging,
 - linking, etc
are still done centrally.

There are plans to improve the bitbake task manager so that, with
the recipe specific sysroot work that has been done in 2.2, we'd be
able to farm out all of the stages of a package's build to individual
nodes in a cluster:
   https://bugzilla.yoctoproject.org/show_bug.cgi?id=10684
I don't know if that work is a priority for the fall 2.4 release.

Note that depending on your workload, inter-recipe dependencies and
the long time taken to run configure for autotools-based packages is
the bottleneck. Therefore, buying a high-end ( >= 16+16 core )
system with lots (64GB+) RAM and a good IO sub-system results
in core-image-minimal building quickly, certainly under 40 minutes.
   https://wiki.yoctoproject.org/wiki/Build_Performance

Also for repeated builds by one or more developers, sstate-cache is
a huge speed-up with some cost in scripts and people to manage it.


I've wondered if anyone has played with bitbake on an OS that is
known as a single-system image:
   https://en.wikipedia.org/wiki/Single_system_image
On these systems, jobs are transparently moved from the master-node
to idle nodes in the cluster by the operating system. That would be
an interesting academic exercise but it wouldn't be useful in
practice since such OSs are not generally used as far as I know at
least.

I look forward to hearing what your goals and plans are.

../Randy




I have tested a small code with mpicc and the cluster do the job.

Thanks for the attention.

On Jul 27, 2017 3:23 AM, "Randy MacLeod" > wrote:

 >
 > On 2017-07-26 02:09 AM, Riko Ho wrote:
 >>
 >> How can we do that ?
 >>
 >> bitbake in which node ? I don't understand ?
 >>
 >>
 >> On 26/07/17 13:57, Josef Holzmayr wrote:
 >>>
 >>> Hi
 >>>
 >>> On 26.07.2017 05:12, Riko Ho wrote:
 
  Does anyone know on how to run poky on mpich cluster ?
 >
 >
 > That's a rather ambiguous question.
 >
 > What OS/Distro is the mpich cluster running?
 > Have you installed the packages that are required on the host:
 >see: "The Build Host Packages" here:
 >
 > 
http://www.yoctoproject.org/docs/2.3/yocto-project-qs/yocto-project-qs.html

 >
 > What do you hope to achieve using bitbake?
 >
 >
 >>>
 >>> As far as I can see, MPICH is a userland library, basically. So 
it would be the other way round, you could probably run a mpich 
application on a number of nodes that run some OE/Poky thing.

 >>>
 >>> Greetz
 >
 >
 > There is an mpich recipe here:
 > http://layers.openembedded.org/layerindex/recipe/33348/
 >
 > but again, it's not clear what your ultimate goal is.
 >
 > ../Randy
 >
 >>
 >> --
 >> *
 >>
 >>
 >> /***/
 >> Sent by Ubuntu LTS 16.04,
 >> Kind regards,
 >> Riko Ho
 >> /***/
 >>
 >> *
 >>
 >>
 >
 >
 > --
 > # Randy MacLeod. SMTS, Linux, Wind River
 > Direct: 613.963.1350 | 350 Terry Fox Drive, Suite 200, Ottawa, ON, 
Canada, K2K 2W5







--
*

/***/
Sent by Ubuntu LTS 16.04,
Kind regards,
Riko Ho
/***/

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

[yocto] [yocto-autobuilder][PATCH] /buildset-config.meta-intel/*.conf

[Graydon, Tracy]

Update meta-intel buildsets to reflect current production versions:

- Change various SRCREVs to default to blank instead of linux-yocto or AUTOREV.

Signed-off-by: Graydon, Tracy 
---
 .../intel-core2-32-lsb-rt.conf | 12 +-
 buildset-config.meta-intel/intel-core2-32-lsb.conf | 10 -
 buildset-config.meta-intel/intel-core2-32-rt.conf  | 12 +-
 buildset-config.meta-intel/intel-core2-32.conf | 10 -
 .../intel-corei7-64-lsb-rt.conf| 12 +-
 .../intel-corei7-64-lsb.conf   | 10 -
 buildset-config.meta-intel/intel-corei7-64-rt.conf | 12 +-
 buildset-config.meta-intel/intel-corei7-64.conf| 10 -
 .../nightly-meta-intel-world.conf  | 10 -
 buildset-config.meta-intel/nightly-musl.conf   | 17 +++---
 buildset-config.meta-intel/nightly-x32.conf| 26 ++
 11 files changed, 70 insertions(+), 71 deletions(-)

diff --git a/buildset-config.meta-intel/intel-core2-32-lsb-rt.conf 
b/buildset-config.meta-intel/intel-core2-32-lsb-rt.conf
index 6e5d794..365c437 100644
--- a/buildset-config.meta-intel/intel-core2-32-lsb-rt.conf
+++ b/buildset-config.meta-intel/intel-core2-32-lsb-rt.conf
@@ -1,5 +1,5 @@
 [intel-core2-32-lsb-rt]
-builders: 'example-worker'
+builders: ['example-worker']
 repos: [{'poky':
 {'repourl':'git://git.yoctoproject.org/poky',
  'layerversion':{'core':'meta', 'yoctobsp':'meta-yocto-bsp', 
'yocto':'meta-yocto', 'poky':'meta-poky'},
@@ -22,8 +22,8 @@ props: [{'kmeta':{'prop_type':'StringParameter',
 {'srcrev_meta':{'prop_type':'StringParameter',
'size': 15,
'name': 'srcrev_meta',
-   'default': '${AUTOREV}',
-   'label':' SRCREV for KMETA_${MACHINE} (default 
is ${AUTOREV}):'}},
+   'default': '',
+   'label':' SRCREV for KMETA_${MACHINE} (default 
is blank):'}},
 {'srcuri_meta':{'prop_type':'StringParameter',
'size': 50,
'name': 'srcuri_meta',
@@ -37,8 +37,8 @@ props: [{'kmeta':{'prop_type':'StringParameter',
 {'srcrev_machine':{'prop_type':'StringParameter',
'size': 15,
'name': 'srcrev_machine',
-   'default': '${AUTOREV}',
-   'label':' SRCREV for KBRANCH. (default is 
${AUTOREV}):'}},
+   'default': '',
+   'label':' SRCREV for KBRANCH. (default is 
blank}):'}},
 {'srcuri_machine':{'prop_type':'StringParameter',
'size': 50,
'name': 'srcuri_machine',
@@ -56,7 +56,7 @@ steps: [{'SetDest':{}},
 {'CreateAutoConf': {'machine': 'intel-core2-32',
 'SDKMACHINE' : 'x86_64',
 'distro': 'poky-lsb',
-'atextappend' : 
'\nPREFERRED_PROVIDER_virtual/kernel = "linux-yocto-rt"\n'}},
+'atextappend' : 
'\nPREFERRED_PROVIDER_virtual/kernel_linuxstdbase = "linux-intel-rt"\n'}},
 {'AddKernelProps': {}},
 {'BuildImages': {'images': 'core-image-rt'}},
 {'PublishLayerTarballs':{}},
diff --git a/buildset-config.meta-intel/intel-core2-32-lsb.conf 
b/buildset-config.meta-intel/intel-core2-32-lsb.conf
index 5cb608f..cea5962 100644
--- a/buildset-config.meta-intel/intel-core2-32-lsb.conf
+++ b/buildset-config.meta-intel/intel-core2-32-lsb.conf
@@ -1,5 +1,5 @@
 [intel-core2-32-lsb]
-builders: 'example-worker'
+builders: ['example-worker']
 repos: [{'poky':
 {'repourl':'git://git.yoctoproject.org/poky',
  'layerversion':{'core':'meta', 'yoctobsp':'meta-yocto-bsp', 
'yocto':'meta-yocto', 'poky':'meta-poky'},
@@ -22,8 +22,8 @@ props: [{'kmeta':{'prop_type':'StringParameter',
 {'srcrev_meta':{'prop_type':'StringParameter',
'size': 15,
'name': 'srcrev_meta',
-   'default': '${AUTOREV}',
-   'label':' SRCREV for KMETA_${MACHINE} (default 
is ${AUTOREV}):'}},
+   'default': '',
+   'label':' SRCREV for KMETA_${MACHINE} (default 
is blank):'}},
 {'srcuri_meta':{'prop_type':'StringParameter',
'size': 50,
'name': 'srcuri_meta',
@@ -37,8 +37,8 @@ props: [{'kmeta':{'prop_type':'StringParameter',
 {'srcrev_machine':{'prop_type':'StringParameter',
'size': 15,
'name': 'srcrev_machine',
-   'default': '${AUTOREV}',
-   'label':' SRCREV for KBRANCH. (default is 
${AUTOREV}):'}},
+   'default': '',
+   'label':' SRCREV for KBRANCH. (default is 

[yocto] [yocto-autobuilder][PATCH] /buildset-config.meta-intel/yoctoAB.conf

[Graydon, Tracy]

Remove the deprecated configs for jasperforest, crownbay, sugarbay, and nuc.

Signed-off-by: Graydon, Tracy 
---
 buildset-config.meta-intel/yoctoAB.conf | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/buildset-config.meta-intel/yoctoAB.conf 
b/buildset-config.meta-intel/yoctoAB.conf
index 7ad8cc7..cf959e8 100644
--- a/buildset-config.meta-intel/yoctoAB.conf
+++ b/buildset-config.meta-intel/yoctoAB.conf
@@ -2,5 +2,4 @@
 order: ['nightly-meta-intel', 'nightly-meta-intel-world', 'nightly-musl',
 'nightly-x32', 'intel-corei7-64', 'intel-corei7-64-lsb', 
 'intel-corei7-64-rt', 'intel-corei7-64-lsb-rt', 'intel-core2-32', 
-'intel-core2-32-rt', 'intel-core2-32-lsb-rt', 'intel-quark', 
-'nuc', 'nuc-lsb', 'sugarbay', 'sugarbay-lsb']
+'intel-core2-32-rt', 'intel-core2-32-lsb-rt', 'intel-quark']
-- 
2.7.0

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

[yocto] [yocto-autobuilder][PATCH] /buildset-config.meta-intel/nightly-meta-intel.conf

[Graydon, Tracy]

Update nightl-meta-intel.conf to reflect what is currently being
used in production.

- Drop deprecated crownbay, jasperforest, sugarbay, and nuc -related stuff.
- Change various SRCREVs to use blank as default instead of linux-yocto or
AUTOREV.

Signed-off-by: Graydon, Tracy 
---
 buildset-config.meta-intel/nightly-meta-intel.conf | 32 --
 1 file changed, 11 insertions(+), 21 deletions(-)

diff --git a/buildset-config.meta-intel/nightly-meta-intel.conf 
b/buildset-config.meta-intel/nightly-meta-intel.conf
index 53c59ed..492aa89 100644
--- a/buildset-config.meta-intel/nightly-meta-intel.conf
+++ b/buildset-config.meta-intel/nightly-meta-intel.conf
@@ -1,5 +1,5 @@
 [nightly-meta-intel]
-builders: 'example-worker'
+builders: ['example-worker']
 repos: [{'poky':
 {'repourl':'git://git.yoctoproject.org/poky',
  'layerversion':{'core':'meta', 'yoctobsp':'meta-yocto-bsp', 
'yocto':'meta-yocto', 'poky':'meta-poky'},
@@ -53,8 +53,9 @@ props: [{'release_me':{'prop_type':'ChoiceStringParameter',
 {'prefered_kernel':{'prop_type':'StringParameter',
'size': 15,
'name': 'prefered_kernel',
-   'default': 'linux-yocto',
-   'label':' PREFERRED_PROVIDER_virtual/kernel 
(default is "linux-yocto"):'}},
+   #'default': 'linux-yocto',
+   'default': '',
+   'label':' PREFERRED_PROVIDER_virtual/kernel 
(default is blank):'}},
 {'kmeta':{'prop_type':'StringParameter',
'size': 15,
'name': 'kmeta',
@@ -63,8 +64,8 @@ props: [{'release_me':{'prop_type':'ChoiceStringParameter',
 {'srcrev_meta':{'prop_type':'StringParameter',
'size': 15,
'name': 'srcrev_meta',
-   'default': '${AUTOREV}',
-   'label':' SRCREV for KMETA_${MACHINE} (default 
is ${AUTOREV}):'}},
+   'default': '',
+   'label':' SRCREV for KMETA_${MACHINE} (default 
is blank):'}},
 {'srcuri_meta':{'prop_type':'StringParameter',
'size': 50,
'name': 'srcuri_meta',
@@ -78,8 +79,8 @@ props: [{'release_me':{'prop_type':'ChoiceStringParameter',
 {'srcrev_machine':{'prop_type':'StringParameter',
'size': 15,
'name': 'srcrev_machine',
-   'default': '${AUTOREV}',
-   'label':' SRCREV for KBRANCH. (default is 
${AUTOREV}):'}},
+   'default': '',
+   'label':' SRCREV for KBRANCH. (default is 
blank):'}},
 {'srcuri_machine':{'prop_type':'StringParameter',
'size': 50,
'name': 'srcuri_machine',
@@ -89,27 +90,16 @@ props: [{'release_me':{'prop_type':'ChoiceStringParameter',
 steps: [{'SetDest':{}},
 {'CheckOutLayers': {}},
 {'RunPreamble': {}},
-{'TriggerBuilds': {'schedulerName': 'main-build', 'waitForFinish': 
'True', 
+{'TriggerBuilds': {'copy_properties': ['custom_deploy_artifacts', 
'custom_prefered_kernel', 'custom_kmeta', 'custom_kbranch', 
'custom_srcrev_meta', 'custom_srcrev_machine', 'custom_srcuri_meta', 
'custom_srcuri_machine'],
+   'schedulerName': 'main-build', 'waitForFinish': 
'True', 
'schedulerNames': {'intel-core2-32':{}, 
'intel-core2-32-lsb':{}, 
  'intel-core2-32-lsb-rt':{}, 
'intel-core2-32-rt':{},
  'intel-corei7-64':{}, 'intel-corei7-64-lsb':{},
  'intel-corei7-64-lsb-rt':{}, 
'intel-corei7-64-rt':{}, 
  'intel-quark':{}, 'nightly-musl':{}, 
'nightly-x32':{},
- 'jasperforest':{}, 'jasperforest-lsb':{},
- 'sugarbay':{}, 'sugarbay-lsb':{},
- 'nuc':{}, 'nuc-lsb':{}}, 'schedulerNames_nowait' 
: {'nightly-meta-intel-world':{,
+ 'schedulerNames_nowait' : 
{'nightly-meta-intel-world':{,
 {'CreateIntelBSPPackage': {'machine': 'intel-core2-32'}},
 {'CreateIntelBSPPackage': {'machine': 'intel-corei7-64'}},
 {'CreateIntelBSPPackage': {'machine': 'intel-quark'}}, 
-{'CreateIntelBSPPackage': {'machine': 'crownbay'}},
-{'CreateIntelBSPPackage': {'machine': 'crownbay-noemgd'}},
-{'CreateIntelBSPPackage': {'machine': 'emenlow'}},
-{'CreateIntelBSPPackage': {'machine': 'emenlow-noemgd'}},
-{'CreateIntelBSPPackage': {'machine': 'fri2'}},
-{'CreateIntelBSPPackage': {'machine': 'fri2-noemgd'}},
-{'CreateIntelBSPPackage': {'machine': 'jasperforest'}},
-{'CreateIntelBSPPackage': {'machine': 'romley'}},
-

Re: [yocto] Mpich and yocto ?

[Randy MacLeod]

On 2017-07-26 08:08 PM, Riko Ho wrote:

Dear Yocto Team Member,

The cluster is using Ubuntu.
I haven't checked all the packages on the other computer. I will.

My goal is getting more hardrive space and compiling speed.

How can I relate bitbake with mpicc or other compilers needed by yocto 
(arm-linux-gcc, gcc, etc)?


Do you mean that you want to do part of the build using each node in the 
cluster? That's possible now using distcc/icecream

(https://github.com/icecc/icecream ) but I haven't done it in years
as explained below.

Oh, there's a Stack Overflow entry for YP+distcc/icecream:

https://stackoverflow.com/questions/14472175/distributed-compile-with-bitbake

and distcc is mentioned in the docs:
   http://www.yoctoproject.org/docs/2.3/dev-manual/dev-manual.html


Anyway, this just distributes the compilation so:
 - build management,
 - recipe download, unpack, patch, configuring and packaging,
 - linking, etc
are still done centrally.

There are plans to improve the bitbake task manager so that, with
the recipe specific sysroot work that has been done in 2.2, we'd be
able to farm out all of the stages of a package's build to individual
nodes in a cluster:
   https://bugzilla.yoctoproject.org/show_bug.cgi?id=10684
I don't know if that work is a priority for the fall 2.4 release.

Note that depending on your workload, inter-recipe dependencies and
the long time taken to run configure for autotools-based packages is
the bottleneck. Therefore, buying a high-end ( >= 16+16 core )
system with lots (64GB+) RAM and a good IO sub-system results
in core-image-minimal building quickly, certainly under 40 minutes.
   https://wiki.yoctoproject.org/wiki/Build_Performance

Also for repeated builds by one or more developers, sstate-cache is
a huge speed-up with some cost in scripts and people to manage it.


I've wondered if anyone has played with bitbake on an OS that is
known as a single-system image:
   https://en.wikipedia.org/wiki/Single_system_image
On these systems, jobs are transparently moved from the master-node
to idle nodes in the cluster by the operating system. That would be
an interesting academic exercise but it wouldn't be useful in
practice since such OSs are not generally used as far as I know at
least.

I look forward to hearing what your goals and plans are.

../Randy




I have tested a small code with mpicc and the cluster do the job.

Thanks for the attention.

On Jul 27, 2017 3:23 AM, "Randy MacLeod" > wrote:

 >
 > On 2017-07-26 02:09 AM, Riko Ho wrote:
 >>
 >> How can we do that ?
 >>
 >> bitbake in which node ? I don't understand ?
 >>
 >>
 >> On 26/07/17 13:57, Josef Holzmayr wrote:
 >>>
 >>> Hi
 >>>
 >>> On 26.07.2017 05:12, Riko Ho wrote:
 
  Does anyone know on how to run poky on mpich cluster ?
 >
 >
 > That's a rather ambiguous question.
 >
 > What OS/Distro is the mpich cluster running?
 > Have you installed the packages that are required on the host:
 >see: "The Build Host Packages" here:
 >
 > 
http://www.yoctoproject.org/docs/2.3/yocto-project-qs/yocto-project-qs.html

 >
 > What do you hope to achieve using bitbake?
 >
 >
 >>>
 >>> As far as I can see, MPICH is a userland library, basically. So it 
would be the other way round, you could probably run a mpich application 
on a number of nodes that run some OE/Poky thing.

 >>>
 >>> Greetz
 >
 >
 > There is an mpich recipe here:
 > http://layers.openembedded.org/layerindex/recipe/33348/
 >
 > but again, it's not clear what your ultimate goal is.
 >
 > ../Randy
 >
 >>
 >> --
 >> *
 >>
 >>
 >> /***/
 >> Sent by Ubuntu LTS 16.04,
 >> Kind regards,
 >> Riko Ho
 >> /***/
 >>
 >> *
 >>
 >>
 >
 >
 > --
 > # Randy MacLeod. SMTS, Linux, Wind River
 > Direct: 613.963.1350 | 350 Terry Fox Drive, Suite 200, Ottawa, ON, 
Canada, K2K 2W5





--
# Randy MacLeod. SMTS, Linux, Wind River
Direct: 613.963.1350 | 350 Terry Fox Drive, Suite 200, Ottawa, ON, 
Canada, K2K 2W5

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

Re: [yocto] [layerindex-web][PATCH] layerindex-web : adding asynchronous task execution

[Diana Thayer]

Great! Thanks for testing it out and identifying that issue.

I've put together a PR on GitHub
 that includes some
changes that appear to fix the issue you're describing. It also updates the
readme to document how to configure the connection to the RabbitMQ server,
and how to start the Celery worker. You can see all the file changes here
.

On Mon, Jul 24, 2017 at 2:49 AM, Paul Eggleton <
paul.eggle...@linux.intel.com> wrote:

> On Friday, 21 July 2017 4:15:26 PM CEST Paul Eggleton wrote:
> > On Tuesday, 27 June 2017 1:59:23 AM CEST Diana Thayer wrote:
> > > This is a work-in-progress solution to issue 11197 within
> layerindex-web:
> > > adding asynchronous task execution.
> > > I used RabbitMQ and Celery. I'm still working with Paul Eggleton on
> adding
> > > install instructions for RabbitMQ to
> > > the site's Dockerfile.
> > >
> > > Previously, when a user submitted a layer, Django would synchronously
> send
> > > emails to users able to publish layers,
> > > such that if an email bounced or otherwise failed, the user submitting
> the
> > > layer would see an error.
> > > This patch sends those emails as asynchronous tasks, so any sending
> errors
> > > don't reach the user submitting a layer.
> >
> > I had a chance to try your patch out today, although I had to apply it
> > partially - I figured a good test would just be the email part. I
> installed
> > rabbitmq and ensured it got started. I started the web interface and
> > submitted  a dummy layer, and the email sent as expected. I then tried
> > killing my local  SMTP server and the layer submission returned an error
> > page, which is what  happened previously - it looks to me as if the
> sending
> > is still being done synchronously. The celery worker isn't reporting
> > anything so I can only assume  the django app is not trying to connect to
> > it.
> >
> > I've pushed just the changes I applied to a new branch here:
> >
> > http://git.yoctoproject.org/cgit/cgit.cgi/layerindex-web/
> log/?h=paule/celery
> >
> > Any idea what's going wrong? Did I mess up in applying the changes, or
> > misconfigure something else?
>
> I figured out the issue - in order to have the task executed asynchronously
> you need to call .delay() on the task object rather than the task
> function itself. That leads to a "django.core.exceptions.
> ImproperlyConfigured"
> error reported by the worker since in my configuration the "import
> settings"
> succeeds but Django isn't set up properly, but at least it's actually
> executing the task via the worker now.
>
> Cheers,
> Paul
>
> --
>
> Paul Eggleton
> Intel Open Source Technology Centre
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [meta-cgl][PATCH] monit: update to 5.20.0

[jackie.huang]

From: Jackie Huang 

Changes:
- Fix the license to AGPLv3
- Add summary, description and homepage
- Add systemd support
- Don't change the files in ${S}, change them
  after installing.
- Add PACKAGECONFIG for pam and enable it when
  it's in DISTRO_FEATURES

Signed-off-by: Jackie Huang 
---
 .../monit/{monit_5.8.bb => monit_5.20.0.bb}| 40 +-
 1 file changed, 32 insertions(+), 8 deletions(-)
 rename meta-cgl-common/recipes-cgl/monit/{monit_5.8.bb => monit_5.20.0.bb} 
(35%)

diff --git a/meta-cgl-common/recipes-cgl/monit/monit_5.8.bb 
b/meta-cgl-common/recipes-cgl/monit/monit_5.20.0.bb
similarity index 35%
rename from meta-cgl-common/recipes-cgl/monit/monit_5.8.bb
rename to meta-cgl-common/recipes-cgl/monit/monit_5.20.0.bb
index 43e02a7..955a28c 100644
--- a/meta-cgl-common/recipes-cgl/monit/monit_5.8.bb
+++ b/meta-cgl-common/recipes-cgl/monit/monit_5.20.0.bb
@@ -1,20 +1,36 @@
-LICENSE = "GPLv3"
+SUMMARY = "Monit is a tool used for system monitoring and error recovery"
+DESCRIPTION = "Monit is a free open source utility for managing and 
monitoring, \
+  processes, programs, files, directories and filesystems on a UNIX system. \
+  Monit conducts automatic maintenance and repair and can execute meaningful \
+  causal actions in error situations. \
+  "
+HOMEPAGE = "http://mmonit.com/monit/;
+
+LICENSE = "AGPLv3"
 LIC_FILES_CHKSUM = "file://COPYING;md5=ea116a7defaf0e93b3bb73b2a34a3f51"
-DEPENDS = "openssl libpam"
+
+DEPENDS = "openssl"
 
 SRC_URI = "\
-   http://mmonit.com/monit/dist/monit-${PV}.tar.gz \
+   http://mmonit.com/monit/dist/${BP}.tar.gz \
file://enable-etc-monit.d-include.patch \
file://init \
"
 
-SRC_URI[md5sum] = "c6873b0828f872676f9e7fe1476a8dc2"
-SRC_URI[sha256sum] = 
"0c00573ebc0156c534a5952f392c2a7bedde194f8261c05497322055938847f5"
+SRC_URI[md5sum] = "769a44ee13b4e1f90156b58dc2f7ea7c"
+SRC_URI[sha256sum] = 
"ebac395ec50c1ae64d568db1260bc049d0e0e624c00e79d7b1b9a59c2679b98d"
 
 INITSCRIPT_NAME = "monit"
 INITSCRIPT_PARAMS = "defaults 99"
 
-inherit autotools-brokensep update-rc.d
+inherit autotools-brokensep update-rc.d systemd
+
+SYSTEMD_PACKAGES = "${PN}"
+SYSTEMD_SERVICE_${PN} = "monit.service"
+SYSTEMD_AUTO_ENABLE = "enable"
+
+PACKAGECONFIG ??= "${@bb.utils.filter('DISTRO_FEATURES', 'pam', d)}"
+PACKAGECONFIG[pam] = "--with-pam,--without-pam,libpam"
 
 EXTRA_OECONF = "\
libmonit_cv_setjmp_available=no \
@@ -23,13 +39,21 @@ EXTRA_OECONF = "\
--with-ssl-incl-dir=${STAGING_INCDIR} \
"
 
+do_configure_prepend() {
+rm -rf ${S}/m4
+}
+
 do_install_append() {
install -d ${D}${sysconfdir}/init.d/
install -m 755 ${WORKDIR}/init ${D}${sysconfdir}/init.d/monit
-   sed -i 's:# set daemon  120:set daemon  120:' ${S}/monitrc
-   sed -i 's:include /etc/monit.d/:include /${sysconfdir}/monit.d/:' 
${S}/monitrc
+
install -m 600 ${S}/monitrc ${D}${sysconfdir}/monitrc
install -m 700 -d ${D}${sysconfdir}/monit.d/
+   sed -i -e 's:# set daemon  120:set daemon  120:' \
+  -e 's:include /etc/monit.d/:include /${sysconfdir}/monit.d/:' \
+  ${D}${sysconfdir}/monitrc
+
+   install -D -m 0644 ${S}/system/startup/monit.service 
${D}${systemd_system_unitdir}/monit.service
 }
 
 CONFFILES_${PN} += "${sysconfdir}/monitrc"
-- 
2.11.0

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

[yocto] [yocto-autobuilder][PATCH] /buildset-config.meta-intel

[Graydon, Tracy]

Delete jasperforest, sugarbay, and nuc buildsets. These are deprecated. We
no longer release/support these.

Signed-off-by: Graydon, Tracy 
---
 buildset-config.meta-intel/jasperforest-lsb.conf | 58 
 buildset-config.meta-intel/jasperforest.conf | 51 -
 buildset-config.meta-intel/nuc-lsb.conf  | 58 
 buildset-config.meta-intel/nuc.conf  | 52 -
 buildset-config.meta-intel/sugarbay-lsb.conf | 58 
 buildset-config.meta-intel/sugarbay.conf | 52 -
 6 files changed, 329 deletions(-)
 delete mode 100644 buildset-config.meta-intel/jasperforest-lsb.conf
 delete mode 100644 buildset-config.meta-intel/jasperforest.conf
 delete mode 100644 buildset-config.meta-intel/nuc-lsb.conf
 delete mode 100644 buildset-config.meta-intel/nuc.conf
 delete mode 100644 buildset-config.meta-intel/sugarbay-lsb.conf
 delete mode 100644 buildset-config.meta-intel/sugarbay.conf

diff --git a/buildset-config.meta-intel/jasperforest-lsb.conf 
b/buildset-config.meta-intel/jasperforest-lsb.conf
deleted file mode 100644
index 5344f28..000
--- a/buildset-config.meta-intel/jasperforest-lsb.conf
+++ /dev/null
@@ -1,58 +0,0 @@
-[jasperforest-lsb]
-builders: 'example-worker'
-repos: [{'poky':
-{'repourl':'git://git.yoctoproject.org/poky',
- 'layerversion':{'core':'meta', 'yoctobsp':'meta-yocto-bsp', 
'yocto':'meta-yocto', 'poky':'meta-poky'},
- 'branch':'master'}},
-{'meta-qt3':
-{'repourl':'git://git.yoctoproject.org/meta-qt3',
- 'branch':'master'}},
-{'meta-qt4':
-{'repourl':'git://git.yoctoproject.org/meta-qt4',
- 'branch':'master'}},
-{'meta-intel':
-{'repourl':'git://git.yoctoproject.org/meta-intel',
- 'layerversion':{'intel':'meta-intel'},
- 'branch':'master'}}]
-props: [{'kmeta':{'prop_type':'StringParameter',
-   'size': 15,
-   'name': 'kmeta',
-   'default': '',
-   'label':' branch for KMETA_${MACHINE} (default 
is blank):'}},
-{'srcrev_meta':{'prop_type':'StringParameter',
-   'size': 15,
-   'name': 'srcrev_meta',
-   'default': '${AUTOREV}',
-   'label':' SRCREV for KMETA_${MACHINE} (default 
is ${AUTOREV}):'}},
-{'srcuri_meta':{'prop_type':'StringParameter',
-   'size': 50,
-   'name': 'srcuri_meta',
-   'default': '',
-   'label':' SRC_URI_pn-linux-yocto KMETA append. 
(default is blank). This should be constructed as *just* the git uri 
portion of the string. 
(git://git.yoctoproject.org/linux-yocto-3.19.git'}},
-{'kbranch':{'prop_type':'StringParameter',
-   'size': 15,
-   'name': 'kbranch',
-   'default': '',
-   'label':' branch for KBRANCH_${MACHINE} 
(default is blank):'}},
-{'srcrev_machine':{'prop_type':'StringParameter',
-   'size': 15,
-   'name': 'srcrev_machine',
-   'default': '${AUTOREV}',
-   'label':' SRCREV for KBRANCH. (default is 
${AUTOREV}):'}},
-{'srcuri_machine':{'prop_type':'StringParameter',
-   'size': 50,
-   'name': 'srcuri_machine',
-   'default': '',
-   'label':' SRC_URI_pn-linux-yocto KBRANCH 
append. (default is blank). This should be constructed as *just* the git 
uri portion of the string. 
(git://git.yoctoproject.org/linux-yocto-3.19.git'}}]
-steps: [{'SetDest':{}},
-{'CheckOutLayers': {}},
-{'RunPreamble': {}},
-{'CheckBSPExists': {}},
-{'GetDistroVersion' : {'distro': 'poky'}},
-{'CreateAutoConf': {'machine': 'jasperforest', 'SDKMACHINE' : 
'x86_64', 'distro': 'poky-lsb', 'emgd': 'False', 'pvr': 'False'}},
-{'CreateBBLayersConf': {'buildprovider' : 'yocto', 'bsplayer': True, 
'bspprovider': 'intel','layerdirs': ['meta-intel', 
'meta-intel/meta-jasperforest', 'meta-intel/meta-tlk']}},
-{'AddKernelProps': {}},
-{'BuildImages': {'images': 'core-image-lsb core-image-lsb-dev 
core-image-lsb-sdk LSB-QT-IMAGES'}},
-{'PublishLayerTarballs':{}},
-{'PublishArtifacts': {'artifacts': ['conf', 'jasperforest']}}]
-
diff --git a/buildset-config.meta-intel/jasperforest.conf 
b/buildset-config.meta-intel/jasperforest.conf
deleted file mode 100644
index 64833da..000
--- a/buildset-config.meta-intel/jasperforest.conf
+++ /dev/null
@@ -1,51 +0,0 @@
-[jasperforest]
-builders: 'example-worker'
-repos: [{'poky':
-{'repourl':'git://git.yoctoproject.org/poky',
- 

Re: [yocto] Mpich and yocto ?

[Riko Ho]

Dear Yocto Team Member,

The cluster is using Ubuntu.
I haven't checked all the packages on the other computer. I will.

My goal is getting more hardrive space and compiling speed.

How can I relate bitbake with mpicc or other compilers needed by yocto
(arm-linux-gcc, gcc, etc)?

I have tested a small code with mpicc and the cluster do the job.

Thanks for the attention.

On Jul 27, 2017 3:23 AM, "Randy MacLeod" 
wrote:
>
> On 2017-07-26 02:09 AM, Riko Ho wrote:
>>
>> How can we do that ?
>>
>> bitbake in which node ? I don't understand ?
>>
>>
>> On 26/07/17 13:57, Josef Holzmayr wrote:
>>>
>>> Hi
>>>
>>> On 26.07.2017 05:12, Riko Ho wrote:

 Does anyone know on how to run poky on mpich cluster ?
>
>
> That's a rather ambiguous question.
>
> What OS/Distro is the mpich cluster running?
> Have you installed the packages that are required on the host:
>see: "The Build Host Packages" here:
>
>
http://www.yoctoproject.org/docs/2.3/yocto-project-qs/yocto-project-qs.html
>
> What do you hope to achieve using bitbake?
>
>
>>>
>>> As far as I can see, MPICH is a userland library, basically. So it
would be the other way round, you could probably run a mpich application on
a number of nodes that run some OE/Poky thing.
>>>
>>> Greetz
>
>
> There is an mpich recipe here:
> http://layers.openembedded.org/layerindex/recipe/33348/
>
> but again, it's not clear what your ultimate goal is.
>
> ../Randy
>
>>
>> --
>> *
>>
>>
>> /***/
>> Sent by Ubuntu LTS 16.04,
>> Kind regards,
>> Riko Ho
>> /***/
>>
>> *
>>
>>
>
>
> --
> # Randy MacLeod. SMTS, Linux, Wind River
> Direct: 613.963.1350 | 350 Terry Fox Drive, Suite 200, Ottawa, ON,
Canada, K2K 2W5
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [linux-yocto] [PATCH 2/3][kernel-cache] common-pc-64: Adds usb-net configs to genericx86-64 builds

[Alejandro Hernandez]

Hey Bruce,

So I completely agree with you, and I think we should keep them 
modules/kernel size as small as we can,


but I just had a meeting with the QA team and discussed this, it does 
look like it'd be necessary to have those


modules built for everyone, since they are not building images 
specifically for QA, they take their images straight


from the public Autobuilder.


The meta-intel images would be unaffected anyway, since they already 
include these modules via another scc,


but after chatting with Saul, we agreed we wanted them anyway, in case 
something changes on the other scc.



Alejandro



On 07/25/2017 08:45 AM, Bruce Ashfield wrote:

No real objections to the series, but it will of course increase the
amount of modules/kernel size out of the box. I'm continually
balancing the built-in convenience versus the size of the kernel
and need to always ask the following question:

This sort of thing can be added via KERNEL_FEATURES when a QA build
is being done.

I assume that route was considered and rejected ?

Bruce

On 2017-07-24 2:58 PM, Alejandro Hernandez wrote:

QA needs USB OTG to automate some of the testing processes,
this patch adds it to genericx86-64 builds

[YOCTO #11740]

Signed-off-by: Alejandro Hernandez 
---
  bsp/common-pc-64/common-pc-64.scc | 1 +
  1 file changed, 1 insertion(+)

diff --git a/bsp/common-pc-64/common-pc-64.scc 
b/bsp/common-pc-64/common-pc-64.scc

index 6ceee53e..d9d41c1c 100644
--- a/bsp/common-pc-64/common-pc-64.scc
+++ b/bsp/common-pc-64/common-pc-64.scc
@@ -17,6 +17,7 @@ include features/usb/uhci-hcd.scc
  include features/usb/ohci-hcd.scc
  include features/usb/xhci-hcd.scc
  include features/usb/touchscreen-composite.scc
+include features/usb-net/usb-net.scc
  include features/intel-e1/intel-e100.scc
  include features/intel-e1/intel-e1.scc
  include features/scsi/cdrom.scc





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

[yocto] [PATCH] dev-manual, ref-manual: Update for vmdk/vdi/qcow2/u-boot image changes

[Tom Rini]

Recently a number of changes have happened on the implementation side of
some image formats, and a few have been renamed.  The u-boot image
signing code is now always available and no longer in a stand-alone
file.  The vmdk/vdi/qcow2 images have been removed and are now just a
conversion type that is applied to wic images.

Signed-off-by: Tom Rini 
---
Please note that while the u-boot image changes are live the
vmdk/vdi/qcow2 portions are not yet merged.  But given that they are
user visible changes I promised to provide documentation updates along
with the implementation changes, so these shouldn't be applied until
they have been merged.  Thanks!
---
 documentation/dev-manual/dev-manual-qemu.xml |  6 +++---
 documentation/ref-manual/ref-classes.xml | 32 +---
 documentation/ref-manual/ref-tasks.xml   | 10 -
 documentation/ref-manual/ref-variables.xml   |  9 +++-
 documentation/ref-manual/usingpoky.xml   |  8 +++
 5 files changed, 15 insertions(+), 50 deletions(-)

diff --git a/documentation/dev-manual/dev-manual-qemu.xml 
b/documentation/dev-manual/dev-manual-qemu.xml
index ed4040ca60d8..2b3383c40482 100644
--- a/documentation/dev-manual/dev-manual-qemu.xml
+++ b/documentation/dev-manual/dev-manual-qemu.xml
@@ -168,13 +168,13 @@
 
 
 This example specifies to boot a virtual machine 
image
-(.vmdk file).
-From the .vmdk,
+(.wic.vmdk file).
+From the .wic.vmdk,
 runqemu determines the QEMU
 architecture (MACHINE) 
to be
 "qemux86" and the root filesystem type to be 
"vmdk".
 
- $ runqemu /home/scott-lenovo/vm/core-image-minimal-qemux86.vmdk
+ $ runqemu /home/scott-lenovo/vm/core-image-minimal-qemux86.wic.vmdk
 
 
 
diff --git a/documentation/ref-manual/ref-classes.xml 
b/documentation/ref-manual/ref-classes.xml
index 1801faf501ee..b177902b776a 100644
--- a/documentation/ref-manual/ref-classes.xml
+++ b/documentation/ref-manual/ref-classes.xml
@@ -1286,14 +1286,13 @@
 image_types must also appear in
 IMAGE_CLASSES.
 
-
-
-
-image_types_uboot.bbclass
 
 
-The image_types_uboot class
-defines additional image types specifically for the U-Boot bootloader.
+   This class also handles conversion and compression of images as well.
+   Note that to build a VMware VMDK image you need to add "wic.vmdk" to
+   IMAGE_FSTYPES.
+   This would also be similar for Virtual Box Virtual Disk Image ("vdi")
+   and QEMU Copy On Write Version 2 ("qcow2") images.
 
 
 
@@ -1370,27 +1369,6 @@
 
 
 
-
-image-vm.bbclass
-
-
-The image-vm class supports building VM
-images.
-
-
-
-
-image-vmdk.bbclass
-
-
-The image-vmdk class supports building VMware
-VMDK images.
-Normally, you do not use this class directly.
-Instead, you add "vmdk" to
-IMAGE_FSTYPES.
-
-
-
 
 insane.bbclass
 
diff --git a/documentation/ref-manual/ref-tasks.xml 
b/documentation/ref-manual/ref-tasks.xml
index 99e9f52b8651..1fe175e10453 100644
--- a/documentation/ref-manual/ref-tasks.xml
+++ b/documentation/ref-manual/ref-tasks.xml
@@ -838,16 +838,6 @@
 section in the Yocto Project Development Manual.
 
 
-
-
-do_vmdkimg
-
-
-Creates a .vmdk image for use with
-VMware
-and compatible virtual machine hosts.
-
-
 
 
 
diff --git a/documentation/ref-manual/ref-variables.xml 
b/documentation/ref-manual/ref-variables.xml
index ff8f4e73d041..54a9ff5ab85e 100644
--- a/documentation/ref-manual/ref-variables.xml
+++ b/documentation/ref-manual/ref-variables.xml
@@ -3864,14 +3864,14 @@
 
 EFI_PROVIDER
 
-EFI_PROVIDER[doc] = "When building bootable images (i.e. where 
hddimg or vmdk is in IMAGE_FSTYPES), the EFI_PROVIDER variable specifies the 
EFI bootloader to use."
+EFI_PROVIDER[doc] = "When building bootable images (i.e. where 
hddimg, iso or live is in IMAGE_FSTYPES), the EFI_PROVIDER variable specifies 
the EFI bootloader to use."
 
 
 
 
 When building bootable images (i.e. where
-hddimg or vmdk
-is in
+   hddimg, iso or
+   live is in
 IMAGE_FSTYPES),
 the EFI_PROVIDER variable specifies
 the EFI bootloader to use.
@@ -6190,7 +6190,6 @@
  jffs2
  jffs2.sum
  multiubi
- qcow2
  squashfs
  squashfs-lzo
  

Re: [yocto] Mpich and yocto ?

[Randy MacLeod]

On 2017-07-26 02:09 AM, Riko Ho wrote:

How can we do that ?

bitbake in which node ? I don't understand ?


On 26/07/17 13:57, Josef Holzmayr wrote:

Hi

On 26.07.2017 05:12, Riko Ho wrote:

Does anyone know on how to run poky on mpich cluster ?


That's a rather ambiguous question.

What OS/Distro is the mpich cluster running?
Have you installed the packages that are required on the host:
   see: "The Build Host Packages" here:

http://www.yoctoproject.org/docs/2.3/yocto-project-qs/yocto-project-qs.html

What do you hope to achieve using bitbake?



As far as I can see, MPICH is a userland library, basically. So it 
would be the other way round, you could probably run a mpich 
application on a number of nodes that run some OE/Poky thing.


Greetz


There is an mpich recipe here:
http://layers.openembedded.org/layerindex/recipe/33348/

but again, it's not clear what your ultimate goal is.

../Randy



--
*

/***/
Sent by Ubuntu LTS 16.04,
Kind regards,
Riko Ho
/***/

*





--
# Randy MacLeod. SMTS, Linux, Wind River
Direct: 613.963.1350 | 350 Terry Fox Drive, Suite 200, Ottawa, ON, 
Canada, K2K 2W5

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

Re: [yocto] do_compile errors.

[Randy MacLeod]

On 2017-07-19 09:13 AM, Joseph Ngigi wrote:

Here's my console output:

ngigijoe@ngigijoe-HP-2000-Notebook-PC:~/src/git/pyro/poky/cubieboard2$ 
bitbake core-image-sato
Loading cache: 100% 
|#| 
Time: 0:00:00

Loaded 2168 entries from dependency cache.
NOTE: Resolving any missing task queue dependencies

Build Configuration:
BB_VERSION= "1.34.0"
BUILD_SYS = "x86_64-linux"
NATIVELSBSTRING   = "universal-4.8"
TARGET_SYS= "arm-poky-linux-gnueabi"
MACHINE   = "cubieboard2"
DISTRO= "poky"
DISTRO_VERSION= "2.3.1"
TUNE_FEATURES = "arm armv7ve vfp neon vfpv4 callconvention-hard 
cortexa7"

TARGET_FPU= "hard"
meta
meta-poky = "pyro:6bd890d9e011014cf323e61267f8b256949d44aa"
meta-sunxi= "pyro:0056643fcf2c496a0f2cf005fb67d626ab0e2c10"
meta-oe
meta-gnome= "pyro:5e82995148a2844c6f483ae5ddd1438d87ea9fb7"

Initialising tasks: 100% 
|| 
Time: 0:00:19

NOTE: Executing SetScene Tasks
NOTE: Executing RunQueue Tasks
ERROR: gperf-native-3.0.4-r0 do_compile: oe_runmake failed
ERROR: gperf-native-3.0.4-r0 do_compile: Function failed: do_compile 
(log file is located at 
/home/ngigijoe/src/git/pyro/poky/cubieboard2/tmp/work/x86_64-linux/gperf-native/3.0.4-r0/temp/log.do_compile.7266)
ERROR: Logfile of failure stored in: 
/home/ngigijoe/src/git/pyro/poky/cubieboard2/tmp/work/x86_64-linux/gperf-native/3.0.4-r0/temp/log.do_compile.7266

Log data follows:
| DEBUG: Executing shell function do_compile
| NOTE: make -j 8
| ERROR: oe_runmake failed
| cd lib; make all
| make[1]: Entering directory 
'/home/ngigijoe/src/git/pyro/poky/cubieboard2/tmp/work/x86_64-linux/gperf-native/3.0.4-r0/build/lib'

| make[1]: Nothing to be done for 'all'.
| make[1]: Leaving directory 
'/home/ngigijoe/src/git/pyro/poky/cubieboard2/tmp/work/x86_64-linux/gperf-native/3.0.4-r0/build/lib'

| cd src; make all
| make[1]: Entering directory 
'/home/ngigijoe/src/git/pyro/poky/cubieboard2/tmp/work/x86_64-linux/gperf-native/3.0.4-r0/build/src'
| g++  
-isystem/home/ngigijoe/src/git/pyro/poky/cubieboard2/tmp/work/x86_64-linux/gperf-native/3.0.4-r0/recipe-sysroot-native/usr/include 
-O2 -pipe -D_GLIBCXX_USE_CXX11_ABI=0 
-L/home/ngigijoe/src/git/pyro/poky/cubieboard2/tmp/work/x86_64-linux/gperf-native/3.0.4-r0/recipe-sysroot-native/usr/lib 
-L/home/ngigijoe/src/git/pyro/poky/cubieboard2/tmp/work/x86_64-linux/gperf-native/3.0.4-r0/recipe-sysroot-native/lib 
-Wl,-rpath-link,/home/ngigijoe/src/git/pyro/poky/cubieboard2/tmp/work/x86_64-linux/gperf-native/3.0.4-r0/recipe-sysroot-native/usr/lib 
-Wl,-rpath-link,/home/ngigijoe/src/git/pyro/poky/cubieboard2/tmp/work/x86_64-linux/gperf-native/3.0.4-r0/recipe-sysroot-native/lib 
-Wl,-rpath,/home/ngigijoe/src/git/pyro/poky/cubieboard2/tmp/work/x86_64-linux/gperf-native/3.0.4-r0/recipe-sysroot-native/usr/lib 
-Wl,-rpath,/home/ngigijoe/src/git/pyro/poky/cubieboard2/tmp/work/x86_64-linux/gperf-native/3.0.4-r0/recipe-sysroot-native/lib 
-Wl,-O1 -o gperf version.o positions.o options.o keyword.o 
keyword-list.o input.o bool-array.o hash-table.o search.o output.o 
main.o ../lib/libgp.a -lm

| g++: error: version.o: No such file or directory
| g++: error: positions.o: No such file or directory
| g++: error: options.o: No such file or directory
| g++: error: keyword.o: No such file or directory
| g++: error: keyword-list.o: No such file or directory
| g++: error: input.o: No such file or directory
| g++: error: bool-array.o: No such file or directory
| g++: error: hash-table.o: No such file or directory
| g++: error: output.o: No such file or directory
| g++: error: main.o: No such file or directory
| g++: error: ../lib/libgp.a: No such file or directory
| Makefile:74: recipe for target 'gperf' failed
| make[1]: *** [gperf] Error 1
| make[1]: Leaving directory 
'/home/ngigijoe/src/git/pyro/poky/cubieboard2/tmp/work/x86_64-linux/gperf-native/3.0.4-r0/build/src'

| Makefile:33: recipe for target 'all' failed
| make: *** [all] Error 2
| WARNING: exit code 1 from a shell command.
| ERROR: Function failed: do_compile (log file is located at 
/home/ngigijoe/src/git/pyro/poky/cubieboard2/tmp/work/x86_64-linux/gperf-native/3.0.4-r0/temp/log.do_compile.7266)
ERROR: Task 
(virtual:native:/home/ngigijoe/src/git/pyro/poky/meta/recipes-extended/gperf/gperf_3.0.4.bb:do_compile) 
failed with exit code '1'


Second Keyboard Interrupt, stopping...


Summary: 1 task failed:
   
virtual:native:/home/ngigijoe/src/git/pyro/poky/meta/recipes-extended/gperf/gperf_3.0.4.bb:do_compile

Summary: There were 2 ERROR messages shown, returning a non-zero exit code.
NOTE: Sending SIGTERM to remaining 6 tasks


On Wed, Jul 19, 2017 at 3:58 PM, Joseph Ngigi > wrote:


I seem to be having a 

[yocto] automount pyro, /run/media/sda1 empty, not under morty

[ALLEN,RICHARD (K-SantaClara,ex1)]

I am new to this area.
I have been using morty to build my image and moved over to pyro
now my automount is resulting in a /run/media/sda1 which is empty
where , under the morty build, I see my files on the usb stick drive  in 
/run/media/sda1

Note:
login as root, not a privilege issue
using same kernel and .config for both morty and pyro , so not a missing kernel 
option

I am not sure where I should be looking at or why automount is behaving this 
way.

Any help, suggestions, would greatly be appreciated.
thanks

Richard C. Allen




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

Re: [yocto] cogl-1.0-dev

[Markus Volk]

the problem could also be resolved in the way it was done here:

https://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=8e15e9b6e478f6368034519b2a8fd3c7ea71d23b


On Wed, 26 Jul 2017 17:48:31 +0200
Markus Volk  wrote:

> Hi,
> 
> I build myself an image (x86_64) for my NUC. Because i´m including all dev 
> packages i encountered the following problem while switching from pyro to the 
> recent poky master
> 
> do_rootfs crashes with an error message because cogl-1.0-dev wants to install 
> package cogl-1.0. Cogl-1.0 is empty and has therefore not been created.
> 
> I tried to fix this with a line in cogl-1.0_%.bbappend
> 
> ALLOW_EMPTY_${PN} = "1"
> 
> next error ... cogl-1.0-dev is missing the package libcogl20
> 
> At this point i´ve simply overwritten the files variables in my bbappend like 
> this
> 
> FILES_${PN} = "*"
> FILES_${PN}-examples = "$ {bindir} / * $ {datadir} / cogl / examples-data / *"
> FILES_libcogl = ""
> FILES_libcogl-gles2 = ""
> FILES_libcogl-pango = ""
> 
> FILES_libcogl-path = ""
> 
> The problem is gone, but i guess this would not be a proper solution for the 
> project. I´m pretty sure, i saw those cogl errors in the do_rootfs log in 
> pyro also, but log_check didn´t care about that so far
> 
> Markus
> -- 
> Markus Volk 
> -- 
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto


-- 
Markus Volk 


0001-cogl-1.0-Fix-packages-so-dev-pkgs-image-generation-w.patch
Description: Binary data
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[linux-yocto] [kernel-cache][PATCH] leafhill: update branch for leafhill

[chong . yi . chai]

From: Chong Yi Chai 

Update branch to standard/intel/base for kernel 4.1.42 upgrade.

Signed-off-by: Chong Yi Chai 
---
 bsp/leafhill/leafhill-standard.scc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bsp/leafhill/leafhill-standard.scc 
b/bsp/leafhill/leafhill-standard.scc
index 8318a57..0fa1b53 100644
--- a/bsp/leafhill/leafhill-standard.scc
+++ b/bsp/leafhill/leafhill-standard.scc
@@ -10,4 +10,4 @@ define KTYPE standard
 include ktypes/standard/standard.scc
 include leafhill.scc
 
-branch intel/4.1.27/leaf-hill
+branch intel/base
-- 
1.9.1

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

[yocto] cogl-1.0-dev

[Markus Volk]

Hi,

I build myself an image (x86_64) for my NUC. Because i´m including all dev 
packages i encountered the following problem while switching from pyro to the 
recent poky master

do_rootfs crashes with an error message because cogl-1.0-dev wants to install 
package cogl-1.0. Cogl-1.0 is empty and has therefore not been created.

I tried to fix this with a line in cogl-1.0_%.bbappend

ALLOW_EMPTY_${PN} = "1"

next error ... cogl-1.0-dev is missing the package libcogl20

At this point i´ve simply overwritten the files variables in my bbappend like 
this

FILES_${PN} = "*"
FILES_${PN}-examples = "$ {bindir} / * $ {datadir} / cogl / examples-data / *"
FILES_libcogl = ""
FILES_libcogl-gles2 = ""
FILES_libcogl-pango = ""

FILES_libcogl-path = ""

The problem is gone, but i guess this would not be a proper solution for the 
project. I´m pretty sure, i saw those cogl errors in the do_rootfs log in pyro 
also, but log_check didn´t care about that so far

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

[yocto] [meta-security][PATCH] keynote: add new recipe

[jackie.huang]

From: Jackie Huang 

KeyNote is a simple and flexible trust-management system
designed to work well for a variety of large- and small-
scale Internet-based applications

Signed-off-by: Jackie Huang 
---
 .../configure-remove-hardcode-path.patch   | 37 ++
 .../keynote/keynote-2.3/makefile-add-ldflags.patch | 36 +
 recipes-security/keynote/keynote-2.3/run-ptest | 16 ++
 recipes-security/keynote/keynote_2.3.bb| 37 ++
 4 files changed, 126 insertions(+)
 create mode 100644 
recipes-security/keynote/keynote-2.3/configure-remove-hardcode-path.patch
 create mode 100644 
recipes-security/keynote/keynote-2.3/makefile-add-ldflags.patch
 create mode 100644 recipes-security/keynote/keynote-2.3/run-ptest
 create mode 100644 recipes-security/keynote/keynote_2.3.bb

diff --git 
a/recipes-security/keynote/keynote-2.3/configure-remove-hardcode-path.patch 
b/recipes-security/keynote/keynote-2.3/configure-remove-hardcode-path.patch
new file mode 100644
index 000..af3ef42
--- /dev/null
+++ b/recipes-security/keynote/keynote-2.3/configure-remove-hardcode-path.patch
@@ -0,0 +1,37 @@
+Remove the hardcoded lib and include dirs
+
+Upstream-Status: Inappropriate [cross compile specific]
+
+written by: Amy Fong 
+Signed-off-by: Jackie Huang 
+
+--- keynote-2.3/configure.in.orig  2010-05-24 04:44:16.0 -0700
 keynote-2.3/configure.in   2010-05-24 04:44:55.0 -0700
+@@ -21,27 +21,16 @@
+ AC_PATH_PROG(ECHO, echo, /bin/echo)
+ AC_PATH_PROG(SED, sed, /usr/bin/sed)
+ 
+-dnl Checks for libraries.
+-LIBS="-L/usr/lib -L/usr/local/lib -L/usr/ssl/lib -L/usr/openssl/lib\
+- -L/usr/local/ssl/lib -L/usr/local/openssl/lib -L/usr/pkg/lib -L/pkg/lib"
+-
+ AC_CHECK_LIB(m, floor, LIBS="$LIBS -lm")
+ AC_CHECK_LIB(rsaref, RSAPrivateDecrypt, LIBS="$LIBS -lrsaref")
+ AC_CHECK_LIB(crypto, i2a_ASN1_STRING, LIBS="$LIBS -lcrypto")
+ AC_CHECK_LIB(RSAglue, RSA_ref_private_encrypt, LIBS="$LIBS -lRSAglue")
+ 
+-dnl Checks for header files.
+-CPPFLAGS="-I/usr/include -I/usr/local/include -I/usr/ssl/include\
+- -I/usr/local/ssl/include -I/usr/openssl/include -I/usr/pkg/include\
+- -I/usr/local/openssl/include -I/pkg/include"
+-
+ AC_HEADER_STDC
+ AC_HEADER_TIME
+ AC_CHECK_HEADERS(fcntl.h limits.h unistd.h regex.h sys/time.h io.h)
+ AC_CHECK_HEADERS(ssl/crypto.h openssl/crypto.h crypto.h memory.h)
+ 
+-dnl Checks for other files
+-
+ dnl Checks for typedefs, structures, and compiler characteristics.
+ AC_C_CONST
+ AC_CHECK_TYPE(u_int, unsigned int)
diff --git a/recipes-security/keynote/keynote-2.3/makefile-add-ldflags.patch 
b/recipes-security/keynote/keynote-2.3/makefile-add-ldflags.patch
new file mode 100644
index 000..80d87cf
--- /dev/null
+++ b/recipes-security/keynote/keynote-2.3/makefile-add-ldflags.patch
@@ -0,0 +1,36 @@
+Add LDFLAGS variable to Makefile so that extra linker flags can be sent via 
this variable.
+
+Upstream-Status: Pending
+
+Signed-off-by: Yi Zhao 
+
+diff --git a/Makefile.in b/Makefile.in
+index b216648..42b4827 100644
+--- a/Makefile.in
 b/Makefile.in
+@@ -35,6 +35,7 @@ MKDIR = @MKDIR@
+ SED = @SED@
+ ECHO = @ECHO@
+ TR = @TR@
++LDFLAGS = @LDFLAGS@
+ 
+ TARFLAGS = -cvzf ${DISTFILE}
+ YACCFLAGS2 = -d -p kv -b z
+@@ -83,7 +84,7 @@ $(TARGET): $(OBJS)
+   $(RANLIB) $(TARGET)
+ 
+ $(TARGET2): $(TARGET) $(OBJS2)
+-  $(CC) $(CFLAGS) -o $(TARGET2) $(OBJS2) $(LIBS)
++  $(CC) $(CFLAGS) $(LDFLAGS) -o $(TARGET2) $(OBJS2) $(LIBS)
+ 
+ k.tab.c: keynote.y header.h keynote.h assertion.h config.h
+   $(YACC) $(YACCFLAGS) keynote.y
+@@ -131,7 +132,7 @@ $(SSLCERT) $(SSLKEY):
+   -keyout $(SSLKEY)
+ 
+ test-sample: all $(OBJS3)
+-  $(CC) $(CFLAGS) -o $(TARGET3) $(OBJS3) $(LIBS)
++  $(CC) $(CFLAGS) $(LDFLAGS) -o $(TARGET3) $(OBJS3) $(LIBS)
+ 
+ test-sig: all $(SSLCERT) $(SSLKEY)
+   $(SED) -e 's/--.*//' < $(SSLCERT) > $(SSLCERT).1
diff --git a/recipes-security/keynote/keynote-2.3/run-ptest 
b/recipes-security/keynote/keynote-2.3/run-ptest
new file mode 100644
index 000..4dc35c9
--- /dev/null
+++ b/recipes-security/keynote/keynote-2.3/run-ptest
@@ -0,0 +1,16 @@
+#!/bin/sh
+
+cd @PTEST_PATH@
+keynote verify -e testsuite/test-env \
+   -r false,maybe,probably,true \
+   -k testsuite/auth1 -k testsuite/auth2 \
+   -k testsuite/auth3 -k testsuite/auth4 \
+   -l testsuite/test-assertion1 \
+   -l testsuite/test-assertion2 \
+   -l testsuite/test-assertion3 \
+   -l testsuite/test-assertion4 \
+   -l testsuite/test-assertion5 \
+   -l testsuite/test-assertion6 \
+   -l testsuite/test-assertion7 \
+   && echo "PASS: keynote-ptest" \
+   || echo "FAIL: keynote-ptest"
diff --git a/recipes-security/keynote/keynote_2.3.bb 

Re: [yocto] Mpich and yocto ?

[Riko Ho]

How can we do that ?

bitbake in which node ? I don't understand ?


On 26/07/17 13:57, Josef Holzmayr wrote:

Hi

On 26.07.2017 05:12, Riko Ho wrote:

Does anyone know on how to run poky on mpich cluster ?


As far as I can see, MPICH is a userland library, basically. So it 
would be the other way round, you could probably run a mpich 
application on a number of nodes that run some OE/Poky thing.


Greetz


--
*

/***/
Sent by Ubuntu LTS 16.04,
Kind regards,
Riko Ho
/***/

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

Re: [yocto] [PATCH] Added missing CPPFLAGS/CFLAGS/LDFLAGS in sample recipe for morty branch

[Einar Vading]

On Mon, Jul 17, 2017 at 4:48 PM, Leonardo Sandoval <
leonardo.sandoval.gonza...@linux.intel.com> wrote:

> On Mon, 2017-07-17 at 15:30 +0100, Burton, Ross wrote:
> >
> > On 17 July 2017 at 15:04, Leonardo Sandoval
> >  wrote:
> > master has the second line (LDFLAGS) but not the first one
> > (CPPFLAGS and
> > CFLAGS) so the problem may also be present on master. Would
> > you mind
> > checking this and sent patches to the poky mailing list?
> >
> >
> > The GNU_HASH warning is triggered by ignoring LDFLAGS.
>
> Got it, so definitely LDFLAGS var is missing, not sure if the rest are
> necessary for this simple hello world recipe.
> Leo
>

I had this problem to and IIRC i fixed it by moving the LDFLAGS variable to
the end of the line
> +  ${CC} helloworld.o -o helloworld  ${LDFLAGS}

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

Re: [yocto] Mpich and yocto ?

[Josef Holzmayr]

Hi

On 26.07.2017 05:12, Riko Ho wrote:

Does anyone know on how to run poky on mpich cluster ?


As far as I can see, MPICH is a userland library, basically. So it would 
be the other way round, you could probably run a mpich application on a 
number of nodes that run some OE/Poky thing.


Greetz
--
Josef Holzmayr
Software Developer Embedded Systems

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

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

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

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