[yocto] [error-report-web][PATCH V2] Add local.conf and auto.conf into error details

[changqing.li]

From: Changqing Li 

Support to display local.conf and auto.conf on error report web.
Here is commit in oe-core, which add local.conf/auto.conf into error report
https://git.openembedded.org/openembedded-core/commit/?id=7adf9707c04d8ef6bcd8d8bda555687f705e6ee6

This commit is related to YOCTO #13252

Signed-off-by: Changqing Li 
---
 Post/0006_auto_20190917_0419.py | 24 
 Post/models.py  |  2 ++
 Post/parser.py  |  2 ++
 Post/test.py|  2 ++
 templates/error-details.html| 10 ++
 test-data/test-payload.json |  4 +++-
 6 files changed, 43 insertions(+), 1 deletion(-)
 create mode 100644 Post/0006_auto_20190917_0419.py

diff --git a/Post/0006_auto_20190917_0419.py b/Post/0006_auto_20190917_0419.py
new file mode 100644
index 000..827944e
--- /dev/null
+++ b/Post/0006_auto_20190917_0419.py
@@ -0,0 +1,24 @@
+# -*- coding: utf-8 -*-
+from __future__ import unicode_literals
+
+from django.db import migrations, models
+
+
+class Migration(migrations.Migration):
+
+dependencies = [
+('Post', '0005_build_error_type'),
+]
+
+operations = [
+migrations.AddField(
+model_name='build',
+name='AUTO_CONF',
+field=models.TextField(default=b'', max_length=5242880),
+),
+migrations.AddField(
+model_name='build',
+name='LOCAL_CONF',
+field=models.TextField(default=b'', max_length=5242880),
+),
+]
diff --git a/Post/models.py b/Post/models.py
index ddf2fc7..e9fd010 100644
--- a/Post/models.py
+++ b/Post/models.py
@@ -43,6 +43,8 @@ class Build(models.Model):
 LINK_BACK = models.TextField(max_length=300, blank=True, null=True)
 ERROR_TYPE = models.CharField(max_length=20, choices=ERROR_TYPE_CHOICES,
   default=ErrorType.RECIPE)
+LOCAL_CONF = models.TextField(max_length=int(settings.MAX_UPLOAD_SIZE), 
default="")
+AUTO_CONF = models.TextField(max_length=int(settings.MAX_UPLOAD_SIZE), 
default="")
 
 def save(self, *args, **kwargs):
 if self.ERROR_TYPE not in [e_type[0] for e_type in
diff --git a/Post/parser.py b/Post/parser.py
index 9639308..69d43c1 100644
--- a/Post/parser.py
+++ b/Post/parser.py
@@ -53,6 +53,8 @@ class Parser:
 b.EMAIL = str(jsondata['email'])
 b.LINK_BACK = jsondata.get("link_back", None)
 b.ERROR_TYPE = jsondata.get("error_type", ErrorType.RECIPE)
+b.LOCAL_CONF = str(jsondata['local_conf'])
+b.AUTO_CONF = str(jsondata['auto_conf'])
 
 # Extract the branch and commit
 g = re.match(r'(.*): (.*)', jsondata['branch_commit'])
diff --git a/Post/test.py b/Post/test.py
index 6dc7878..4fe236c 100755
--- a/Post/test.py
+++ b/Post/test.py
@@ -46,6 +46,8 @@ def compare_db_obj_with_payload(self, bf_object):
 self.assertEqual(bf_object.BUILD.NAME == str(payload['username']), True)
 self.assertEqual(bf_object.BUILD.EMAIL == str(payload['email']), True)
 self.assertEqual(bf_object.BUILD.LINK_BACK == payload.get("link_back", 
None), True)
+self.assertEqual(bf_object.BUILD.LOCAL_CONF == payload.get("local_conf", 
None), True)
+self.assertEqual(bf_object.BUILD.AUTO_CONF == payload.get("auto_conf", 
None), True)
 
 g = re.match(r'(.*): (.*)', payload['branch_commit'])
 
diff --git a/templates/error-details.html b/templates/error-details.html
index c30160d..c8fce05 100644
--- a/templates/error-details.html
+++ b/templates/error-details.html
@@ -81,6 +81,16 @@
   {% endwith %}
 
 
+{% if detail.BUILD.LOCAL_CONF != "" %}
+Local Conf:
+{{ detail.BUILD.LOCAL_CONF | safe 
}}
+{% endif %}
+
+{% if detail.BUILD.AUTO_CONF != "" %}
+Auto Conf:
+{{ detail.BUILD.AUTO_CONF | safe 
}}
+{% endif %}
+
   
   
 https://bugzilla.yoctoproject.org/enter_bug.cgi?classification=__all"; 
>Open a bug
diff --git a/test-data/test-payload.json b/test-data/test-payload.json
index 0428a16..fd21053 100644
--- a/test-data/test-payload.json
+++ b/test-data/test-payload.json
@@ -1,4 +1,5 @@
 {
+"auto_conf": "",
 "branch_commit": "(master-test): 
736b49449233c936e3099b314a58e91ad17f9774", 
 "build_sys": "x86_64-linux", 
 "component": "base-passwd", 
@@ -11,7 +12,8 @@
 "package": "base-passwd-3.5.29-r0", 
 "task": "do_install"
 }
-], 
+],
+"local_conf": "",
 "machine": "qemux86", 
 "nativelsb": "Ubuntu-14.04", 
 "target_sys": "i586-poky-linux"
-- 
2.7.4

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

Re: [yocto] Public cloud provider for Yocto builds

[Alexander Kanavin]

I would have the following requirements for any provider you choose:

1. Having kvm enabled (for the purpose of running qemu tests in the cloud
with good performance)
2. NFS server as a service from the cloud provider (so you don't have to
set it up and maintain it yourself)
3. Ability to share directories to the public over http (for the purpose of
providing sstate cache to developers' local machines).

Alex

On Tue, 12 Nov 2019 at 00:55, John McGehee 
wrote:

> ​I am looking at building on a public cloud provider like AWS, Google or
> Azure. Is there any cloud provider that is better than the others for Yocto
> build and CI?
>
>
> Is there anything else that I should use to get the most our of
> cloud-based builds?
>
> *** MEDIATEK Confidentiality Notice ***
> The information contained in this e-mail message (including any
> attachments) may be confidential, proprietary, privileged, or
> otherwise exempt from disclosure under applicable laws. It is
> intended to be conveyed only to the designated recipient(s). Any
> use, dissemination, distribution, printing, retaining or copying
> of this e-mail (including its attachments) by unintended recipient(s)
> is strictly prohibited and may be unlawful. If you are not an
> intended recipient of this e-mail, or believe that you have received
> this e-mail in error, please notify the sender immediately
> (by replying to this e-mail), delete any and all copies of this
> e-mail (including any attachments) from your system, and do not
> disclose the content of this e-mail to any other person. Thank you!
>
> --
> ___
> 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] Kernel modules packaged but not installed

[Dimitris Tassopoulos]

Hi Bruce,

I've also tried adding the `kernel-modules` in the IMAGE_INSTALL,
but that doesn't help either, because as I've mentioned this package
is empty.

The individual module packages are indeed populated and adding each
one individually in the IMAGE_INSTALL makes them install in the final
image.

So the problem is that the `kernel-modules` doesn't add all the module
packages in one package and it's empty. Therefore, when it's installed
it installs nothing.

Regards,
Dimitris

Bruce Ashfield  schrieb am Mi., 6. Nov. 2019,
17:20:

> On Wed, Nov 6, 2019 at 11:06 AM Dimitris Tassopoulos 
> wrote:
> >
> > Hi all. I have a weird issue with the kernel modules not being installed
> in the image and also not packaged.
> > I see the packages for individual "kernel-module-*.ipk" modules but the
> "kernel-modules_*.ipk" is always
> > empty.
> >
> > I'm also able to see the "modules-${MACHINE}.tgz" in DEPLOYDIR which has
> all the modules in there, just fine.
> >
> > In my image file I've also set this:
> > MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS += "kernel-modules"
>
> Have you tried something stronger than the RRECOMMENDS ? i.e. either
> adding one of the modules, or the kernel-modules meta package to
> IMAGE_INSTALL ?
>
> Bruce
>
> >
> > This is the kernel recipe:
> >
> https://gitlab.com/dimtass/meta-allwinner-hx/blob/master/recipes-kernel/linux/linux-stable_4.19.bb
> >
> > And this is the conf folder
> > https://gitlab.com/dimtass/meta-allwinner-hx/tree/master/conf
> >
> > For some reason I can't figure out why modules are not ending up in the
> image.
> >
> > If I do it manually in a do_install_append like this:
> > do_install_append() {
> > # Install kernel-modules
> > install -d ${D}${nonarch_base_libdir}
> > oe_runmake INSTALL_MOD_PATH=${D} modules_install
> > }
> >
> > then it works, but I guess that shouldn't be the right way.
> >
> > Any suggestions or ideas?
> >
> > Thanks!
> > --
> > ___
> > yocto mailing list
> > yocto@yoctoproject.org
> > https://lists.yoctoproject.org/listinfo/yocto
>
>
>
> --
> - Thou shalt not follow the NULL pointer, for chaos and madness await
> thee at its end
> - "Use the force Harry" - Gandalf, Star Trek II
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Hycontek Linux Touchscreen Driver

[Shravan Singh]

Hello All,

I have a 7" inch Display connected to Raspberrypi-cm3 which using hycontex
capacitive touch screen driver.
hy46xx_ts

So my question is.
Is there a  linux driver for hycontek touchscreen driver? Or would I have
to write one for it?

I am unable to find any touchscreen driver with the same name under Linux
master
https://github.com/torvalds/linux

On their website they do offer a Linux_driver_sample_code.zip file. But
having a quick glance at it. It feels like that's more for Android devices.
https://www.hycontek.com/en/category/products-en/touch-en#tab2
So I guess my only reservation in creating one is that, If there is an
already existing driver then that would save a considerable amount of time
in creating and then testing it.

I have attached their linux sample code

Regards,
Shravan Singh
(239) 243-0838

Blue Sparq, Inc.
928 NE 24th Lane unit 4 and 5.
Cape Coral, FL 33993

IMPORTANT: The contents of this email and any attachments are confidential.
They are intended for the named recipient(s) only. If you have received
this email by mistake, please notify the sender immediately and do not
disclose the contents to anyone or make copies thereof.
/* drivers/input/touchscreen/hy46xx_ts.c
 *
 * HYCON hy46xx TouchScreen driver.
 *
 * Copyright (c) 2010  Hycon tech Ltd.
 *
 * This software is licensed under the terms of the GNU General Public
 * License version 2, as published by the Free Software Foundation, and
 * may be copied, distributed, and modified under those terms.
 *
 * This program is distributed in the hope that it will be useful,
 * but WITHOUT ANY WARRANTY; without even the implied warranty of
 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 * GNU General Public License for more details.
 *
 */

#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 

#include 
#include 
#include 
#include 
#include 
#include 

#include "hy46xx_ts.h"

#define hy46xx_ts_suspend   NULL
#define hy46xx_ts_resumeNULL

//static struct i2c_client *this_client;
static struct mutex g_device_mutex;

//
static int i2c_interface_recv(struct i2c_client* client, unsigned char* 
pbt_buf, int dw_lenth)
{
int ret;
ret=i2c_master_recv(client, pbt_buf, dw_lenth);
if(ret<=0)
{
return 0;
}  
return ret;
}
//
static int i2c_interface_send(struct i2c_client* client, unsigned char* 
pbt_buf, int dw_lenth)
{
int ret;
ret=i2c_master_send(client, pbt_buf, dw_lenth);
if(ret<0)
{
return 0;
}
return ret;
}

/**/

int hy46xx_i2c_Read(struct i2c_client *client, char *writebuf, int writelen, 
char *readbuf, int readlen)
{
int ret;

if (writelen > 0) {
struct i2c_msg msgs[] = {
{
 .addr = client->addr,
 .flags = 0,
 .len = writelen,
 .buf = writebuf,
 },
{
 .addr = client->addr,
 .flags = 1,
 .len = readlen,
 .buf = readbuf,
 },
};
ret = i2c_transfer(client->adapter, msgs, 2);
if (ret < 0)
dev_err(&client->dev, "f%s: i2c read error.\n",
__func__);
}
else {
struct i2c_msg msgs[] = {
{
 .addr = client->addr,
 .flags = 1,
 .len = readlen,
 .buf = readbuf,
 },
};
ret = i2c_transfer(client->adapter, msgs, 1);

if (ret < 0)
dev_err(&client->dev, "%s:i2c read error.\n", __func__);
}

return ret;
}
/**/
int hy46xx_i2c_Write(struct i2c_client *client, char *writebuf, int writelen)
{
int ret;
struct i2c_msg msg[] = {
{
 .addr = client->addr,
 .flags = 0,
 .len = writelen,
 .buf = writebuf,
 },
};
ret = i2c_transfer(client->adapter, msg, 1);
if (ret < 0)
dev_err(&client->dev, "%s i2c write error.\n", __func__);
return ret;
}
/**/
int h

[yocto] Yocto Project Newcomer & Unassigned Bugs - Help Needed

[Stephen K Jolley]

All,

 

The triage team is starting to try and collect up and classify bugs which a 
newcomer to the project would be able to work on in a way which means people 
can find them. They're being listed on the triage page under the appropriate 
heading:

 

  
https://wiki.yoctoproject.org/wiki/Bug_Triage#Newcomer_Bugs

 

The idea is these bugs should be straight forward for a person to help work on 
who doesn't have deep experience with the project.  If anyone can help, please 
take ownership of the bug and send patches!  If anyone needs help/advice there 
are people on irc who can likely do so, or some of the more experienced 
contributors will likely be happy to help too.

 

Also, 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 298 unassigned 
or newcomer 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 four different "priority" classes right now, 
“3.1”, “3.2, "3.99" and "Future", the more pressing/urgent issues being in 
"3.1" and then “3.2”.

 

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 ( 
 sjolley.yp...@gmail.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_or_Newcomer_Bugs

 

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

7867 SW Bayberry Dr., Beaverton, OR 97007

*Cell:(208) 244-4460

* Email: s  
jolley.yp...@gmail.com  

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

[yocto] Building only the app and not the Linux core

[gholhak...@yahoo.com]

Hi all,

I would like to build my yocto project, but only my applications. I mean, I 
would like to separate my Linux build and the application build.
I want to just have my meta-layer which contains my application being build by 
calling the bitbake command.
Can anyone give me a pointer? Using the multiconfig is the way to do it?

Best
Em

P.S. If I want to be more specific, I just want to use Yocto as a 
cross-compilation tool for baremetal applications.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Building only the app and not the Linux core

[Paul Barker]

On Tue, 12 Nov 2019, at 15:33, gholhak...@yahoo.com wrote:
> Hi all,
> 
> I would like to build my yocto project, but only my applications. I 
> mean, I would like to separate my Linux build and the application build.
> I want to just have my meta-layer which contains my application being 
> build by calling the bitbake command.
> Can anyone give me a pointer? Using the multiconfig is the way to do it?
> 
> Best
> Em
> 
> P.S. If I want to be more specific, I just want to use Yocto as a 
> cross-compilation tool for baremetal applications.

You could start by looking at how meta-freertos 
(https://github.com/aehs29/meta-freertos) achieves this. It has support for 
running the resulting bare-metal app under qemu which you might not need, but 
the rest of freertos-image.bbclass is probably a good reference.

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

[yocto] Yocto Project Status WW46'19

[sjolley.yp.pm]

Current Dev Position: YP 3.1 M1 

Next Deadline: YP 3.1 M1 build Dec. 2, 2019

 

SWAT Team Rotation:

*   SWAT lead is currently: Anuj 
*   SWAT team rotation: Anuj -> Chen on Nov. 15, 2019
*   SWAT team rotation: Chen > Paul on Nov. 22, 2019
*
https://wiki.yoctoproject.org/wiki/Yocto_Build_Failure_Swat_Team

 

Next Team Meetings:

*   Bug Triage meeting Thursday Nov. 14th at 7:30am PDT (
 https://zoom.us/j/454367603)
*   Monthly Project Meeting Tuesday Dec. 3rd at 8am PDT (
 https://zoom.us/j/990892712)
*   Weekly Engineering Sync Tuesday Nov. 12th at 8am PDT (
 https://zoom.us/j/990892712)
*   Twitch - Next event is Tuesday Nov. 12th at 8am PDT (
 https://www.twitch.tv/yocto_project)

 

Key Status/Updates:

*   YP 2.7.2 is still undergoing QA
*   There were some key fixes for pseudo related issues which mean it
continues to work with modern distros like Fedora 31.
*   Patches have continued to merge and master is staying roughly
current with the pending patch queue but there continue to be recurring
build failures that are not being addressed.
*   The YP TSC worked on and shared a proposal on how an LTS release
could work which is available at:

https://docs.google.com/document/d/1AwAFDf52f_FoXksbHEVUMlu4hpcI0JMGVG-Kj_sU
kyc/ . There has been much discussion about this, patience would be
appreciated as the TSC and governing board work through this to come up with
plans on how we proceed.
*   We are continuing to collect ideas for YP 3.1 in this document:

https://docs.google.com/document/d/1UKZIGe88-eq3-pOPtkAvFAegbQDzhy_f4ye64yjn
ABc/edit?usp=sharing
*   If anyone has any status items for the project they'd like to add to
the weekly reports, please email Richard and Stephen.

 

Proposed YP 3.1 Milestone Dates:

*   YP 3.1 M1 Proposed build date 12/2/2019
*   YP 3.1 M1 Proposed release date 12/13/2019
*   YP 3.1 M2 Proposed build date 1/20/2020
*   YP 3.1 M2 Proposed release date 1/31/2020
*   YP 3.1 M3 Proposed build date 2/24/2020
*   YP 3.1 M3 Proposed release date 3/6/2020
*   YP 3.1 M4 Proposed build date  3/30/2020
*   YP 3.1 M4 Proposed release date  4/24/2020

 

Planned upcoming dot releases:

*   YP 3.0.1 has patches being queued in poky-contrib
*   YP 2.7.2 (Warrior) is in QA.

 

Tracking Metrics:

*   WDD 2508 (last week 2518) (

https://wiki.yoctoproject.org/charts/combo.html)
*   Poky Patch Metrics  

*   Total patches found: 1445 (last week 1446)
*   Patches in the Pending State: 579 (40%) [last week 579 (40%)]

 

The Yocto Project's technical governance is through its Technical Steering
Committee, more information is available at:

 
https://wiki.yoctoproject.org/wiki/TSC

 

The Status reports are now stored on the wiki at:

https://wiki.yoctoproject.org/wiki/Weekly_Status

 

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

 

Thanks,

 

Stephen K. Jolley

Yocto Project Project Manager

*Cell:(208) 244-4460

* Email:   
sjolley.yp...@gmail.com

 

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

Re: [yocto] Building only the app and not the Linux core

[Ross Burton]

On 12/11/2019 15:33, gholhak...@yahoo.com wrote:

Hi all,

I would like to build my yocto project, but only my applications. I 
mean, I would like to separate my Linux build and the application build.
I want to just have my meta-layer which contains my application being 
build by calling the bitbake command.

Can anyone give me a pointer? Using the multiconfig is the way to do it?

Best
Em

P.S. If I want to be more specific, I just want to use Yocto as a 
cross-compilation tool for baremetal applications.


Baremetal != "just my app and not Linux".

If you want to build a bare metal application then setup the 
distribution as such: meta-freertos is one example using FreeRTOS, and 
we have newlib or baremetal options for the toolchain.  Using Linux and 
glibc is just the default and not hardcoded.


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

Re: [yocto] Building only the app and not the Linux core

[Ross Burton]

On 12/11/2019 16:17, gholhak...@yahoo.com wrote:
My question now is, how can I avoid hassle of building the x86_64-linux? 
I just need my test.elf file.


Have a look in that folder to see what it is building.  That directory 
is for native tools, like GCC.


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

Re: [yocto] Error Building Valgrind_3.15 for yocto

[Khem Raj]

On Tue, Nov 12, 2019 at 5:26 AM Sheraz Ali  wrote:
>
> Hi Sir,
>
> I want to add valgrind to my yocto i am using valgrind version 
> (3.15.0-r0 ) i have attached the valgrind source and error log for your 
> reference.
>
> This is the Build Configuration for which i am trying to build valgrind
>
> Build Configuration:
> BB_VERSION= "1.22.0"
> BUILD_SYS = "x86_64-linux"
> NATIVELSBSTRING   = "Ubuntu-14.04"
> TARGET_SYS= "arm-poky-linux-gnueabi"
> MACHINE   = "iwg22m"
> DISTRO= "poky"
> DISTRO_VERSION= "1.6.1"
> TUNE_FEATURES = "armv7a vfp neon callconvention-hard cortexa7"
> TARGET_FPU= "vfp-neon"
> meta
> meta-yocto
> meta-yocto-bsp= "tmp:c4f1f0f491f988901bfd6965f7d10f60cb94a76f"
> meta-renesas
> meta-rzg1 = "tmp:19bf1ed97d04009722bb88a780268822ee60ff83"
> meta-oe
> meta-multimedia   = "tmp:dca466c074c9a35bc0133e7e0d65cca0731e2acf"
> meta-linaro-toolchain = "tmp:8a0601723c06fdb75e62aa0f0cf15fc9d7d90167"
> meta-networking   = "tmp:dca466c074c9a35bc0133e7e0d65cca0731e2acf"
>
> I am getting the following error can you suggest me what to do
>
> arm-poky-linux-gnueabi-gcc: error: unrecognized argument in option 
> '-march=armv7ve'
> arm-poky-linux-gnueabi-gcc: note: valid arguments to '-march=' are: armv2 
> armv2a armv3 armv3m armv4 armv4t armv5 armv5e armv5t armv5te armv6 armv6-m 
> armv6j armv6k armv6s-m armv6t2 armv6z armv6zk armv7 armv7-a armv7-m armv7-r 
> armv7e-m armv8-a armv8-a+crc iwmmxt iwmmxt2 native
> make[5]: *** [intdiv-intdiv.o] Error 1
> make[5]: Leaving directory 
> `/home/sarjoodeen/Project/2018/Nippon/YOCTO/iwG22M-release-bsp/build/tmp/work/cortexa7hf-vfp-neon-poky-linux-gnueabi/valgrind/3.15.0-r0/build/none/tests/arm'
> make[4]: *** [check-am] Error 2
> make[4]: Leaving directory 
> `/home/sarjoodeen/Project/2018/Nippon/YOCTO/iwG22M-release-bsp/build/tmp/work/cortexa7hf-vfp-neon-poky-linux-gnueabi/valgrind/3.15.0-r0/build/none/tests/arm'
> make[3]: *** [check-recursive] Error 1
> make[3]: Leaving directory 
> `/home/sarjoodeen/Project/2018/Nippon/YOCTO/iwG22M-release-bsp/build/tmp/work/cortexa7hf-vfp-neon-poky-linux-gnueabi/valgrind/3.15.0-r0/build/none/tests'
> make[2]: *** [check-recursive] Error 1
> make[2]: Leaving directory 
> `/home/sarjoodeen/Project/2018/Nippon/YOCTO/iwG22M-release-bsp/build/tmp/work/cortexa7hf-vfp-neon-poky-linux-gnueabi/valgrind/3.15.0-r0/build/none'
> make[1]: *** [check-recursive] Error 1
> make[1]: Leaving directory 
> `/home/sarjoodeen/Project/2018/Nippon/YOCTO/iwG22M-release-bsp/build/tmp/work/cortexa7hf-vfp-neon-poky-linux-gnueabi/valgrind/3.15.0-r0/build'
> make: *** [check] Error 2
> make: Leaving directory 
> `/home/sarjoodeen/Project/2018/Nippon/YOCTO/iwG22M-release-bsp/build/tmp/work/cortexa7hf-vfp-neon-poky-linux-gnueabi/valgrind/3.15.0-r0/build'
> ERROR: oe_runmake failed
> WARNING: exit code 1 from a shell command.
> ERROR: Function failed: do_compile_ptest_base (log file is located at 
> /home/sarjoodeen/Project/2018/Nippon/YOCTO/iwG22M-release-bsp/build/tmp/work/cortexa7hf-vfp-neon-poky-linux-gnueabi/valgrind/3.15.0-r0/temp/log.do_compile_ptest_base.29480)
>

somewhere, its messing up compiler flags -march=armv7ve
-mcpu=cortex-a15 -mthumb is being added can you check if you have
bbapends or other places modifying it

> Thanks and Regards
> Sheraz Ali Shah
> --
> ___
> 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] Building only the app and not the Linux core

[Ross Burton]

On 12/11/2019 16:52, gholhak...@yahoo.com wrote:

so you mean there is no way not to build them? I don't need any native tool.
I define my cross-compilation toolchain in my layer.
I asked you in twitter, you said "Use multiconfig to split the Linux 
and  rtos entirely". I could not figure it, so I decided not to bother 
you in twitter and ask it here :)


Have a look and you'll see what it is building.  If you can remove those 
dependencies from your build then it won't build them...


I suspect you can't.  Your cross compiler will be built in the 
x86-64_linux folder for a start.


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

Re: [yocto] Yocto/bitbake recipe 'diff test'?

[Brad Bishop]

> On Nov 12, 2019, at 1:55 AM, Kun Yi  wrote:
>  
> Sure, it's partially due to how we set up the build downstream. Our 
> downstream would put all the needed layers in one bblayers file, so we would 
> have something like:
> 
>   ##OEROOT##/meta \
>   ##OEROOT##/meta-poky \
>   ##OEROOT##/meta-openembedded/meta-oe \
>   ##OEROOT##/meta-openembedded/meta-networking \
>   ##OEROOT##/meta-openembedded/meta-python \
>   ##OEROOT##/meta-phosphor \
>   ##OEROOT##/meta-google \
>   ##OEROOT##/meta-google-gbmc \
>   ##OEROOT##/meta-aspeed \
>   ##OEROOT##/meta-nuvoton \
>   ##OEROOT##/meta-openpower \
>   ##OEROOT##/meta-ingrasys \
>   ##OEROOT##/meta-ingrasys/meta-zaius \
>   ##OEROOT##/meta-quanta \
>   ##OEROOT##/meta-quanta/meta-gsj \
> ...
> 
> The distinct advantage of this approach is that we would be able to build 
> images for different machine types using the same layer conf, so the build 
> doesn't need to be reconfigured if you were to test on another platform.
> 
> The challenge, as you can imagine, is that each meta layer now cannot 'leak' 
> any variable. e.g. if some recipe in meta-quanta sets a variable for quanta 
> systems only, then it must specify "_quanta" or a similar suffix to prevent 
> the variable expansion to apply to other systems. I think this rule is 
> generally preferred upstream, but not sure whether it is an official 
> guideline.
> 
> With my proposal, it would be much easier for a multi-system layer setup like 
> ours to work. Not only that, it would benefit the most common use cases: 
> moving variable definitions in bitbake recipes, or even just adding a 
> variable for a particular machine feature. Having a visible diff would make 
> reviewing the changes so much easier.

Thanks for the background Kun.

I know yocto has a concept of Q&A checks that can be run - would it make sense 
to try something like this via that mechanism?  Emit warnings (which we can 
elevate to build failures in CI) if variables aren’t properly overriden?  That 
is nice because it doesn’t require any changes to our CI system.

I’ve cross posted to the yocto mailing list in case there is any interest or 
ideas there.  Here is a link to the entire thread as I remove a little too much 
context I think…

https://lists.ozlabs.org/pipermail/openbmc/2019-November/019409.html

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

Re: [yocto] Yocto/bitbake recipe 'diff test'?

[Paul Barker]

On Tue, 12 Nov 2019, at 18:05, Brad Bishop wrote:
> 
> 
> > On Nov 12, 2019, at 1:55 AM, Kun Yi  wrote:
> >  
> > Sure, it's partially due to how we set up the build downstream. Our 
> > downstream would put all the needed layers in one bblayers file, so we 
> > would have something like:
> > 
> >   ##OEROOT##/meta \
> >   ##OEROOT##/meta-poky \
> >   ##OEROOT##/meta-openembedded/meta-oe \
> >   ##OEROOT##/meta-openembedded/meta-networking \
> >   ##OEROOT##/meta-openembedded/meta-python \
> >   ##OEROOT##/meta-phosphor \
> >   ##OEROOT##/meta-google \
> >   ##OEROOT##/meta-google-gbmc \
> >   ##OEROOT##/meta-aspeed \
> >   ##OEROOT##/meta-nuvoton \
> >   ##OEROOT##/meta-openpower \
> >   ##OEROOT##/meta-ingrasys \
> >   ##OEROOT##/meta-ingrasys/meta-zaius \
> >   ##OEROOT##/meta-quanta \
> >   ##OEROOT##/meta-quanta/meta-gsj \
> > ...
> > 
> > The distinct advantage of this approach is that we would be able to build 
> > images for different machine types using the same layer conf, so the build 
> > doesn't need to be reconfigured if you were to test on another platform.
> > 
> > The challenge, as you can imagine, is that each meta layer now cannot 
> > 'leak' any variable. e.g. if some recipe in meta-quanta sets a variable for 
> > quanta systems only, then it must specify "_quanta" or a similar suffix to 
> > prevent the variable expansion to apply to other systems. I think this rule 
> > is generally preferred upstream, but not sure whether it is an official 
> > guideline.
> > 
> > With my proposal, it would be much easier for a multi-system layer setup 
> > like ours to work. Not only that, it would benefit the most common use 
> > cases: moving variable definitions in bitbake recipes, or even just adding 
> > a variable for a particular machine feature. Having a visible diff would 
> > make reviewing the changes so much easier.
> 
> Thanks for the background Kun.
> 
> I know yocto has a concept of Q&A checks that can be run - would it 
> make sense to try something like this via that mechanism?  Emit 
> warnings (which we can elevate to build failures in CI) if variables 
> aren’t properly overriden?  That is nice because it doesn’t require any 
> changes to our CI system.
> 
> I’ve cross posted to the yocto mailing list in case there is any 
> interest or ideas there.  Here is a link to the entire thread as I 
> remove a little too much context I think…
> 
> https://lists.ozlabs.org/pipermail/openbmc/2019-November/019409.html

This is something I covered in the Yocto Project Summit in Lyon at the end of 
October. I'm hoping to get the project documentation updated to reflect what 
was discussed but that will take a little time.

In the mean time, the `yocto-check-layer` script is what you want here - it 
calculates the signatures for all recipes before adding the layer in question 
and then again after adding the layer. If the signatures differ that means one 
or more variables or tasks has been changed unconditionally. This check can't 
be an ordinary QA test as it relies on the layer being added during the test 
and on multiple bitbake invocations.

There are many ways to make modifications dependent on the selected MACHINE, 
DISTRO, DISTRO_FEATURES, MACHINE_FEATURES, IMAGE_FEATURES, etc - more than just 
using simple overrides everywhere. Until the video is up or the documentation 
is updated, have a look at my slides at the start of the Day 1 slide deck at 
https://wiki.yoctoproject.org/wiki/YP_Summit_Lyon_2019.

Thanks,

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

[yocto] [meta-mingw][PATCH] Add sdktest image

[Joshua Watt]

Adds a specific image that can be used to build MinGW SDKs. This image
includes extra recipes that are know to build for MinGW so that they can
be tested on the autobuilder.

Signed-off-by: Joshua Watt 
---
 recipes-core/images/core-image-mingw-sdktest.bb | 16 
 1 file changed, 16 insertions(+)
 create mode 100644 recipes-core/images/core-image-mingw-sdktest.bb

diff --git a/recipes-core/images/core-image-mingw-sdktest.bb 
b/recipes-core/images/core-image-mingw-sdktest.bb
new file mode 100644
index 000..6215aef
--- /dev/null
+++ b/recipes-core/images/core-image-mingw-sdktest.bb
@@ -0,0 +1,16 @@
+# Copyright (C) 2019 Garmin Ltd. or its subsidiaries
+# Released under the MIT license (see COPYING.MIT for the terms)
+
+require ${COREBASE}/meta/recipes-core/images/core-image-minimal.bb
+
+# Other recipes that should be tested as part of the SDK in case some one wants
+# to include them
+TOOLCHAIN_HOST_TASK += "\
+nativesdk-curl \
+nativesdk-dbus \
+nativesdk-dtc \
+nativesdk-libarchive \
+nativesdk-swig \
+nativesdk-wayland \
+"
+
-- 
2.23.0

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

Re: [yocto] Error Building Valgrind_3.15 for yocto

[Randy MacLeod]

On 11/11/19 9:33 PM, Sheraz Ali wrote:


Hi Sir,

        I want to add valgrind to my yocto i am using valgrind version 
(3.15.0-r0 ) i have attached the valgrind source and error log for 
your reference.


This is the Build Configuration for which i am trying to build valgrind

Build Configuration:
BB_VERSION    = "1.22.0"
BUILD_SYS = "x86_64-linux"
NATIVELSBSTRING   = "Ubuntu-14.04"
TARGET_SYS    = "arm-poky-linux-gnueabi"
MACHINE   = "iwg22m"
DISTRO    = "poky"
DISTRO_VERSION    = "1.6.1"

That's a very old  release and is not supported officially by Yocto or 
even by the community:

   https://wiki.yoctoproject.org/wiki/Releases

Do you have a vendor who supports this collection of layers?
If not, there are many companies who are likley able to do so.


TUNE_FEATURES = "armv7a vfp neon callconvention-hard cortexa7"
TARGET_FPU    = "vfp-neon"
meta
meta-yocto
meta-yocto-bsp    = "tmp:c4f1f0f491f988901bfd6965f7d10f60cb94a76f"
meta-renesas
meta-rzg1 = "tmp:19bf1ed97d04009722bb88a780268822ee60ff83"
meta-oe
meta-multimedia   = "tmp:dca466c074c9a35bc0133e7e0d65cca0731e2acf"
meta-linaro-toolchain = "tmp:8a0601723c06fdb75e62aa0f0cf15fc9d7d90167"
meta-networking   = "tmp:dca466c074c9a35bc0133e7e0d65cca0731e2acf"

I am getting the following error can you suggest me what to do

/*arm-poky-linux-gnueabi-gcc: error: unrecognized argument in option 
'-march=armv7ve'*/
/*arm-poky-linux-gnueabi-gcc: note: valid arguments to '-march=' are: 
armv2 armv2a armv3 armv3m armv4 armv4t armv5 armv5e armv5t armv5te 
armv6 armv6-m armv6j armv6k armv6s-m armv6t2 armv6z armv6zk armv7 
armv7-a armv7-m armv7-r armv7e-m armv8-a armv8-a+crc iwmmxt iwmmxt2 
native*/




It looks like your BSP layer/vendor (meta-rzg1 perhaps), or perhaps the
toolchain supplier hasn't added support for this arch.

I can understand that you might not be able to upgrade to a
supported Yocto release but if not, it's unlikely that anyone can help.

If you can reproduce the problem on a supported branch with just poky or
with just fewer layers, then you could open a defect against valgrind or 
the toolchain:

   https://bugzilla.yoctoproject.org/

Sorry that I can't be of more assistance.,

../Randy



make[5]: *** [intdiv-intdiv.o] Error 1
make[5]: Leaving directory 
`/home/sarjoodeen/Project/2018/Nippon/YOCTO/iwG22M-release-bsp/build/tmp/work/cortexa7hf-vfp-neon-poky-linux-gnueabi/valgrind/3.15.0-r0/build/none/tests/arm'

make[4]: *** [check-am] Error 2
make[4]: Leaving directory 
`/home/sarjoodeen/Project/2018/Nippon/YOCTO/iwG22M-release-bsp/build/tmp/work/cortexa7hf-vfp-neon-poky-linux-gnueabi/valgrind/3.15.0-r0/build/none/tests/arm'

make[3]: *** [check-recursive] Error 1
make[3]: Leaving directory 
`/home/sarjoodeen/Project/2018/Nippon/YOCTO/iwG22M-release-bsp/build/tmp/work/cortexa7hf-vfp-neon-poky-linux-gnueabi/valgrind/3.15.0-r0/build/none/tests'

make[2]: *** [check-recursive] Error 1
make[2]: Leaving directory 
`/home/sarjoodeen/Project/2018/Nippon/YOCTO/iwG22M-release-bsp/build/tmp/work/cortexa7hf-vfp-neon-poky-linux-gnueabi/valgrind/3.15.0-r0/build/none'

make[1]: *** [check-recursive] Error 1
make[1]: Leaving directory 
`/home/sarjoodeen/Project/2018/Nippon/YOCTO/iwG22M-release-bsp/build/tmp/work/cortexa7hf-vfp-neon-poky-linux-gnueabi/valgrind/3.15.0-r0/build'

make: *** [check] Error 2
make: Leaving directory 
`/home/sarjoodeen/Project/2018/Nippon/YOCTO/iwG22M-release-bsp/build/tmp/work/cortexa7hf-vfp-neon-poky-linux-gnueabi/valgrind/3.15.0-r0/build'

ERROR: oe_runmake failed
WARNING: exit code 1 from a shell command.
ERROR: Function failed: do_compile_ptest_base (log file is located at 
/home/sarjoodeen/Project/2018/Nippon/YOCTO/iwG22M-release-bsp/build/tmp/work/cortexa7hf-vfp-neon-poky-linux-gnueabi/valgrind/3.15.0-r0/temp/log.do_compile_ptest_base.29480)


Thanks and Regards
Sheraz Ali Shah
--
Thanks and Regards
Sheraz Ali Shah



--
# Randy MacLeod
# Wind River Linux

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

[yocto] Occasionally long boot after erasing and re creating ext4 fs

[Yoav Rubin]

Linux 32bit 4.1.8 kernel , PowerPC , embedded , real time patch , systemV
init.
I had an ext4 file system mounted at /run/media/mmcblk0p1.
I unmounted and erased it and then recreated it:

1)
fdisk /dev/mmcblk0
-> select: n
-> enter (choose default value for start)
-> enter (choose default value for end)
-> enter (choose default)
-> enter (choose default)
-> select: w  (write changes to MBR)
(pressed n , four times enter and w).



2) mkfs.ext4 -E nodiscard -F /dev/mmcblk0p1

After restart I got the following error:
```
EXT4-fs (mmcblk0p1): Filesystem with huge files cannot be mounted RDWR
without CONFIG_LBDAF
```

Because I don't need huge_files support (files bigger than 2TB)
I used:
```
mkfs.ext4 -O ^huge_file -E nodiscard -F /dev/mmcblk0p1
```
and now the system works with /dev/mmcblk0p1 mounted at
/run/media/mmcblk0p1.

the problem is that since these actions , sometimes the boot takes a long
time and sometimes not. I have no Idea why.


**bad dmesg:**
```
[5.775060] udevd[872]: renamed network interface eth0 to fm2-gb0
[5.793777] udevd[873]: renamed network interface eth1 to fm2-gb1
[7.482486] EXT4-fs (mmcblk0p1): recovery complete
[7.487834] EXT4-fs (mmcblk0p1): mounted filesystem with ordered data
mode. Opts: (null)
[7.728026] random: dd urandom read with 29 bits of entropy available
[9.113007] random: nonblocking pool is initialized
[   43.058167]
   [rmStart]:The OSA version is: LINUXA4.1.0 from 16-04-2019
[   43.094075] [rmStart] gpr: id: 0 - physAddr: 0x1a000 - len: 0x1000 -
memAddr: 0xf1afe000
[   43.104048] [rmStart] dcfg: id: 7 - physAddr: 0x1900e - len: 0x1000
- memAddr: 0xf1c7a000
```


**good dmesg:**
```
[5.773918] udevd[872]: renamed network interface eth0 to fm2-gb0
[5.792785] udevd[873]: renamed network interface eth1 to fm2-gb1
[7.508329] EXT4-fs (mmcblk0p1): recovery complete
[7.513673] EXT4-fs (mmcblk0p1): mounted filesystem with ordered data
mode. Opts: (null)
[7.754070] random: dd urandom read with 29 bits of entropy available
[9.699353]
   [rmStart]:The OSA version is: LINUXA4.1.0 from 16-04-2019
[9.710210] [rmStart] gpr: id: 0 - physAddr: 0x1a000 - len: 0x1000 -
memAddr: 0xf1afe000
```



**/etc/fstab:**
```
/dev/root/auto   defaults
 1  1
proc /procproc   defaults
 0  0
devpts   /dev/pts devpts mode=0620,gid=5
0  0
tmpfs/run tmpfs
 mode=0755,nodev,nosuid,strictatime 0  0
tmpfs/var/volatiletmpfs  defaults
 0  0
/dev/mmcblk0p1 /run/media/mmcblk0p1 ext4 defaults,async,noauto 0 0
```

**tune2fs -l /dev/mmcblk0p1**
```
tune2fs 1.42.9 (28-Dec-2013)
Filesystem volume name:   
Last mounted on:  
Filesystem UUID:  49ef04af-109b-433d-81b8-e5d42c947c8c
Filesystem magic number:  0xEF53
Filesystem revision #:1 (dynamic)
Filesystem features:  has_journal ext_attr resize_inode dir_index
filetype needs_recovery extent flex_bg sparse_super large_file uninit_bg
dir_nlink extra_isize
Filesystem flags: unsigned_directory_hash
Default mount options:user_xattr acl
Filesystem state: clean
Errors behavior:  Continue
Filesystem OS type:   Linux
Inode count:  956592
Block count:  3825408
Reserved block count: 191270
Free blocks:  3723263
Free inodes:  956581
First block:  0
Block size:   4096
Fragment size:4096
Reserved GDT blocks:  933
Blocks per group: 32768
Fragments per group:  32768
Inodes per group: 8176
Inode blocks per group:   511
Flex block group size:16
Filesystem created:   Wed Dec 13 15:17:05 2017
Last mount time:  Thu Jan  1 00:00:07 1970
Last write time:  Thu Jan  1 00:00:07 1970
Mount count:  9
Maximum mount count:  -1
Last checked: Wed Dec 13 15:17:05 2017
Check interval:   0 ()
Lifetime writes:  132 MB
Reserved blocks uid:  0 (user root)
Reserved blocks gid:  0 (group root)
First inode:  11
Inode size:   256
Required extra isize: 28
Desired extra isize:  28
Journal inode:8
Default directory hash:   half_md4
Directory Hash Seed:  d3fe2c1f-7dbb-43d5-b6d6-7b867b71386c
Journal backup:   inode blocks
```



*After a couple of prints I noticed the delay occurs at
populate-volatile.sh*
*in a specific line. I marked it at file's end.*
*this is the script:*


#!/bin/sh

### BEGIN INIT INFO

# Provides: volatile

# Required-Start:   $local_fs

# Required-Stop:  $local_fs

# Default-Start:S

# Default-Stop:

# Short-Description:  Populate the volatile filesystem

### END INIT INFO

echo "**populate-volatile start***"

# Get ROOT_DIR

DIRNAME=`dirname $0`

ROOT_DIR=`echo $DIRNAME | sed -ne 's:/etc/.*::p'`



[ -e ${ROOT_DIR

[yocto] pkg-config not found

[Mark Hawthorne]

I have an autotools build that uses the following autoconfig file:

AC_INIT([my-program], [1])
AM_INIT_AUTOMAKE([-Wall -Werror foreign])
AC_LANG(C++)
AC_PROG_CXX
AX_PTHREAD()
PKG_CHECK_MODULES(LIBPNG, libpng >= 1.6.34)
PKG_CHECK_MODULES(FREETYPE2, freetype2 >= 21.0.15)
PKG_CHECK_MODULES(EGL, egl > 0)
PKG_CHECK_MODULES(GLES2, glesv2 > 0)
PKG_CHECK_MODULES(GLM, glm >= 0.9.9)
PKG_CHECK_MODULES(SPATIALITE, spatialite >= 4.3.0)
AC_CONFIG_FILES([Makefile])
AC_OUTPUT


I have made the following bitbake recipe file


SUMMARY = "my program"
HOMEPAGE = ""
DESCRIPTION = ""
LICENSE = "MIT"
LIC_FILES_CHKSUM =
"file://${COMMON_LICENSE_DIR}/MIT;md5=0835ade698e0bcf8506ecda2f7b4f302"

SRC_URI = "git://u...@bitbucket.org/user/myrepo.git"

SRCREV = "dc1391dbc82702fd0126d4156d4ab59571427efe"

DEPENDS_${PN} = "libpng freetype glm libegl libgles2 libspatialite"

S = "${WORKDIR}/git"

inherit pkgconfig autotools


The build fails with this error:

configure: error: in
`/home/user/Documents/tisdk/build/arago-tmp-external-arm-toolchain/work/armv7at2hf-neon-linux-gnueabi/my-program/1.0-r0/build':
configure: error: The pkg-config script could not be found or is too old.
Make sure it is in your PATH or set the PKG_CONFIG environment variable to
the full path to pkg-config.

Alternatively, you may set the environment variables LIBPNG_CFLAGS and
LIBPNG_LIBS to avoid the need to call pkg-config.


I have looked at several other autotools/pkgconfig recipes and it appears
that I am doing everything the same. What is missing?
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] pkg-config not found

[Adrian Bunk]

On Tue, Nov 12, 2019 at 03:06:25PM -0600, Mark Hawthorne wrote:
>...
> DEPENDS_${PN} = "libpng freetype glm libegl libgles2 libspatialite"
>...

DEPENDS, not DEPENDS_${PN}

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

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

Re: [yocto] pkg-config not found

[Mark Hawthorne]

Thank you. I have fixed this issue but the original pkg-config error still
persists.

On Tue, Nov 12, 2019 at 3:41 PM Adrian Bunk  wrote:

> On Tue, Nov 12, 2019 at 03:06:25PM -0600, Mark Hawthorne wrote:
> >...
> > DEPENDS_${PN} = "libpng freetype glm libegl libgles2 libspatialite"
> >...
>
> DEPENDS, not DEPENDS_${PN}
>
> cu
> Adrian
>
> --
>
>"Is there not promise of rain?" Ling Tan asked suddenly out
> of the darkness. There had been need of rain for many days.
>"Only a promise," Lao Er said.
>Pearl S. Buck - Dragon Seed
>
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] No Package Provides /bin/awk

[Wayne Li]

Dear Yocto Developers,

I'm trying to to build a Yocto kernel for a T4240 RDB.  When I run "bitbake
fsl-image-full" to build the entire linux image, I get an error that says
"Can't install kernel-devsrc-1.0-r0@t4240rdb_64b: no package provides
/bin/awk".  Here's the entire error print that I see:

https://gist.github.com/WayneZhenLi/e35f65081092cf1f24df29ec369c701c

Anyway I'm confused about this error because /bin/awk does exist.  Like if
I run "/bin/awk" in the console I see help info come up describing how to
use a program called "gawk".  Why can't bitbake find /bin/awk then?  Or am
I misunderstanding what this error is trying to say?  I mean I'm assuming
it's just not able to find /bin/awk but maybe the error means something
else?  Or maybe /bin/awk is actually relative to some path?  Let me know
your thoughts.

-Thanks!, Wayne Li
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] pkg-config not found

[Khem Raj]

On Tue, Nov 12, 2019 at 2:00 PM Mark Hawthorne
 wrote:
>
> Thank you. I have fixed this issue but the original pkg-config error still 
> persists.
>

do a clean build after above change

bitbake -ccleanall 
bitbake 

does that help ?

> On Tue, Nov 12, 2019 at 3:41 PM Adrian Bunk  wrote:
>>
>> On Tue, Nov 12, 2019 at 03:06:25PM -0600, Mark Hawthorne wrote:
>> >...
>> > DEPENDS_${PN} = "libpng freetype glm libegl libgles2 libspatialite"
>> >...
>>
>> DEPENDS, not DEPENDS_${PN}
>>
>> cu
>> Adrian
>>
>> --
>>
>>"Is there not promise of rain?" Ling Tan asked suddenly out
>> of the darkness. There had been need of rain for many days.
>>"Only a promise," Lao Er said.
>>Pearl S. Buck - Dragon Seed
>>
> --
> ___
> 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] pkg-config not found

[Mark Hawthorne]

No, it did not help

It appears from the config.log file that the PKG_CONFIG variable never gets
set. I'm sorting through the bbclass files to figure out why this is not
getting set...

PKG_CONFIG=''
PKG_CONFIG_LIBDIR='/home/mark/Documents/tisdk/build/arago-tmp-external-arm-toolchain/work/armv7at2hf-neon-linux-gnueabi/myprogram/1.0-r0/recipe-sysroot/usr/lib/pkgconfig'
PKG_CONFIG_PATH='/home/mark/Documents/tisdk/build/arago-tmp-external-arm-toolchain/work/armv7at2hf-neon-linux-gnueabi/myprogram/1.0-r0/recipe-sysroot/usr/lib/pkgconfig:/home/mark/Documents/tisdk/build/arago-tmp-external-arm-toolchain/work/armv7at2hf-neon-linux-gnueabi/myprogram/1.0-r0/recipe-sysroot/usr/share/pkgconfig'

On Tue, Nov 12, 2019 at 4:22 PM Khem Raj  wrote:

> On Tue, Nov 12, 2019 at 2:00 PM Mark Hawthorne
>  wrote:
> >
> > Thank you. I have fixed this issue but the original pkg-config error
> still persists.
> >
>
> do a clean build after above change
>
> bitbake -ccleanall 
> bitbake 
>
> does that help ?
>
> > On Tue, Nov 12, 2019 at 3:41 PM Adrian Bunk  wrote:
> >>
> >> On Tue, Nov 12, 2019 at 03:06:25PM -0600, Mark Hawthorne wrote:
> >> >...
> >> > DEPENDS_${PN} = "libpng freetype glm libegl libgles2 libspatialite"
> >> >...
> >>
> >> DEPENDS, not DEPENDS_${PN}
> >>
> >> cu
> >> Adrian
> >>
> >> --
> >>
> >>"Is there not promise of rain?" Ling Tan asked suddenly out
> >> of the darkness. There had been need of rain for many days.
> >>"Only a promise," Lao Er said.
> >>Pearl S. Buck - Dragon Seed
> >>
> > --
> > ___
> > 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] pkg-config not found

[Mark Hawthorne]

Khem,

I found a recipe that you made a few years ago where you addressed this
problem:

http://cgit.openembedded.org/meta-openembedded/tree/meta-oe/recipes-extended/boinc/boinc-client_7.12.bb

You solved it by exporting PKG_CONFIG

export PKG_CONFIG = "${STAGING_BINDIR_NATIVE}/pkg-config"

This seems like it may be the incorrect way to do it and there needs to be
an update in the configure.ac file instead?

On Tue, Nov 12, 2019 at 4:44 PM Mark Hawthorne 
wrote:

> No, it did not help
>
> It appears from the config.log file that the PKG_CONFIG variable never
> gets set. I'm sorting through the bbclass files to figure out why this is
> not getting set...
>
> PKG_CONFIG=''
>
> PKG_CONFIG_LIBDIR='/home/mark/Documents/tisdk/build/arago-tmp-external-arm-toolchain/work/armv7at2hf-neon-linux-gnueabi/myprogram/1.0-r0/recipe-sysroot/usr/lib/pkgconfig'
>
> PKG_CONFIG_PATH='/home/mark/Documents/tisdk/build/arago-tmp-external-arm-toolchain/work/armv7at2hf-neon-linux-gnueabi/myprogram/1.0-r0/recipe-sysroot/usr/lib/pkgconfig:/home/mark/Documents/tisdk/build/arago-tmp-external-arm-toolchain/work/armv7at2hf-neon-linux-gnueabi/myprogram/1.0-r0/recipe-sysroot/usr/share/pkgconfig'
>
> On Tue, Nov 12, 2019 at 4:22 PM Khem Raj  wrote:
>
>> On Tue, Nov 12, 2019 at 2:00 PM Mark Hawthorne
>>  wrote:
>> >
>> > Thank you. I have fixed this issue but the original pkg-config error
>> still persists.
>> >
>>
>> do a clean build after above change
>>
>> bitbake -ccleanall 
>> bitbake 
>>
>> does that help ?
>>
>> > On Tue, Nov 12, 2019 at 3:41 PM Adrian Bunk  wrote:
>> >>
>> >> On Tue, Nov 12, 2019 at 03:06:25PM -0600, Mark Hawthorne wrote:
>> >> >...
>> >> > DEPENDS_${PN} = "libpng freetype glm libegl libgles2 libspatialite"
>> >> >...
>> >>
>> >> DEPENDS, not DEPENDS_${PN}
>> >>
>> >> cu
>> >> Adrian
>> >>
>> >> --
>> >>
>> >>"Is there not promise of rain?" Ling Tan asked suddenly out
>> >> of the darkness. There had been need of rain for many days.
>> >>"Only a promise," Lao Er said.
>> >>Pearl S. Buck - Dragon Seed
>> >>
>> > --
>> > ___
>> > 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] pkg-config not found

[Khem Raj]

On Tue, Nov 12, 2019 at 4:29 PM Mark Hawthorne
 wrote:
>
> Khem,
>
> I found a recipe that you made a few years ago where you addressed this 
> problem:
>
> http://cgit.openembedded.org/meta-openembedded/tree/meta-oe/recipes-extended/boinc/boinc-client_7.12.bb
>
> You solved it by exporting PKG_CONFIG
>
> export PKG_CONFIG = "${STAGING_BINDIR_NATIVE}/pkg-config"
>
> This seems like it may be the incorrect way to do it and there needs to be an 
> update in the configure.ac file instead?

in configure.ac you can add something like this

PKG_PROG_PKG_CONFIG
if test -z "$PKG_CONFIG"; then
  AC_MSG_WARN([Cannot find pkg-config, make sure it is installed in your PATH])
fi

>
> On Tue, Nov 12, 2019 at 4:44 PM Mark Hawthorne  
> wrote:
>>
>> No, it did not help
>>
>> It appears from the config.log file that the PKG_CONFIG variable never gets 
>> set. I'm sorting through the bbclass files to figure out why this is not 
>> getting set...
>>
>> PKG_CONFIG=''
>> PKG_CONFIG_LIBDIR='/home/mark/Documents/tisdk/build/arago-tmp-external-arm-toolchain/work/armv7at2hf-neon-linux-gnueabi/myprogram/1.0-r0/recipe-sysroot/usr/lib/pkgconfig'
>> PKG_CONFIG_PATH='/home/mark/Documents/tisdk/build/arago-tmp-external-arm-toolchain/work/armv7at2hf-neon-linux-gnueabi/myprogram/1.0-r0/recipe-sysroot/usr/lib/pkgconfig:/home/mark/Documents/tisdk/build/arago-tmp-external-arm-toolchain/work/armv7at2hf-neon-linux-gnueabi/myprogram/1.0-r0/recipe-sysroot/usr/share/pkgconfig'
>>
>> On Tue, Nov 12, 2019 at 4:22 PM Khem Raj  wrote:
>>>
>>> On Tue, Nov 12, 2019 at 2:00 PM Mark Hawthorne
>>>  wrote:
>>> >
>>> > Thank you. I have fixed this issue but the original pkg-config error 
>>> > still persists.
>>> >
>>>
>>> do a clean build after above change
>>>
>>> bitbake -ccleanall 
>>> bitbake 
>>>
>>> does that help ?
>>>
>>> > On Tue, Nov 12, 2019 at 3:41 PM Adrian Bunk  wrote:
>>> >>
>>> >> On Tue, Nov 12, 2019 at 03:06:25PM -0600, Mark Hawthorne wrote:
>>> >> >...
>>> >> > DEPENDS_${PN} = "libpng freetype glm libegl libgles2 libspatialite"
>>> >> >...
>>> >>
>>> >> DEPENDS, not DEPENDS_${PN}
>>> >>
>>> >> cu
>>> >> Adrian
>>> >>
>>> >> --
>>> >>
>>> >>"Is there not promise of rain?" Ling Tan asked suddenly out
>>> >> of the darkness. There had been need of rain for many days.
>>> >>"Only a promise," Lao Er said.
>>> >>Pearl S. Buck - Dragon Seed
>>> >>
>>> > --
>>> > ___
>>> > yocto mailing list
>>> > yocto@yoctoproject.org
>>> > https://lists.yoctoproject.org/listinfo/yocto
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] pkg-config not found

[Mark Hawthorne]

I added the lines you suggested and it indicates that PKG_CONFIG is not
set. What would cause this to fail in the bitbake environment? It works for
other packages such as pixman.

On Tue, Nov 12, 2019 at 6:38 PM Khem Raj  wrote:

> On Tue, Nov 12, 2019 at 4:29 PM Mark Hawthorne
>  wrote:
> >
> > Khem,
> >
> > I found a recipe that you made a few years ago where you addressed this
> problem:
> >
> >
> http://cgit.openembedded.org/meta-openembedded/tree/meta-oe/recipes-extended/boinc/boinc-client_7.12.bb
> >
> > You solved it by exporting PKG_CONFIG
> >
> > export PKG_CONFIG = "${STAGING_BINDIR_NATIVE}/pkg-config"
> >
> > This seems like it may be the incorrect way to do it and there needs to
> be an update in the configure.ac file instead?
>
> in configure.ac you can add something like this
>
> PKG_PROG_PKG_CONFIG
> if test -z "$PKG_CONFIG"; then
>   AC_MSG_WARN([Cannot find pkg-config, make sure it is installed in your
> PATH])
> fi
>
> >
> > On Tue, Nov 12, 2019 at 4:44 PM Mark Hawthorne <
> markhawthorne...@gmail.com> wrote:
> >>
> >> No, it did not help
> >>
> >> It appears from the config.log file that the PKG_CONFIG variable never
> gets set. I'm sorting through the bbclass files to figure out why this is
> not getting set...
> >>
> >> PKG_CONFIG=''
> >>
> PKG_CONFIG_LIBDIR='/home/mark/Documents/tisdk/build/arago-tmp-external-arm-toolchain/work/armv7at2hf-neon-linux-gnueabi/myprogram/1.0-r0/recipe-sysroot/usr/lib/pkgconfig'
> >>
> PKG_CONFIG_PATH='/home/mark/Documents/tisdk/build/arago-tmp-external-arm-toolchain/work/armv7at2hf-neon-linux-gnueabi/myprogram/1.0-r0/recipe-sysroot/usr/lib/pkgconfig:/home/mark/Documents/tisdk/build/arago-tmp-external-arm-toolchain/work/armv7at2hf-neon-linux-gnueabi/myprogram/1.0-r0/recipe-sysroot/usr/share/pkgconfig'
> >>
> >> On Tue, Nov 12, 2019 at 4:22 PM Khem Raj  wrote:
> >>>
> >>> On Tue, Nov 12, 2019 at 2:00 PM Mark Hawthorne
> >>>  wrote:
> >>> >
> >>> > Thank you. I have fixed this issue but the original pkg-config error
> still persists.
> >>> >
> >>>
> >>> do a clean build after above change
> >>>
> >>> bitbake -ccleanall 
> >>> bitbake 
> >>>
> >>> does that help ?
> >>>
> >>> > On Tue, Nov 12, 2019 at 3:41 PM Adrian Bunk  wrote:
> >>> >>
> >>> >> On Tue, Nov 12, 2019 at 03:06:25PM -0600, Mark Hawthorne wrote:
> >>> >> >...
> >>> >> > DEPENDS_${PN} = "libpng freetype glm libegl libgles2
> libspatialite"
> >>> >> >...
> >>> >>
> >>> >> DEPENDS, not DEPENDS_${PN}
> >>> >>
> >>> >> cu
> >>> >> Adrian
> >>> >>
> >>> >> --
> >>> >>
> >>> >>"Is there not promise of rain?" Ling Tan asked suddenly out
> >>> >> of the darkness. There had been need of rain for many days.
> >>> >>"Only a promise," Lao Er said.
> >>> >>Pearl S. Buck - Dragon Seed
> >>> >>
> >>> > --
> >>> > ___
> >>> > yocto mailing list
> >>> > yocto@yoctoproject.org
> >>> > https://lists.yoctoproject.org/listinfo/yocto
> >
> > --
> > ___
> > yocto mailing list
> > yocto@yoctoproject.org
> > https://lists.yoctoproject.org/listinfo/yocto
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] bitbake SRC_URI fetch Azure DevOps repository Azure DevOps Services Basic

[江騏先]

Hi Richard,

I try use 
SRC_URI = 
"git://quant...@vs-ssh.visualstudio.com/v3/quanta01/OpenBMC/crashdump;protocol=ssh;nobranch=1"

the bitbake response below error message:
 git -c core.fsyncobjectfiles=0 ls-remote 
ssh://quant...@vs-ssh.visualstudio.com:v3/quanta01/OpenBMC/crashdump
  failed with exit code 128, output:

ssh: Could not resolve hostname vs-ssh.visualstudio.com:v3: Name or 
 service not known
fatal: Could not read from remote repository.

I discussed with Microsoft support team,
the Azure DevOps support SSH url clone without [ ssh:// ] prefix, like below:
git -c core.fsyncobjectfiles=0 ls-remote 
quant...@vs-ssh.visualstudio.com:v3/quanta01/OpenBMC/crashdump

Does bitbake support git SRC_URI without any prefix or need extra with Azure 
SSH protocol support it?

Thanks,
Samuel Jiang


-Original Message-
From: Richard Purdie  
Sent: Tuesday, November 5, 2019 11:30 PM
To: Samuel Jiang (江騏先) ; yocto@yoctoproject.org
Cc: Alex Chong 
Subject: Re: [yocto] bitbake SRC_URI fetch Azure DevOps repository Azure DevOps 
Services Basic

On Mon, 2019-11-04 at 02:52 +, Samuel Jiang (江騏先) wrote:
> Dear yocto developer,
> The below disscussed about azure devops clone issue including test 
> result with Microsoft support team member.
> We wonder know how Bitbake access repository through SSH. Does it 
> different between git and Azue DevOps?


Try:

SRC_URI = 
"git://quant...@vs-ssh.visualstudio.com/v3/quanta01/OpenBMC/crashdump;protocol=ssh;nobranch=1"

as I think you didn't convert the url to our syntax correctly.

Cheers,

Richard


> Thanks,
> 
> Samuel Jiang
> -- Forwarded message --
> From: Alex Chong (Shanghai Wicresoft Co,.Ltd.) < 
> v-chu...@microsoft.com>
> Date: 2019年10月31日 PM5:39 [+0800]
> To: Samuel Jiang (江騏先) 
> Cc: support , Alex Chong (Shanghai 
> Wicresoft Co,.Ltd.) 
> Subject: RE: 119102923000220 use yocto bitbake SRC_URI fetch Azure 
> DevOps repository Azure DevOps Services Basic
> 
> > Hi Samuel,
> > 
> >  
> > 
> > Thank you for reply.
> > 
> >  
> > 
> > I test and read the BitBake doc, let me share with you my finding 
> > and analysis.
> > 
> > I have verified that our Azure DevOps Organization Repo could be 
> > clone through SSH authentication successfully.
> > I create a new SSH key and add it to Azure DevOps SSH public keys.
> >  
> > 
> > Then I use git clone command and clone this repo successfully. The 
> > url is “v-chucho-micros...@vs-ssh.visualstudio.com:v3/v-chucho-
> > microsoft/testCodeCoverage/testCodeCoverage”
> > 
> > 
> > My testing verify that SSH Authentication is available, and the url 
> > given by Azure DevOps is correct.
> > 
> >  
> > 
> > Then I also test it in GitHub, and succeed. The only difference is 
> > the url of GitHub is “g...@github.com:xx.git”
> >  
> > 
> > So let’s come back to BitBake. I read more of the BitBake doc.( 
> > https://www.yoctoproject.org/docs/1.8/bitbake-user-manual/bitbake-us
> > er-manual.html#bb-fetchers
> > ) . Your command SRC_URI = "git://quanta01@vs- 
> > ssh.visualstudio.com:v3/quanta01/OpenBMC/crashdump;protocol=ssh;nob
> > ranch=1". The BitBake example is below.
> > 
> > 
> > We can see that the BitBake syntax is like git SSH but not Azure 
> > DevOps SSH. Do you try to use this command clone a repo from GitHub?
> > 
> >  
> > 
> > Then I read the doc you shared. The customer also met your issue 
> > when trying to clone Azure DevOps repo with SSH url. In my 
> > understanding, seems BitBake Git fetcher is good for Git SSH but not 
> > ready to access the Azure DevOps SSH.
> > 
> > 
> >  
> > 
> > Action Plan
> > 
> > Could you involve BitBake support team? We can deliver this testing 
> > result and consult them how BitBake access Azure DevOps through SSH.
> > 
> >  
> > 
> > If you have any conern or query, please feel free to let me know.
> > 
> >  
> > 
> > Best Regards,
> > 
> >  
> > 
> > Alex Chong
> > 
> >  
> > 
> > 
> > 
> > Support Engineer
> > 
> > Microsoft APAC Developer Support Team
> > 
> > Customer Service & Support (CSS)
> > 
> > Email: v-chu...@microsoft.com
> > 
> > Office: +86 (21) 52638610
> > 
> > Time zone: (UTC+08:00) Beijing, Chongqing, Hong Kong, Urumqi
> > 
> > Working time: 9:00am-6:00pm, Mon-Tue-Wed-Thu-Fri
> > 
> >  
> > 
> > From: Samuel Jiang (江騏先) 
> > Sent: Thursday, October 31, 2019 12:16 PM
> > To: Alex Chong (Shanghai Wicresoft Co,.Ltd.) < 
> > v-chu...@microsoft.com>
> > Cc: support 
> > Subject: RE: 119102923000220 use yocto bitbake SRC_URI fetch Azure 
> > DevOps repository Azure DevOps Services Basic
> > 
> >  
> > 
> > Hi Alex,
> > 
> > I catch same problem on the yocto mail list
> > link: 
> > https://lists.yoctoproject.org/pipermail/yocto/2018-October/042736.h
> > tml
> > 
> > when I use SRC_URI = "git://quanta01@vs- 
> > ssh.visualstudio.com:v3/quanta01/OpenBMC/crashdump;protocol=ssh;nob
> > ranch=1"
> > 
> > the bitbake response below error message:
> > git -c core.fsyncobjectfiles=0 ls-remote 
> > ssh://quant...@vs-ssh.visualstudio.