date:20190311

Re: [OE-core] [PATCH 07/12] xev: update to 1.2.3

2019-03-11 Thread Mittal, Anuj

Looks like this is failing with musl:

https://errors.yoctoproject.org/Errors/Details/232435/

On Sun, 2019-03-10 at 11:07 -0700, Armin Kuster wrote:
> refactor diet-x11 patch
> 
> LIC_FILES_CHKSUM changed to do merging of copyright/license notices
> https://gitlab.freedesktop.org/xorg/app/mkfontscale/commit/8609ad731b9c9c670a815c915055ae416d2396d8
> 
> Signed-off-by: Armin Kuster 
> ---
>  meta/recipes-graphics/xorg-app/xev/diet-x11.patch  | 79
> --
>  .../xorg-app/{xev_1.2.2.bb => xev_1.2.3.bb}|  4 +-
>  2 files changed, 46 insertions(+), 37 deletions(-)
>  rename meta/recipes-graphics/xorg-app/{xev_1.2.2.bb => xev_1.2.3.bb}
> (77%)
> 
> diff --git a/meta/recipes-graphics/xorg-app/xev/diet-x11.patch
> b/meta/recipes-graphics/xorg-app/xev/diet-x11.patch
> index 6130959..b4415e3 100644
> --- a/meta/recipes-graphics/xorg-app/xev/diet-x11.patch
> +++ b/meta/recipes-graphics/xorg-app/xev/diet-x11.patch
> @@ -4,79 +4,88 @@ Upstream-Status: Inappropriate [disable feature]
>   xev.c |   16 
>   1 file changed, 8 insertions(+), 8 deletions(-)
>  
> -Index: xev-1.2.0/xev.c
> +Index: xev-1.2.3/xev.c
>  ===
>  xev-1.2.0.orig/xev.c
> -+++ xev-1.2.0/xev.c
> -@@ -116,7 +116,7 @@ do_KeyPress (XEvent *eventp)
> - nbytes = XLookupString (e, str, 256, &ks, NULL);
> +--- xev-1.2.3.orig/xev.c
>  xev-1.2.3/xev.c
> +@@ -125,7 +125,7 @@ do_KeyPress(XEvent *eventp)
> + nbytes = XLookupString(e, str, 256, &ks, NULL);
>   
>   /* not supposed to call XmbLookupString on a key release event
> */
>  -if (e->type == KeyPress && xic) {
>  +/*if (e->type == KeyPress && xic) {
>   do {
> - nmbbytes = XmbLookupString (xic, e, buf, bsize - 1,
> &ks, &status);
> + nmbbytes = XmbLookupString(xic, e, buf, bsize - 1, &ks,
> &status);
>   buf[nmbbytes] = '\0';
> -@@ -126,7 +126,7 @@ do_KeyPress (XEvent *eventp)
> - buf = realloc (buf, bsize);
> +@@ -135,7 +135,7 @@ do_KeyPress(XEvent *eventp)
> + buf = realloc(buf, bsize);
>   }
>   } while (status == XBufferOverflow);
>  -}
>  +}*/
>   
>   if (ks == NoSymbol)
> - ksname = "NoSymbol";
> -@@ -156,7 +156,7 @@ do_KeyPress (XEvent *eventp)
> + ksname = "NoSymbol";
> +@@ -168,7 +168,7 @@ do_KeyPress(XEvent *eventp)
>   }
>   
>   /* not supposed to call XmbLookupString on a key release event
> */
>  -if (e->type == KeyPress && xic) {
> -+/*if (e->type == KeyPress && xic) {
> - printf ("XmbLookupString gives %d bytes: ", nmbbytes);
> ++/* if (e->type == KeyPress && xic) {
> + printf("XmbLookupString gives %d bytes: ", nmbbytes);
>   if (nmbbytes > 0) {
> -dump (buf, nmbbytes);
> -@@ -164,7 +164,7 @@ do_KeyPress (XEvent *eventp)
> - } else {
> -printf ("\n");
> + dump(buf, nmbbytes);
> +@@ -177,7 +177,7 @@ do_KeyPress(XEvent *eventp)
> + else {
> + printf("\n");
>   }
>  -}
>  +} */
>   
> - printf ("XFilterEvent returns: %s\n",
> - XFilterEvent (eventp, e->window) ? "True" : "False");
> -@@ -1015,7 +1015,7 @@ main (int argc, char **argv)
> - fprintf (stderr, "%s:  XSetLocaleModifiers failed\n",
> ProgramName);
> + printf("XFilterEvent returns: %s\n",
> +XFilterEvent(eventp, e->window) ? "True" : "False");
> +@@ -1141,7 +1141,7 @@ parse_event_mask(const char *s, long eve
> + if (s)
> + return True;
> + }
> +-}
> ++}*/
> + 
> + if (s != NULL)
> + fprintf(stderr, "%s: unrecognized event mask '%s'\n",
> ProgramName, s);
> +@@ -1288,7 +1288,7 @@ main(int argc, char **argv)
> + fprintf(stderr, "%s:  XSetLocaleModifiers failed\n",
> ProgramName);
>   }
>   
> --xim = XOpenIM (dpy, NULL, NULL, NULL);
> -+/*xim = XOpenIM (dpy, NULL, NULL, NULL);
> +-xim = XOpenIM(dpy, NULL, NULL, NULL);
> ++/*xim = XOpenIM(dpy, NULL, NULL, NULL);
>   if (xim == NULL) {
> - fprintf (stderr, "%s:  XOpenIM failed\n", ProgramName);
> + fprintf(stderr, "%s:  XOpenIM failed\n", ProgramName);
>   }
> -@@ -1042,7 +1042,7 @@ main (int argc, char **argv)
> +@@ -1317,7 +1317,7 @@ main(int argc, char **argv)
>   }
> - XFree (xim_styles);
> + XFree(xim_styles);
>   }
>  -}
> -+}*/
> ++}*/
>   
> - screen = DefaultScreen (dpy);
> + screen = DefaultScreen(dpy);
>   
> -@@ -1109,7 +1109,7 @@ main (int argc, char **argv)
> - printf ("Outer window is 0x%lx, inner window is 0x%lx\n", w,
> subw);
> +@@ -1373,7 +1373,7 @@ main(int argc, char **argv)
> + printf("Outer window is 0x%lx, inner window is 0x%lx\n", w,
> subw);
>   }
>   
>  -if (xim && xim_style) {
>  +/*if (xim && xim_style) {
> - xic = XCreateIC (xim,
> -

Re: [OE-core] [PATCH] scripts/resulttool: Enhance retrieving test cases value

2019-03-11 Thread Mohamad, Mazliana

Apologize, please ignore this email

-Original Message-
From: Mohamad, Mazliana 
Sent: Monday, March 11, 2019 4:31 PM
To: openembedded-core@lists.openembedded.org
Cc: Mohamad, Mazliana ; Yeoh, Ee Peng 

Subject: [PATCH] scripts/resulttool: Enhance retrieving test cases value

From: Mazliana 

We found that manualexecution does not capture test suite values correctly if 
there are more than one test suite in test cases.
After verification has made we found out we should retrieved full test cases 
value  from oeqa/manual/ json file rather 
than split it them into new variables test_suite and test_cases.

Signed-off-by: Mazliana 
---
 scripts/lib/resulttool/manualexecution.py | 15 ++-
 1 file changed, 6 insertions(+), 9 deletions(-)

diff --git a/scripts/lib/resulttool/manualexecution.py 
b/scripts/lib/resulttool/manualexecution.py
index a44cc86..6487cd9 100755
--- a/scripts/lib/resulttool/manualexecution.py
+++ b/scripts/lib/resulttool/manualexecution.py
@@ -29,8 +29,7 @@ class ManualTestRunner(object):
 def __init__(self):
 self.jdata = ''
 self.test_module = ''
-self.test_suite = ''
-self.test_cases = ''
+self.test_cases_id = ''
 self.configuration = ''
 self.starttime = ''
 self.result_id = ''
@@ -38,11 +37,10 @@ class ManualTestRunner(object):
 
 def _get_testcases(self, file):
 self.jdata = load_json_file(file)
-self.test_cases = []
+self.test_cases_id = []
 self.test_module = self.jdata[0]['test']['@alias'].split('.', 2)[0]
-self.test_suite = self.jdata[0]['test']['@alias'].split('.', 2)[1]
 for i in self.jdata:
-self.test_cases.append(i['test']['@alias'].split('.', 2)[2])
+self.test_cases_id.append(i['test']['@alias'])
 
 def _get_input(self, config):
 while True:
@@ -81,10 +79,9 @@ class ManualTestRunner(object):
 
 def _execute_test_steps(self, test_id):
 test_result = {}
-testcase_id = self.test_module + '.' + self.test_suite + '.' + 
self.test_cases[test_id]
 total_steps = len(self.jdata[test_id]['test']['execution'].keys())
 
print('')
-print('Executing test case:' + '' '' + self.test_cases[test_id])
+print('Executing test case:' + '' '' + 
+ self.test_cases_id[test_id])
 
print('')
 print('You have total ' + str(total_steps) + ' test steps to be 
executed.')
 
print('\n')
@@ -105,9 +102,9 @@ class ManualTestRunner(object):
 res = result_types[r]
 if res == 'FAILED':
 log_input = input('\nPlease enter the error and 
the description of the log: (Ex:log:211 Error Bitbake)\n')
-test_result.update({testcase_id: {'status': '%s' % 
res, 'log': '%s' % log_input}})
+
+ test_result.update({self.test_cases_id[test_id]: {'status': '%s' % 
+ res, 'log': '%s' % log_input}})
 else:
-test_result.update({testcase_id: {'status': '%s' % 
res}})
+
+ test_result.update({self.test_cases_id[test_id]: {'status': '%s' % 
+ res}})
 break
 print('Invalid input!')
 return test_result
--
2.7.4

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] resulttool/manualexecution: To output right test case id

2019-03-11 Thread mazliana . mohamad

From: Mazliana 

We found that manualexecution does not capture test suite values
correctly if there are more than one test suite in test cases.
After verification has made we found out we should retrieved
full test cases value  from
oeqa/manual/ json file rather than split it them into new
variables test_suite and test_cases.

Signed-off-by: Mazliana 
---
 scripts/lib/resulttool/manualexecution.py | 15 ++-
 1 file changed, 6 insertions(+), 9 deletions(-)

diff --git a/scripts/lib/resulttool/manualexecution.py 
b/scripts/lib/resulttool/manualexecution.py
index a44cc86..6487cd9 100755
--- a/scripts/lib/resulttool/manualexecution.py
+++ b/scripts/lib/resulttool/manualexecution.py
@@ -29,8 +29,7 @@ class ManualTestRunner(object):
 def __init__(self):
 self.jdata = ''
 self.test_module = ''
-self.test_suite = ''
-self.test_cases = ''
+self.test_cases_id = ''
 self.configuration = ''
 self.starttime = ''
 self.result_id = ''
@@ -38,11 +37,10 @@ class ManualTestRunner(object):
 
 def _get_testcases(self, file):
 self.jdata = load_json_file(file)
-self.test_cases = []
+self.test_cases_id = []
 self.test_module = self.jdata[0]['test']['@alias'].split('.', 2)[0]
-self.test_suite = self.jdata[0]['test']['@alias'].split('.', 2)[1]
 for i in self.jdata:
-self.test_cases.append(i['test']['@alias'].split('.', 2)[2])
+self.test_cases_id.append(i['test']['@alias'])
 
 def _get_input(self, config):
 while True:
@@ -81,10 +79,9 @@ class ManualTestRunner(object):
 
 def _execute_test_steps(self, test_id):
 test_result = {}
-testcase_id = self.test_module + '.' + self.test_suite + '.' + 
self.test_cases[test_id]
 total_steps = len(self.jdata[test_id]['test']['execution'].keys())
 
print('')
-print('Executing test case:' + '' '' + self.test_cases[test_id])
+print('Executing test case:' + '' '' + self.test_cases_id[test_id])
 
print('')
 print('You have total ' + str(total_steps) + ' test steps to be 
executed.')
 
print('\n')
@@ -105,9 +102,9 @@ class ManualTestRunner(object):
 res = result_types[r]
 if res == 'FAILED':
 log_input = input('\nPlease enter the error and 
the description of the log: (Ex:log:211 Error Bitbake)\n')
-test_result.update({testcase_id: {'status': '%s' % 
res, 'log': '%s' % log_input}})
+test_result.update({self.test_cases_id[test_id]: 
{'status': '%s' % res, 'log': '%s' % log_input}})
 else:
-test_result.update({testcase_id: {'status': '%s' % 
res}})
+test_result.update({self.test_cases_id[test_id]: 
{'status': '%s' % res}})
 break
 print('Invalid input!')
 return test_result
-- 
2.7.4

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] scripts/resulttool: Enhance retrieving test cases value

2019-03-11 Thread mazliana . mohamad

From: Mazliana 

We found that manualexecution does not capture test suite values
correctly if there are more than one test suite in test cases.
After verification has made we found out we should retrieved
full test cases value  from
oeqa/manual/ json file rather than split it them into new
variables test_suite and test_cases.

Signed-off-by: Mazliana 
---
 scripts/lib/resulttool/manualexecution.py | 15 ++-
 1 file changed, 6 insertions(+), 9 deletions(-)

diff --git a/scripts/lib/resulttool/manualexecution.py 
b/scripts/lib/resulttool/manualexecution.py
index a44cc86..6487cd9 100755
--- a/scripts/lib/resulttool/manualexecution.py
+++ b/scripts/lib/resulttool/manualexecution.py
@@ -29,8 +29,7 @@ class ManualTestRunner(object):
 def __init__(self):
 self.jdata = ''
 self.test_module = ''
-self.test_suite = ''
-self.test_cases = ''
+self.test_cases_id = ''
 self.configuration = ''
 self.starttime = ''
 self.result_id = ''
@@ -38,11 +37,10 @@ class ManualTestRunner(object):
 
 def _get_testcases(self, file):
 self.jdata = load_json_file(file)
-self.test_cases = []
+self.test_cases_id = []
 self.test_module = self.jdata[0]['test']['@alias'].split('.', 2)[0]
-self.test_suite = self.jdata[0]['test']['@alias'].split('.', 2)[1]
 for i in self.jdata:
-self.test_cases.append(i['test']['@alias'].split('.', 2)[2])
+self.test_cases_id.append(i['test']['@alias'])
 
 def _get_input(self, config):
 while True:
@@ -81,10 +79,9 @@ class ManualTestRunner(object):
 
 def _execute_test_steps(self, test_id):
 test_result = {}
-testcase_id = self.test_module + '.' + self.test_suite + '.' + 
self.test_cases[test_id]
 total_steps = len(self.jdata[test_id]['test']['execution'].keys())
 
print('')
-print('Executing test case:' + '' '' + self.test_cases[test_id])
+print('Executing test case:' + '' '' + self.test_cases_id[test_id])
 
print('')
 print('You have total ' + str(total_steps) + ' test steps to be 
executed.')
 
print('\n')
@@ -105,9 +102,9 @@ class ManualTestRunner(object):
 res = result_types[r]
 if res == 'FAILED':
 log_input = input('\nPlease enter the error and 
the description of the log: (Ex:log:211 Error Bitbake)\n')
-test_result.update({testcase_id: {'status': '%s' % 
res, 'log': '%s' % log_input}})
+test_result.update({self.test_cases_id[test_id]: 
{'status': '%s' % res, 'log': '%s' % log_input}})
 else:
-test_result.update({testcase_id: {'status': '%s' % 
res}})
+test_result.update({self.test_cases_id[test_id]: 
{'status': '%s' % res}})
 break
 print('Invalid input!')
 return test_result
-- 
2.7.4

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH 0/1] oe-init-build-env: Error out when failed to locate cwd

2019-03-11 Thread Robert Yang

The following changes since commit 28e631d6dbc0a126253c0a072b8f39ff683bfa3a:

  python: time.tzset missing (2019-03-09 14:41:20 +)

are available in the git repository at:

  git://git.openembedded.org/openembedded-core-contrib rbt/init
  http://cgit.openembedded.org/openembedded-core-contrib/log/?h=rbt/init

Robert Yang (1):
  oe-init-build-env: Error out when failed to locate cwd

 oe-init-build-env | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

-- 
2.7.4

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH 1/1] oe-init-build-env: Error out when failed to locate cwd

2019-03-11 Thread Robert Yang

Ubuntu's /bin/sh symlinks to /bin/dash by default, so
subprocess.check_call(oe-init-build-env, cwd=builddir) would be failed since
pwd is builddir, and there is no $builddir/oe-init-build-env, this would
lead to other confusing errors, check and error it out earlier to make it
easier to locate the problem.

We don't meet the problem when manually run ". oe-init-build-env" is because
Ubuntu's default login shell is bash, but subprocess.check_call() doesn't
respect to login shell, so the error only happens in situations like
subprocess.check_call().

And also print errors to stderr as oe-buildenv-internal does.

Signed-off-by: Robert Yang 
---
 oe-init-build-env | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/oe-init-build-env b/oe-init-build-env
index e813230..861c3e0 100755
--- a/oe-init-build-env
+++ b/oe-init-build-env
@@ -31,13 +31,18 @@ elif [ -n "$ZSH_NAME" ]; then
 THIS_SCRIPT=$0
 else
 THIS_SCRIPT="$(pwd)/oe-init-build-env"
+if [ ! -e "$THIS_SCRIPT" ]; then
+echo "Error: $THIS_SCRIPT doesn't exist!" >&2
+echo "Please run this script in oe-init-build-env's directory." >&2
+exit 1
+fi
 fi
 if [ -n "$BBSERVER" ]; then
 unset BBSERVER
 fi
 
 if [ -z "$ZSH_NAME" ] && [ "$0" = "$THIS_SCRIPT" ]; then
-echo "Error: This script needs to be sourced. Please run as '. 
$THIS_SCRIPT'"
+echo "Error: This script needs to be sourced. Please run as '. 
$THIS_SCRIPT'" >&2
 exit 1
 fi
 
-- 
2.7.4

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] correct do_patch for kernel bbappend in sdk

2019-03-11 Thread Yann CARDAILLAC

do_patch rule of SDK's workspace/appends/linux-*.bbhappend may fail if script 
are not written in Python

that was the case with Phytec's BSP, the fix was to replace the do_patch rule 
with :

do_patch[noexec]="1" when the file was generated in 
scripts/lib/devtool/standard.py

Signed-off-by: Yann CARDAILLAC 
---
 scripts/lib/devtool/standard.py | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/scripts/lib/devtool/standard.py b/scripts/lib/devtool/standard.py
index beea0d4..810d12f 100644
--- a/scripts/lib/devtool/standard.py
+++ b/scripts/lib/devtool/standard.py
@@ -761,9 +761,7 @@ def modify(args, config, basepath, workspace):
 if bb.data.inherits_class('kernel', rd):
 f.write('SRCTREECOVEREDTASKS = "do_validate_branches 
do_kernel_checkout '
 'do_fetch do_unpack do_kernel_configme 
do_kernel_configcheck"\n')
-f.write('\ndo_patch() {\n'
-':\n'
-'}\n')
+f.write('\ndo_patch[noexec] = "1"\n')
 f.write('\ndo_configure_append() {\n'
 'cp ${B}/.config ${S}/.config.baseline\n'
 'ln -sfT ${B}/.config ${S}/.config.new\n'
-- 
2.7.4

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 4/5] linux-yocto: Fix systemtap issue on armv7

2019-03-11 Thread richard . purdie

On Sun, 2019-03-10 at 21:27 -0700, Khem Raj wrote:
> On Sun, Mar 10, 2019 at 8:13 PM Richard Purdie
>  wrote:
> > Testing stap on armv7 machines was failing due to intermixing of
> > thumb/arm
> > instructions. Patch the kernel to always use the v7 march options
> > since
> > we know our gcc versions support it to avoid the failure and allow
> > systemtap to work.
> > 
> > [YOCTO #13153]
> > 
> 
> please use the fix that Victor submitted upstream, that way we dont
> need workaround.
> http://lists.infradead.org/pipermail/linux-arm-kernel/2019-March/637809.html

I have a feeling that patch may get some discussion upstream. I was
going to say that the version we're working with is simpler and easier
to work with until upstream decide what the right approach is. Victor
as already pointed out that even then I messed it up slightly!

I certainly appreciate getting something upstream and that is the right
thing to do, I think a simpler workaround for us is fine until that
gets sorted out though.

I'm particularly conscious that we've not built M3 yet and that Bruce
has limited availability due to travel so we have a few constraints
here.

Cheers,

Richard

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] systemd: do not disable SELinux with musl

2019-03-11 Thread luca . boccassi

From: Luca Boccassi 

Building and running SELinux with musl works fine these days,
so don't disable it in the systemd bitbake file.

Signed-off-by: Luca Boccassi 
---
 meta/recipes-core/systemd/systemd_241.bb | 1 -
 1 file changed, 1 deletion(-)

diff --git a/meta/recipes-core/systemd/systemd_241.bb 
b/meta/recipes-core/systemd/systemd_241.bb
index 47492c9512..e4534ab8af 100644
--- a/meta/recipes-core/systemd/systemd_241.bb
+++ b/meta/recipes-core/systemd/systemd_241.bb
@@ -101,7 +101,6 @@ PACKAGECONFIG_remove_libc-musl = " \
 nss-mymachines \
 nss-resolve \
 resolved \
-selinux \
 smack \
 sysusers \
 utmp \
-- 
2.20.1

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 4/5] linux-yocto: Fix systemtap issue on armv7

2019-03-11 Thread Bruce Ashfield

On Mon, Mar 11, 2019 at 8:13 AM  wrote:
>
> On Sun, 2019-03-10 at 21:27 -0700, Khem Raj wrote:
> > On Sun, Mar 10, 2019 at 8:13 PM Richard Purdie
> >  wrote:
> > > Testing stap on armv7 machines was failing due to intermixing of
> > > thumb/arm
> > > instructions. Patch the kernel to always use the v7 march options
> > > since
> > > we know our gcc versions support it to avoid the failure and allow
> > > systemtap to work.
> > >
> > > [YOCTO #13153]
> > >
> >
> > please use the fix that Victor submitted upstream, that way we dont
> > need workaround.
> > http://lists.infradead.org/pipermail/linux-arm-kernel/2019-March/637809.html
>
> I have a feeling that patch may get some discussion upstream. I was
> going to say that the version we're working with is simpler and easier
> to work with until upstream decide what the right approach is. Victor
> as already pointed out that even then I messed it up slightly!
>
> I certainly appreciate getting something upstream and that is the right
> thing to do, I think a simpler workaround for us is fine until that
> gets sorted out though.
>
> I'm particularly conscious that we've not built M3 yet and that Bruce
> has limited availability due to travel so we have a few constraints
> here.

I'm of the same mind. Until the upstream patch is actually queued,
we can easily just stick with the current patch.  That way I can log
the permanent upstream git hash in a revert and update ..  which
is no different than I'd do if I merged the posted patch and then it
eventually merges (or if it needs changes, etc).

So as long as what we merged doesn't break anything, there's no
need to change anything (it isn't a mystery that there's an
upstream fix, even I noticed it last night when scanning my upstream
lists and I'm on vacation :D.

Cheers,

Bruce

>
> Cheers,
>
> Richard
>
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core



-- 
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] Can't build product that uses DEFAULTTUNE="arm926ejs"

2019-03-11 Thread Peter Kjellerstedt

> -Original Message-
> From: Khem Raj 
> Sent: den 11 mars 2019 05:24
> To: Peter Kjellerstedt 
> Cc: OE Core (openembedded-core@lists.openembedded.org)  c...@lists.openembedded.org>
> Subject: Re: Can't build product that uses DEFAULTTUNE="arm926ejs"
> 
> On Sun, Mar 10, 2019 at 9:20 PM Peter Kjellerstedt
>  wrote:
> >
> > I'm trying to build with master of OE-core and one of our products
> > now fails with:
> >
> > ERROR:  OE-core's config sanity checker detected a potential 
> > misconfiguration.
> > Either fix the cause of this error or at your own risk disable the 
> > checker
> > (see sanity.conf). Following is the list of potential problems / 
> > advisories:
> >
> > Error, the PACKAGE_ARCHS variable (all any noarch arm armv4 armv4t armv5
> > armv5t armv5e armv5te arm926ejste arm926ejse ) for
> > DEFAULTTUNE (arm926ejs) does not contain TUNE_PKGARCH (arm926ejst).
> >
> > I believe this is due to commit ac83d22e (arm-tunes: Remove -march
> > option if mcpu is already added). If I build with Thud, TUNE_PKGARCH 
> > is "arm926ejste". The  lack of the "e" at the end when building with 
> > master seems to be due to the definition of ARMPKGSFX_DSP as
> > "${@bb.utils.contains('TUNE_FEATURES', [ 'armv5', 'dsp' ], 'e', '', d)}" 
> > and the fact that after commit ac83d22e, TUNE_FEATURES no longer 
> > contains 'armv5'.
> 
> right this should now check for armv5t

There is no armv5t to check for.

> armv5 has been removed from upstream gcc as well. So we only support
> armv5t variants.
> 
> > //Peter

I am by no means any expert on the tuning files (actually they mostly 
seem like black magic), but I devised an alternative solution for 
preferring -mcpu over -march that I think is less invasive and without 
unwanted side effects. I will publish it shortly.

//Peter

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH 2/2] arm-tunes: Prefer the -mcpu option over -march

2019-03-11 Thread Peter Kjellerstedt

Tune files that inherit the arch definitions already define
appropriate -mcpu options, which are equivalent of the correct -march
and -mtune combinations. This is preferred since gcc is getting
stricter and stricter with option check semantics and can now find
incompatible -march and -mcpu options better with every release. It
does an internal feature consistency check and if it finds any
discrepancies between what -mcpu would expand to as compared to
-march, it will flag the options to be incompatible. For the naked eye
it looks wrong, but gcc will translate -mcpu to a given -march
internally and it might not match what we set in these arch files.

The effects are quite subtle, where this can result in configure tests
failing to compile due to these incompatible options and a feature
option getting disabled for a recipe for no reason.

E.g., with GCC 9, which can now detect that -mcpu=cortex-a5 and
-march=armv7-a are incompatible, many features in libstdc++ end up
disabled due to configure check failures, e.g., size_t size, ptrdiff_t
sizes, which in turn results in compiling libstdc++ with wanted
features disabled.

This is an alternative solution to the same problem originally
implemented by Khem Raj in commit ac83d22e, but this time only
affecting -mcpu and -march options without other side effects.

Signed-off-by: Peter Kjellerstedt 
---
 meta/conf/machine/include/arm/arch-arm.inc   | 5 +
 meta/conf/machine/include/arm/arch-armv4.inc | 2 +-
 meta/conf/machine/include/arm/arch-armv5.inc | 2 +-
 meta/conf/machine/include/arm/arch-armv6.inc | 2 +-
 meta/conf/machine/include/arm/arch-armv7a.inc| 2 +-
 meta/conf/machine/include/arm/arch-armv7ve.inc   | 2 +-
 meta/conf/machine/include/arm/arch-armv8a.inc| 2 +-
 meta/conf/machine/include/tune-arm1136jf-s.inc   | 2 +-
 meta/conf/machine/include/tune-arm920t.inc   | 2 +-
 meta/conf/machine/include/tune-arm926ejs.inc | 2 +-
 meta/conf/machine/include/tune-arm9tdmi.inc  | 2 +-
 meta/conf/machine/include/tune-cortexa15.inc | 2 +-
 meta/conf/machine/include/tune-cortexa17.inc | 2 +-
 meta/conf/machine/include/tune-cortexa32.inc | 2 +-
 meta/conf/machine/include/tune-cortexa35.inc | 2 +-
 meta/conf/machine/include/tune-cortexa5.inc  | 2 +-
 meta/conf/machine/include/tune-cortexa53.inc | 2 +-
 meta/conf/machine/include/tune-cortexa7.inc  | 2 +-
 meta/conf/machine/include/tune-cortexa72.inc | 2 +-
 meta/conf/machine/include/tune-cortexa8.inc  | 2 +-
 meta/conf/machine/include/tune-cortexa9.inc  | 2 +-
 meta/conf/machine/include/tune-ep9312.inc| 2 +-
 meta/conf/machine/include/tune-iwmmxt.inc| 2 +-
 meta/conf/machine/include/tune-strongarm1100.inc | 2 +-
 meta/conf/machine/include/tune-thunderx.inc  | 2 +-
 meta/conf/machine/include/tune-xscale.inc| 2 +-
 26 files changed, 30 insertions(+), 25 deletions(-)

diff --git a/meta/conf/machine/include/arm/arch-arm.inc 
b/meta/conf/machine/include/arm/arch-arm.inc
index 99625d8417..1482c3ad03 100644
--- a/meta/conf/machine/include/arm/arch-arm.inc
+++ b/meta/conf/machine/include/arm/arch-arm.inc
@@ -11,6 +11,11 @@ ARMPKGSFX_THUMB ??= ""
 TUNE_ARCH = "${@bb.utils.contains('TUNE_FEATURES', 'bigendian', 'armeb', 
'arm', d)}"
 TUNE_PKGARCH = 
"${ARMPKGARCH}${ARMPKGSFX_THUMB}${ARMPKGSFX_DSP}${ARMPKGSFX_EABI}${ARMPKGSFX_ENDIAN}${ARMPKGSFX_FPU}"
 
+# Prefer -mcpu= over -arch=
+TUNE_MCPU ??= ""
+TUNE_MARCH ??= ""
+TUNE_CCARGS .= "${@d.getVar('TUNE_MCPU') or d.getVar('TUNE_MARCH')}"
+
 ABIEXTENSION = "eabi"
 
 TARGET_FPU = "${@d.getVar('TUNE_CCARGS_MFLOAT') or 'soft'}"
diff --git a/meta/conf/machine/include/arm/arch-armv4.inc 
b/meta/conf/machine/include/arm/arch-armv4.inc
index 47a7ad2830..4188ba0637 100644
--- a/meta/conf/machine/include/arm/arch-armv4.inc
+++ b/meta/conf/machine/include/arm/arch-armv4.inc
@@ -2,7 +2,7 @@ DEFAULTTUNE ?= "armv4"
 
 TUNEVALID[arm] = "Enable ARM instruction set"
 TUNEVALID[armv4] = "Enable instructions for ARMv4"
-TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'armv4', ' 
-march=armv4t', '', d)}"
+TUNE_MARCH .= "${@bb.utils.contains('TUNE_FEATURES', 'armv4', ' 
-march=armv4t', '', d)}"
 # enable --fix-v4bx when we have armv4 in TUNE_FEATURES, but then disable it 
when we have also armv5 or thumb
 # maybe we should extend bb.utils.contains to support check for any 
checkvalues in value, now it does 
 # checkvalues.issubset(val) which cannot be used for negative test of foo 
neither bar in value
diff --git a/meta/conf/machine/include/arm/arch-armv5.inc 
b/meta/conf/machine/include/arm/arch-armv5.inc
index f9068af9de..ae8df32919 100644
--- a/meta/conf/machine/include/arm/arch-armv5.inc
+++ b/meta/conf/machine/include/arm/arch-armv5.inc
@@ -2,7 +2,7 @@ DEFAULTTUNE ?= "armv5"
 
 TUNEVALID[armv5] = "Enable instructions for ARMv5"
 TUNECONFLICTS[armv5] = "armv4"
-TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'armv5', ' 
-march=armv5t${ARMPKGSFX_DSP}', '', d)}"
+TUNE_MARCH .= "${@bb.utils.

[OE-core] [PATCH 1/2] Revert "arm-tunes: Remove -march option if mcpu is already added"

2019-03-11 Thread Peter Kjellerstedt

This reverts commit ac83d22eb5031f7fdd09d34a1a46d92fd3e39a3c.

This solution had unforeseen side effects, which, e.g., lead to the
following sanity error if trying to build with the arm926ejs default
tune:

Error, the PACKAGE_ARCHS variable (all any noarch arm armv4 armv4t
armv5 armv5t armv5e armv5te arm926ejste arm926ejse ) for DEFAULTTUNE (arm926ejs) does not contain
TUNE_PKGARCH (arm926ejst).

An alternative solution will follow, which only affects the -mcpu and
-march options without other side effects.

Signed-off-by: Peter Kjellerstedt 
---
 meta/conf/machine/include/tune-arm1136jf-s.inc   |  4 +---
 meta/conf/machine/include/tune-arm920t.inc   |  4 +---
 meta/conf/machine/include/tune-arm926ejs.inc |  4 +---
 meta/conf/machine/include/tune-arm9tdmi.inc  |  4 +---
 meta/conf/machine/include/tune-cortexa15.inc | 27 ++-
 meta/conf/machine/include/tune-cortexa17.inc | 27 ++-
 meta/conf/machine/include/tune-cortexa5.inc  | 27 ++-
 meta/conf/machine/include/tune-cortexa7.inc  | 27 ++-
 meta/conf/machine/include/tune-cortexa8.inc  | 19 +++-
 meta/conf/machine/include/tune-cortexa9.inc  | 28 ++--
 meta/conf/machine/include/tune-ep9312.inc|  1 -
 meta/conf/machine/include/tune-iwmmxt.inc|  3 +--
 meta/conf/machine/include/tune-strongarm1100.inc |  3 +--
 meta/conf/machine/include/tune-xscale.inc|  7 ++
 14 files changed, 76 insertions(+), 109 deletions(-)

diff --git a/meta/conf/machine/include/tune-arm1136jf-s.inc 
b/meta/conf/machine/include/tune-arm1136jf-s.inc
index d883eba7c9..c5de63e1cc 100644
--- a/meta/conf/machine/include/tune-arm1136jf-s.inc
+++ b/meta/conf/machine/include/tune-arm1136jf-s.inc
@@ -4,10 +4,8 @@ require conf/machine/include/arm/arch-armv6.inc
 
 TUNEVALID[arm1136jfs] = "Enable arm1136jfs specific processor optimizations"
 TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'arm1136jfs', ' 
-mcpu=arm1136jf-s', '', d)}"
-MACHINEOVERRIDES =. "${@bb.utils.contains('TUNE_FEATURES', 'arm1136jfs', 
'armv6:', '' ,d)}"
 
 AVAILTUNES += "arm1136jfs"
 ARMPKGARCH_tune-arm1136jfs = "arm1136jfs"
-# mcpu is used so don't use armv6 as we don't want march
-TUNE_FEATURES_tune-arm1136jfs = "arm arm1136jfs"
+TUNE_FEATURES_tune-arm1136jfs = "${TUNE_FEATURES_tune-armv6} arm1136jfs"
 PACKAGE_EXTRA_ARCHS_tune-arm1136jfs = "${PACKAGE_EXTRA_ARCHS_tune-armv6} 
arm1136jfs-vfp"
diff --git a/meta/conf/machine/include/tune-arm920t.inc 
b/meta/conf/machine/include/tune-arm920t.inc
index 42e8ed2b51..c6e74b6772 100644
--- a/meta/conf/machine/include/tune-arm920t.inc
+++ b/meta/conf/machine/include/tune-arm920t.inc
@@ -4,10 +4,8 @@ require conf/machine/include/arm/arch-armv4.inc
 
 TUNEVALID[arm920t] = "Enable arm920t specific processor optimizations"
 TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'arm920t', ' 
-mcpu=arm920t', '', d)}"
-MACHINEOVERRIDES =. "${@bb.utils.contains('TUNE_FEATURES', 'arm920t', 
'armv4:', '' ,d)}"
 
 AVAILTUNES += "arm920t"
 ARMPKGARCH_tune-arm920t = "arm920t"
-# mcpu is used so don't use armv4t as we don't want march
-TUNE_FEATURES_tune-arm920t = "arm thumb arm920t"
+TUNE_FEATURES_tune-arm920t = "${TUNE_FEATURES_tune-armv4t} arm920t"
 PACKAGE_EXTRA_ARCHS_tune-arm920t = "${PACKAGE_EXTRA_ARCHS_tune-armv4t} arm920t 
arm920tt"
diff --git a/meta/conf/machine/include/tune-arm926ejs.inc 
b/meta/conf/machine/include/tune-arm926ejs.inc
index 563d53bc4e..81bcda339b 100644
--- a/meta/conf/machine/include/tune-arm926ejs.inc
+++ b/meta/conf/machine/include/tune-arm926ejs.inc
@@ -4,10 +4,8 @@ require conf/machine/include/arm/arch-armv5-dsp.inc
 
 TUNEVALID[arm926ejs] = "Enable arm926ejs specific processor optimizations"
 TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'arm926ejs', ' 
-mcpu=arm926ej-s', '', d)}"
-MACHINEOVERRIDES =. "${@bb.utils.contains('TUNE_FEATURES', 'arm926ejs', 
'armv5:', '' ,d)}"
 
 AVAILTUNES += "arm926ejs"
 ARMPKGARCH_tune-arm926ejs = "arm926ejs"
-# mcpu is used so don't use armv5te as we don't want march
-TUNE_FEATURES_tune-arm926ejs = "arm thumb dsp arm926ejs"
+TUNE_FEATURES_tune-arm926ejs = "${TUNE_FEATURES_tune-armv5te} arm926ejs"
 PACKAGE_EXTRA_ARCHS_tune-arm926ejs = "${PACKAGE_EXTRA_ARCHS_tune-armv5te} 
arm926ejste arm926ejse"
diff --git a/meta/conf/machine/include/tune-arm9tdmi.inc 
b/meta/conf/machine/include/tune-arm9tdmi.inc
index e03a8b86a0..e9c2b8fcf5 100644
--- a/meta/conf/machine/include/tune-arm9tdmi.inc
+++ b/meta/conf/machine/include/tune-arm9tdmi.inc
@@ -4,10 +4,8 @@ require conf/machine/include/arm/arch-armv4.inc
 
 TUNEVALID[arm9tdmi] = "Enable arm9tdmi specific processor optimizations"
 TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'arm9tdmi', ' 
-mcpu=arm9tdmi', '', d)}"
-MACHINEOVERRIDES =. "${@bb.utils.contains('TUNE_FEATURES', 'arm9tdmi', 
'armv4:', '' ,d)}"
 
 AVAILTUNES += "arm9tdmi"
 ARMPKGARCH_tune-arm9tdmi = "arm9tdmi"
-# mcpu is used so don

Re: [OE-core] [PATCH 07/12] xev: update to 1.2.3

2019-03-11 Thread akuster808




On 3/11/19 1:04 AM, Mittal, Anuj wrote:
> Looks like this is failing with musl:
Of course, anything will fall over with a little musl applied against it ; )

>
> https://errors.yoctoproject.org/Errors/Details/232435/

thanks,
armin
>
> On Sun, 2019-03-10 at 11:07 -0700, Armin Kuster wrote:
>> refactor diet-x11 patch
>>
>> LIC_FILES_CHKSUM changed to do merging of copyright/license notices
>> https://gitlab.freedesktop.org/xorg/app/mkfontscale/commit/8609ad731b9c9c670a815c915055ae416d2396d8
>>
>> Signed-off-by: Armin Kuster 
>> ---
>>  meta/recipes-graphics/xorg-app/xev/diet-x11.patch  | 79
>> --
>>  .../xorg-app/{xev_1.2.2.bb => xev_1.2.3.bb}|  4 +-
>>  2 files changed, 46 insertions(+), 37 deletions(-)
>>  rename meta/recipes-graphics/xorg-app/{xev_1.2.2.bb => xev_1.2.3.bb}
>> (77%)
>>
>> diff --git a/meta/recipes-graphics/xorg-app/xev/diet-x11.patch
>> b/meta/recipes-graphics/xorg-app/xev/diet-x11.patch
>> index 6130959..b4415e3 100644
>> --- a/meta/recipes-graphics/xorg-app/xev/diet-x11.patch
>> +++ b/meta/recipes-graphics/xorg-app/xev/diet-x11.patch
>> @@ -4,79 +4,88 @@ Upstream-Status: Inappropriate [disable feature]
>>   xev.c |   16 
>>   1 file changed, 8 insertions(+), 8 deletions(-)
>>  
>> -Index: xev-1.2.0/xev.c
>> +Index: xev-1.2.3/xev.c
>>  ===
>>  xev-1.2.0.orig/xev.c
>> -+++ xev-1.2.0/xev.c
>> -@@ -116,7 +116,7 @@ do_KeyPress (XEvent *eventp)
>> - nbytes = XLookupString (e, str, 256, &ks, NULL);
>> +--- xev-1.2.3.orig/xev.c
>>  xev-1.2.3/xev.c
>> +@@ -125,7 +125,7 @@ do_KeyPress(XEvent *eventp)
>> + nbytes = XLookupString(e, str, 256, &ks, NULL);
>>   
>>   /* not supposed to call XmbLookupString on a key release event
>> */
>>  -if (e->type == KeyPress && xic) {
>>  +/*if (e->type == KeyPress && xic) {
>>   do {
>> - nmbbytes = XmbLookupString (xic, e, buf, bsize - 1,
>> &ks, &status);
>> + nmbbytes = XmbLookupString(xic, e, buf, bsize - 1, &ks,
>> &status);
>>   buf[nmbbytes] = '\0';
>> -@@ -126,7 +126,7 @@ do_KeyPress (XEvent *eventp)
>> - buf = realloc (buf, bsize);
>> +@@ -135,7 +135,7 @@ do_KeyPress(XEvent *eventp)
>> + buf = realloc(buf, bsize);
>>   }
>>   } while (status == XBufferOverflow);
>>  -}
>>  +}*/
>>   
>>   if (ks == NoSymbol)
>> -ksname = "NoSymbol";
>> -@@ -156,7 +156,7 @@ do_KeyPress (XEvent *eventp)
>> + ksname = "NoSymbol";
>> +@@ -168,7 +168,7 @@ do_KeyPress(XEvent *eventp)
>>   }
>>   
>>   /* not supposed to call XmbLookupString on a key release event
>> */
>>  -if (e->type == KeyPress && xic) {
>> -+/*if (e->type == KeyPress && xic) {
>> - printf ("XmbLookupString gives %d bytes: ", nmbbytes);
>> ++/* if (e->type == KeyPress && xic) {
>> + printf("XmbLookupString gives %d bytes: ", nmbbytes);
>>   if (nmbbytes > 0) {
>> -dump (buf, nmbbytes);
>> -@@ -164,7 +164,7 @@ do_KeyPress (XEvent *eventp)
>> - } else {
>> -   printf ("\n");
>> + dump(buf, nmbbytes);
>> +@@ -177,7 +177,7 @@ do_KeyPress(XEvent *eventp)
>> + else {
>> + printf("\n");
>>   }
>>  -}
>>  +} */
>>   
>> - printf ("XFilterEvent returns: %s\n",
>> -XFilterEvent (eventp, e->window) ? "True" : "False");
>> -@@ -1015,7 +1015,7 @@ main (int argc, char **argv)
>> - fprintf (stderr, "%s:  XSetLocaleModifiers failed\n",
>> ProgramName);
>> + printf("XFilterEvent returns: %s\n",
>> +XFilterEvent(eventp, e->window) ? "True" : "False");
>> +@@ -1141,7 +1141,7 @@ parse_event_mask(const char *s, long eve
>> + if (s)
>> + return True;
>> + }
>> +-}
>> ++   }*/
>> + 
>> + if (s != NULL)
>> + fprintf(stderr, "%s: unrecognized event mask '%s'\n",
>> ProgramName, s);
>> +@@ -1288,7 +1288,7 @@ main(int argc, char **argv)
>> + fprintf(stderr, "%s:  XSetLocaleModifiers failed\n",
>> ProgramName);
>>   }
>>   
>> --xim = XOpenIM (dpy, NULL, NULL, NULL);
>> -+/*xim = XOpenIM (dpy, NULL, NULL, NULL);
>> +-xim = XOpenIM(dpy, NULL, NULL, NULL);
>> ++/*xim = XOpenIM(dpy, NULL, NULL, NULL);
>>   if (xim == NULL) {
>> - fprintf (stderr, "%s:  XOpenIM failed\n", ProgramName);
>> + fprintf(stderr, "%s:  XOpenIM failed\n", ProgramName);
>>   }
>> -@@ -1042,7 +1042,7 @@ main (int argc, char **argv)
>> +@@ -1317,7 +1317,7 @@ main(int argc, char **argv)
>>   }
>> - XFree (xim_styles);
>> + XFree(xim_styles);
>>   }
>>  -}
>> -+   }*/
>> ++}*/
>>   
>> - screen = DefaultScreen (dpy);
>> + screen = DefaultScreen(dpy);
>>   
>> -@@ -1109,7 +1109,7 @@ main (int argc, char **argv)
>> -printf ("Outer window is 0x%lx, inner window is 0x%lx\n", w,

Re: [OE-core] [sumo][PATCH] busybox: backport fix for issues introduced by CVE-2011-5325.patch

2019-03-11 Thread Tom Rini

On Sun, Mar 10, 2019 at 08:12:01PM +, Martin Jansa wrote:

> Signed-off-by: Martin Jansa 

This also reverts some really odd functionality that can cause projects
to break (I hit this myself and intended to find time to do a
move-busybox-forward patch to sumo) so yes, please!

Reviewed-by: Tom Rini 

-- 
Tom
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 1/5] qemuarm: Swap for an arm7ve (A15) configuration

2019-03-11 Thread Tom Rini

On Mon, Mar 11, 2019 at 03:12:26AM +, Richard Purdie wrote:

> From: Jon Mason 
> 
> Add new QEMU BSP for a Arm Cortex-A15 system and use this as qemuarm,
> moving the old armv5te Versatile PB based machine to qemuarmv5.
> 
> The new machine uses the QEMU virt machine type, which should be
> faster to emulate and updates the qemuarm support to a modern
> architecture.
> 
> Signed-off-by: Jon Mason 
> Signed-off-by: Richard Purdie 

Should we also not set UBOOT_MACHINE here to qemu_arm_defconfig for the
new machine?  We dropped versatilepb support back in 2015 however.
Thanks!

-- 
Tom


signature.asc
Description: PGP signature
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 1/5] qemuarm: Swap for an arm7ve (A15) configuration

2019-03-11 Thread Richard Purdie

On Mon, 2019-03-11 at 11:09 -0400, Tom Rini wrote:
> On Mon, Mar 11, 2019 at 03:12:26AM +, Richard Purdie wrote:
> 
> > From: Jon Mason 
> > 
> > Add new QEMU BSP for a Arm Cortex-A15 system and use this as
> > qemuarm,
> > moving the old armv5te Versatile PB based machine to qemuarmv5.
> > 
> > The new machine uses the QEMU virt machine type, which should be
> > faster to emulate and updates the qemuarm support to a modern
> > architecture.
> > 
> > Signed-off-by: Jon Mason 
> > Signed-off-by: Richard Purdie 
> 
> Should we also not set UBOOT_MACHINE here to qemu_arm_defconfig for
> the new machine?  We dropped versatilepb support back in 2015
> however.
> Thanks!

For which machine, the new qemuarm or the qemuarmv5? I'm guessing you
mean the latter?

We perhaps could/should but it isn't set now so I'd suggest it be done
in a separate patch.

I would like to see u-boot being used in more builds but if we don't
actually test/use the binary, its not so useful and that would mean
further changes?

Cheers,

Richard


-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 1/5] qemuarm: Swap for an arm7ve (A15) configuration

2019-03-11 Thread Tom Rini

On Mon, Mar 11, 2019 at 08:13:21AM -0700, Richard Purdie wrote:
> On Mon, 2019-03-11 at 11:09 -0400, Tom Rini wrote:
> > On Mon, Mar 11, 2019 at 03:12:26AM +, Richard Purdie wrote:
> > 
> > > From: Jon Mason 
> > > 
> > > Add new QEMU BSP for a Arm Cortex-A15 system and use this as
> > > qemuarm,
> > > moving the old armv5te Versatile PB based machine to qemuarmv5.
> > > 
> > > The new machine uses the QEMU virt machine type, which should be
> > > faster to emulate and updates the qemuarm support to a modern
> > > architecture.
> > > 
> > > Signed-off-by: Jon Mason 
> > > Signed-off-by: Richard Purdie 
> > 
> > Should we also not set UBOOT_MACHINE here to qemu_arm_defconfig for
> > the new machine?  We dropped versatilepb support back in 2015
> > however.
> > Thanks!
> 
> For which machine, the new qemuarm or the qemuarmv5? I'm guessing you
> mean the latter?

For the new v7 machine that uses the virt machine upstream.

> We perhaps could/should but it isn't set now so I'd suggest it be done
> in a separate patch.

I see we aren't doing it for qemuarm64 either which is also supported in
U-Boot under qemu_arm64_defconfig, so yes, I'll do a follow-up to enable
in both of these.  And to qemumips* too.

> I would like to see u-boot being used in more builds but if we don't
> actually test/use the binary, its not so useful and that would mean
> further changes?

So, humm.  As a serious question, how do we test wic images / ovmf
today?  On the U-Boot side of things, we test all of our qemu images
frequently with our functional tests.  What we don't have atm is "boot
linux to login prompt" or similar.

-- 
Tom


signature.asc
Description: PGP signature
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] cmake: Reduce verbosity for make invocation

2019-03-11 Thread Khem Raj

On Sun, Mar 10, 2019 at 10:53 PM Douglas Royds
 wrote:
>
> Since the dawn of time, we have set CMAKE_VERBOSE_MAKEFILE=1 in cmake.bbclass.
> Back in 2016, we also explicitly set VERBOSE=1 in cmake_do_compile(),
> to ensure that make (and ninja) output were verbose in log.do_compile.
>
> Turning off CMAKE_VERBOSE_MAKEFILE=1 means that make (or ninja)
> invocations from the command-line are non-verbose,
> giving CMake's default human-readable output on the terminal instead.
> The user can still invoke VERBOSE=1 make if they do want verbose output.
> This has no effect on the verbose output that goes into the logs.
>

I think it would be better to have knob to turn is on and off both on
console and log files.

> Signed-off-by: Douglas Royds 
> ---
>  meta/classes/cmake.bbclass | 1 -
>  1 file changed, 1 deletion(-)
>
> diff --git a/meta/classes/cmake.bbclass b/meta/classes/cmake.bbclass
> index fa7f68c99b..e16630434e 100644
> --- a/meta/classes/cmake.bbclass
> +++ b/meta/classes/cmake.bbclass
> @@ -164,7 +164,6 @@ cmake_do_configure() {
>   
> -DCMAKE_INSTALL_DATAROOTDIR:PATH=${@os.path.relpath(d.getVar('datadir'), 
> d.getVar('prefix'))} \
>   -DCMAKE_INSTALL_SO_NO_EXE=0 \
>   -DCMAKE_TOOLCHAIN_FILE=${WORKDIR}/toolchain.cmake \
> - -DCMAKE_VERBOSE_MAKEFILE=1 \
>   -DCMAKE_NO_SYSTEM_FROM_IMPORTED=1 \
>   ${EXTRA_OECMAKE} \
>   -Wno-dev
> --
> 2.17.1
>
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] gst-examples: switch to gitlab url and https protocol

2019-03-11 Thread Tim Orling

Signed-off-by: Tim Orling 
---
 meta/recipes-multimedia/gstreamer/gst-examples_git.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-multimedia/gstreamer/gst-examples_git.bb 
b/meta/recipes-multimedia/gstreamer/gst-examples_git.bb
index f8cef857b3..75ac9b75c1 100644
--- a/meta/recipes-multimedia/gstreamer/gst-examples_git.bb
+++ b/meta/recipes-multimedia/gstreamer/gst-examples_git.bb
@@ -4,7 +4,7 @@ LIC_FILES_CHKSUM = 
"file://playback/player/gtk/gtk-play.c;beginline=1;endline=20
 
 DEPENDS = "glib-2.0 gstreamer1.0 gstreamer1.0-plugins-base 
gstreamer1.0-plugins-bad gtk+3 glib-2.0-native"
 
-SRC_URI = "git://anongit.freedesktop.org/gstreamer/gst-examples \
+SRC_URI = 
"git://gitlab.freedesktop.org/gstreamer/gst-examples.git;protocol=https \
file://0001-Make-player-examples-installable.patch \
file://gst-player.desktop"
 
-- 
2.20.1

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] Yocto Project Unassigned Bugs - Help Needed

2019-03-11 Thread sjolley.yp.pm

All,

 

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

 

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

 

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

 

There are also roughly four different "priority" classes right now, "2.7",
"2.8", "2.99" and "Future", the more pressing/urgent issues being in "2.7"
and then "2.8".

 

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

 

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

 

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

*Cell:(208) 244-4460

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

 

 

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [V2][PATCH] xev: update to 1.2.3

2019-03-11 Thread Armin Kuster

refactor diet-x11 patch

LIC_FILES_CHKSUM changed to do merging of copyright/license notices

Signed-off-by: Armin Kuster 

V2] Fix musl build fix
---
 .../xorg-app/xev/diet-x11.patch   | 133 +++---
 .../xorg-app/{xev_1.2.2.bb => xev_1.2.3.bb}   |   4 +-
 2 files changed, 82 insertions(+), 55 deletions(-)
 rename meta/recipes-graphics/xorg-app/{xev_1.2.2.bb => xev_1.2.3.bb} (77%)

diff --git a/meta/recipes-graphics/xorg-app/xev/diet-x11.patch 
b/meta/recipes-graphics/xorg-app/xev/diet-x11.patch
index 6130959f86..53c0ac2e61 100644
--- a/meta/recipes-graphics/xorg-app/xev/diet-x11.patch
+++ b/meta/recipes-graphics/xorg-app/xev/diet-x11.patch
@@ -4,79 +4,106 @@ Upstream-Status: Inappropriate [disable feature]
  xev.c |   16 
  1 file changed, 8 insertions(+), 8 deletions(-)
 
-Index: xev-1.2.0/xev.c
+Index: xev-1.2.3/xev.c
 ===
 xev-1.2.0.orig/xev.c
-+++ xev-1.2.0/xev.c
-@@ -116,7 +116,7 @@ do_KeyPress (XEvent *eventp)
- nbytes = XLookupString (e, str, 256, &ks, NULL);
+--- xev-1.2.3.orig/xev.c
 xev-1.2.3/xev.c
+@@ -125,17 +125,6 @@ do_KeyPress(XEvent *eventp)
+ nbytes = XLookupString(e, str, 256, &ks, NULL);
  
  /* not supposed to call XmbLookupString on a key release event */
 -if (e->type == KeyPress && xic) {
-+/*if (e->type == KeyPress && xic) {
- do {
- nmbbytes = XmbLookupString (xic, e, buf, bsize - 1, &ks, &status);
- buf[nmbbytes] = '\0';
-@@ -126,7 +126,7 @@ do_KeyPress (XEvent *eventp)
- buf = realloc (buf, bsize);
- }
- } while (status == XBufferOverflow);
+-do {
+-nmbbytes = XmbLookupString(xic, e, buf, bsize - 1, &ks, &status);
+-buf[nmbbytes] = '\0';
+-
+-if (status == XBufferOverflow) {
+-bsize = nmbbytes + 1;
+-buf = realloc(buf, bsize);
+-}
+-} while (status == XBufferOverflow);
 -}
-+}*/
  
  if (ks == NoSymbol)
-   ksname = "NoSymbol";
-@@ -156,7 +156,7 @@ do_KeyPress (XEvent *eventp)
+ ksname = "NoSymbol";
+@@ -168,16 +157,6 @@ do_KeyPress(XEvent *eventp)
  }
  
  /* not supposed to call XmbLookupString on a key release event */
 -if (e->type == KeyPress && xic) {
-+/*if (e->type == KeyPress && xic) {
- printf ("XmbLookupString gives %d bytes: ", nmbbytes);
- if (nmbbytes > 0) {
-dump (buf, nmbbytes);
-@@ -164,7 +164,7 @@ do_KeyPress (XEvent *eventp)
- } else {
-  printf ("\n");
+-printf("XmbLookupString gives %d bytes: ", nmbbytes);
+-if (nmbbytes > 0) {
+-dump(buf, nmbbytes);
+-printf(" \"%s\"\n", buf);
+-}
+-else {
+-printf("\n");
+-}
+-}
+ 
+ printf("XFilterEvent returns: %s\n",
+XFilterEvent(eventp, e->window) ? "True" : "False");
+@@ -1141,7 +1120,7 @@ parse_event_mask(const char *s, long eve
+ if (s)
+ return True;
  }
 -}
-+} */
++  }
  
- printf ("XFilterEvent returns: %s\n",
-   XFilterEvent (eventp, e->window) ? "True" : "False");
-@@ -1015,7 +1015,7 @@ main (int argc, char **argv)
- fprintf (stderr, "%s:  XSetLocaleModifiers failed\n", ProgramName);
+ if (s != NULL)
+ fprintf(stderr, "%s: unrecognized event mask '%s'\n", ProgramName, s);
+@@ -1288,37 +1267,6 @@ main(int argc, char **argv)
+ fprintf(stderr, "%s:  XSetLocaleModifiers failed\n", ProgramName);
  }
  
--xim = XOpenIM (dpy, NULL, NULL, NULL);
-+/*xim = XOpenIM (dpy, NULL, NULL, NULL);
- if (xim == NULL) {
- fprintf (stderr, "%s:  XOpenIM failed\n", ProgramName);
- }
-@@ -1042,7 +1042,7 @@ main (int argc, char **argv)
- }
- XFree (xim_styles);
- }
+-xim = XOpenIM(dpy, NULL, NULL, NULL);
+-if (xim == NULL) {
+-fprintf(stderr, "%s:  XOpenIM failed\n", ProgramName);
 -}
-+  }*/
- 
- screen = DefaultScreen (dpy);
+-
+-if (xim) {
+-imvalret = XGetIMValues(xim, XNQueryInputStyle, &xim_styles, NULL);
+-if (imvalret != NULL || xim_styles == NULL) {
+-fprintf(stderr, "%s:  input method doesn't support any styles\n",
+-ProgramName);
+-}
+-
+-if (xim_styles) {
+-xim_style = 0;
+-for (i = 0; i < xim_styles->count_styles; i++) {
+-if (xim_styles->supported_styles[i] ==
+-(XIMPreeditNothing | XIMStatusNothing)) {
+-xim_style = xim_styles->supported_styles[i];
+-break;
+-}
+-}
+-
+-if (xim_style == 0) {
+-fprintf(stderr,
+-"%s: input method doesn't support the style we 
support\n",
+-ProgramName);
+-

Re: [OE-core] [PATCH] cmake: Reduce verbosity for make invocation

2019-03-11 Thread Douglas Royds


On 12/03/19 6:18 AM, Khem Raj wrote:


On Sun, Mar 10, 2019 at 10:53 PM Douglas Royds
 wrote:

Since the dawn of time, we have set CMAKE_VERBOSE_MAKEFILE=1 in cmake.bbclass.
Back in 2016, we also explicitly set VERBOSE=1 in cmake_do_compile(),
to ensure that make (and ninja) output were verbose in log.do_compile.

Turning off CMAKE_VERBOSE_MAKEFILE=1 means that make (or ninja)
invocations from the command-line are non-verbose,
giving CMake's default human-readable output on the terminal instead.
The user can still invoke VERBOSE=1 make if they do want verbose output.
This has no effect on the verbose output that goes into the logs.


I think it would be better to have knob to turn is on and off both on
console and log files.



If you want it on for some reason, you can turn it on in your local.conf:

   EXTRA_OECMAKE_append=" -DCMAKE_VERBOSE_MAKEFILE=1"

Alternatively, you can turn verbosity on for a single invocation (this 
is what I do when I need it):


   make VERBOSE=1

You can also set an environment variable to make it always verbose, if 
you want that for some reason:


   VERBOSE=1 make

Do we really need a new variable for this?

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] virglrenderer: requires distro feature opengl

2019-03-11 Thread kai.kang

From: Kai Kang 

virglrenderer depends on 2 packages:
* mesa: requires one of distro features opengl or vulkan
* libepoxy: requires distro feature opengl

So make virglrenderer requires distro feature opengl. Otherwise it fails
to build world if 'opengl' doesn't exist in DISTRO_FEATURES.

Signed-off-by: Kai Kang 
---
 meta/recipes-graphics/virglrenderer/virglrenderer_0.7.0.bb | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/meta/recipes-graphics/virglrenderer/virglrenderer_0.7.0.bb 
b/meta/recipes-graphics/virglrenderer/virglrenderer_0.7.0.bb
index 500ed4f2d8..225a0b8b0c 100644
--- a/meta/recipes-graphics/virglrenderer/virglrenderer_0.7.0.bb
+++ b/meta/recipes-graphics/virglrenderer/virglrenderer_0.7.0.bb
@@ -13,7 +13,10 @@ SRC_URI = "git://anongit.freedesktop.org/virglrenderer \
 
 S = "${WORKDIR}/git"
 
-inherit autotools pkgconfig
+inherit autotools pkgconfig distro_features_check
 
 BBCLASSEXTEND = "native nativesdk"
 
+REQUIRED_DISTRO_FEATURES = "opengl"
+REQUIRED_DISTRO_FEATURES_class-native = ""
+REQUIRED_DISTRO_FEATURES_class-nativesdk = ""
-- 
2.20.0

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] linux-yocto/5.0: fix system tap for arm

2019-03-11 Thread Mittal, Anuj

On Sun, 2019-03-10 at 23:45 -0400, bruce.ashfi...@gmail.com wrote:
> -SRCREV_machine_qemuarm ?= "1fbecad0e6a68b6c57b4f6ef8207e7e90ea764a3"
> -SRCREV_machine_qemuarm64 ?=
> "1a0da7e50b77c82841efb501c648dbaca699eac2"
> -SRCREV_machine_qemumips ?=
> "d9dd6d4cfe689efd5cb7bbacd118a3888ac7c517"
> -SRCREV_machine_qemuppc ?= "1a0da7e50b77c82841efb501c648dbaca699eac2"
> -SRCREV_machine_qemux86 ?= "1a0da7e50b77c82841efb501c648dbaca699eac2"
> -SRCREV_machine_qemux86-64 ?=
> "1a0da7e50b77c82841efb501c648dbaca699eac2"
> -SRCREV_machine_qemumips64 ?=
> "5f072445126e6a9e44f9435a552f4fcf6fc15499"
> -SRCREV_machine ?= "1a0da7e50b77c82841efb501c648dbaca699eac2"
> -SRCREV_meta ?= "4faa4419884d2bbe65f637befd71a1e95629eaae"
> +SRCREV_machine_qemuarm ?= "23b538073fdc803b0a749de77677508671e246af"
> +SRCREV_machine_qemuarm64 ?=
> "37c8f2a3df1e3154087538a27228fad0c6e172c5"
> +SRCREV_machine_qemumips ?=
> "50b5b709ac6b1d14ac815f9a002c50a196306b02"
> +SRCREV_machine_qemuppc ?= "37c8f2a3df1e3154087538a27228fad0c6e172c5"
> +SRCREV_machine_qemux86 ?= "37c8f2a3df1e3154087538a27228fad0c6e172c5"
> +SRCREV_machine_qemux86-64 ?=
> "37c8f2a3df1e3154087538a27228fad0c6e172c5"
> +SRCREV_machine_qemumips64 ?=
> "8322515ba7a858c47386b95c6e7201c8a3a41175"
> +SRCREV_machine ?= "37c8f2a3df1e3154087538a27228fad0c6e172c5"
> +SRCREV_meta ?= "8fbd119bd954443b1cae496d7797c458faa02495"

Looks like these commits weren't actually pushed.

I still see 1a0da7e50 as the latest on v5.0/standard/base and this is
resulting in failures for master-next on autobuilder ...

Thanks,
Anuj
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] linux-yocto/5.0: fix system tap for arm

2019-03-11 Thread Bruce Ashfield

On Mon, Mar 11, 2019 at 9:41 PM Mittal, Anuj  wrote:
>
> On Sun, 2019-03-10 at 23:45 -0400, bruce.ashfi...@gmail.com wrote:
> > -SRCREV_machine_qemuarm ?= "1fbecad0e6a68b6c57b4f6ef8207e7e90ea764a3"
> > -SRCREV_machine_qemuarm64 ?=
> > "1a0da7e50b77c82841efb501c648dbaca699eac2"
> > -SRCREV_machine_qemumips ?=
> > "d9dd6d4cfe689efd5cb7bbacd118a3888ac7c517"
> > -SRCREV_machine_qemuppc ?= "1a0da7e50b77c82841efb501c648dbaca699eac2"
> > -SRCREV_machine_qemux86 ?= "1a0da7e50b77c82841efb501c648dbaca699eac2"
> > -SRCREV_machine_qemux86-64 ?=
> > "1a0da7e50b77c82841efb501c648dbaca699eac2"
> > -SRCREV_machine_qemumips64 ?=
> > "5f072445126e6a9e44f9435a552f4fcf6fc15499"
> > -SRCREV_machine ?= "1a0da7e50b77c82841efb501c648dbaca699eac2"
> > -SRCREV_meta ?= "4faa4419884d2bbe65f637befd71a1e95629eaae"
> > +SRCREV_machine_qemuarm ?= "23b538073fdc803b0a749de77677508671e246af"
> > +SRCREV_machine_qemuarm64 ?=
> > "37c8f2a3df1e3154087538a27228fad0c6e172c5"
> > +SRCREV_machine_qemumips ?=
> > "50b5b709ac6b1d14ac815f9a002c50a196306b02"
> > +SRCREV_machine_qemuppc ?= "37c8f2a3df1e3154087538a27228fad0c6e172c5"
> > +SRCREV_machine_qemux86 ?= "37c8f2a3df1e3154087538a27228fad0c6e172c5"
> > +SRCREV_machine_qemux86-64 ?=
> > "37c8f2a3df1e3154087538a27228fad0c6e172c5"
> > +SRCREV_machine_qemumips64 ?=
> > "8322515ba7a858c47386b95c6e7201c8a3a41175"
> > +SRCREV_machine ?= "37c8f2a3df1e3154087538a27228fad0c6e172c5"
> > +SRCREV_meta ?= "8fbd119bd954443b1cae496d7797c458faa02495"
>
> Looks like these commits weren't actually pushed.
>
> I still see 1a0da7e50 as the latest on v5.0/standard/base and this is
> resulting in failures for master-next on autobuilder ...

I just double checked my builder and they were pushed, at least the machine
branches. I did just explicitly push standard/base, hopefully the build issues
are cleared up now.

Bruce

>
> Thanks,
> Anuj



-- 
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] createrepo-c: fix for do_package_qa

2019-03-11 Thread Zheng Ruoqin

Fix the following QA Issue:

ERROR: nativesdk-createrepo-c-0.12.1-r0 do_package_qa: QA Issue: 
nativesdk-createrepo-c rdepends on nativesdk-python3-dev [dev-deps]
ERROR: nativesdk-createrepo-c-0.12.1-r0 do_package_qa: QA run found fatal 
errors. Please consider fixing them.

Signed-off-by: Zheng Ruoqin 
---
 meta/recipes-devtools/createrepo-c/createrepo-c_git.bb | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/meta/recipes-devtools/createrepo-c/createrepo-c_git.bb 
b/meta/recipes-devtools/createrepo-c/createrepo-c_git.bb
index 9aa8d2a..e11a783 100644
--- a/meta/recipes-devtools/createrepo-c/createrepo-c_git.bb
+++ b/meta/recipes-devtools/createrepo-c/createrepo-c_git.bb
@@ -33,3 +33,5 @@ do_install_append_class-nativesdk() {
 RPM_CONFIGDIR=${SDKPATHNATIVE}${libdir_nativesdk}/rpm
 rm -rf ${D}/etc
 }
+
+INSANE_SKIP_${PN} += "dev-deps"
-- 
2.7.4



-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] cmake: Reduce verbosity for make invocation

2019-03-11 Thread Khem Raj

On Mon, Mar 11, 2019 at 5:47 PM Douglas Royds
 wrote:
>
> On 12/03/19 6:18 AM, Khem Raj wrote:
>
> On Sun, Mar 10, 2019 at 10:53 PM Douglas Royds
>  wrote:
>
> Since the dawn of time, we have set CMAKE_VERBOSE_MAKEFILE=1 in cmake.bbclass.
> Back in 2016, we also explicitly set VERBOSE=1 in cmake_do_compile(),
> to ensure that make (and ninja) output were verbose in log.do_compile.
>
> Turning off CMAKE_VERBOSE_MAKEFILE=1 means that make (or ninja)
> invocations from the command-line are non-verbose,
> giving CMake's default human-readable output on the terminal instead.
> The user can still invoke VERBOSE=1 make if they do want verbose output.
> This has no effect on the verbose output that goes into the logs.
>
> I think it would be better to have knob to turn is on and off both on
> console and log files.
>
>
> If you want it on for some reason, you can turn it on in your local.conf:
>
> EXTRA_OECMAKE_append=" -DCMAKE_VERBOSE_MAKEFILE=1"
>
> Alternatively, you can turn verbosity on for a single invocation (this is 
> what I do when I need it):
>
> make VERBOSE=1
>
> You can also set an environment variable to make it always verbose, if you 
> want that for some reason:
>
> VERBOSE=1 make
>
> Do we really need a new variable for this?

its fine if we can ensure consistent behaviour, I dont like the fact that
cmdline output would be different than whats stored in log files.
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] cmake: Reduce verbosity for make invocation

2019-03-11 Thread Douglas Royds


On 12/03/19 5:09 PM, Khem Raj wrote:


On Mon, Mar 11, 2019 at 5:47 PM Douglas Royds
 wrote:

On 12/03/19 6:18 AM, Khem Raj wrote:

On Sun, Mar 10, 2019 at 10:53 PM Douglas Royds
 wrote:

Since the dawn of time, we have set CMAKE_VERBOSE_MAKEFILE=1 in cmake.bbclass.
Back in 2016, we also explicitly set VERBOSE=1 in cmake_do_compile(),
to ensure that make (and ninja) output were verbose in log.do_compile.

Turning off CMAKE_VERBOSE_MAKEFILE=1 means that make (or ninja)
invocations from the command-line are non-verbose,
giving CMake's default human-readable output on the terminal instead.
The user can still invoke VERBOSE=1 make if they do want verbose output.
This has no effect on the verbose output that goes into the logs.

I think it would be better to have knob to turn is on and off both on
console and log files.


If you want it on for some reason, you can turn it on in your local.conf:

EXTRA_OECMAKE_append=" -DCMAKE_VERBOSE_MAKEFILE=1"

Alternatively, you can turn verbosity on for a single invocation (this is what 
I do when I need it):

make VERBOSE=1

You can also set an environment variable to make it always verbose, if you want 
that for some reason:

VERBOSE=1 make

Do we really need a new variable for this?

its fine if we can ensure consistent behaviour, I dont like the fact that
cmdline output would be different than whats stored in log files.



OK, that's a fair point. I'll update it with a variable.

--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [OE-Core][PATCH v2 3/3] devtool: provide support for devtool menuconfig command.

2019-03-11 Thread Chandana Kalluri

-Original Message-
From: Paul Eggleton  
Sent: Monday, March 4, 2019 3:46 PM
To: Chandana Kalluri 
Cc: openembedded-core@lists.openembedded.org
Subject: Re: [OE-core] [OE-Core][PATCH v2 3/3] devtool: provide support for 
devtool menuconfig command.

On Saturday, 26 January 2019 8:53:02 AM NZDT Sai Hari Chandana Kalluri wrote:
> +def menuconfig(args, config, basepath, workspace):
> +"""Entry point for the devtool 'menuconfig' subcommand"""
> +
> +rd = "" 
> +kconfigpath = ""
> +pn_src = ""
> +localfilesdir = ""
> +workspace_dir = ""
> +tinfoil = setup_tinfoil(basepath=basepath)
> +try:
> +  rd = parse_recipe(config, tinfoil, args.component, appends=True, 
> filter_workspace=False)
> +  if not rd:
> + return 1
> +
> +  pn =  rd.getVar('PN', True)
> +  if pn not in workspace:
> + raise DevtoolError("Run devtool modify before calling menuconfig 
> for %s" %pn)

Strictly speaking we have check_workspace_recipe() for this. It could be that 
we should extend the message printed by that to be a bit more friendly and 
suggest devtool add/modify/upgrade first, but I'd like to be consistent.

>...
> +  #add check to see if oe_local_files exists or not
> +  localfilesdir = os.path.join(pn_src,'oe-local-files') 
> +  if not os.path.exists(localfilesdir):
> +  bb.utils.mkdirhier(localfilesdir)
> +  #Add gitignore to ensure source tree is clean
> +  gitignorefile = os.path.join(localfilesdir,'.gitignore')
> +  with open(gitignorefile, 'w') as f:
> +  f.write('# Ignore local files, by default. Remove this 
> file if you want to commit the directory to Git\n')
> +  f.write('*\n')

We should already be handling this in devtool-source.bbclass, but I'm guessing 
the hardlinking you're adding bypasses that, so we likely need to handle that 
separately during devtool modify rather than here (preferably without 
duplicating code).

This check for oe_local_files is specific for all other packages except 
linux-yocto. This is needed if the package uses make menuconfig to generate cfg 
and for devtool finish to pick up the cfg fragment. 
For linux-yocto, after the hardlinking is done, the check for oe-local-files is 
taken care for within devtool modify( this is in PATCH 1/3 ). 

The above check for oe-local-files for all packages could be handled within 
devtool modify and can be done in two ways:
1. Either all packages(even the ones that do not run menuconfig command) have 
an empty oe-local-files dir as a part of workspace/source OR
2. have a check within modify to see if it runs menuconfig task and create the 
oe-local-files. 

What would you recommend ?

> +parser_menuconfig = subparsers.add_parser('menuconfig',help='allows 
> altering the system component configuration', description='launches the make 
> menuconfig command, allows user to make changes to configuration. creates a 
> config fragment', group='advanced') 
> +parser_menuconfig.add_argument('component', help='compenent to alter 
> config')

To be consistent with other subcommands and a bit more readable this should be 
something like:

parser_menuconfig = subparsers.add_parser('menuconfig', help='Alter 
build-time configuration for a recipe', description='Launches the "make 
menuconfig" command (for recipes where do_menuconfig is available), allowing 
you to make changes to the build-time configuration. Creates a config fragment 
corresponding to changes made.', group='advanced') 
parser_menuconfig.add_argument('recipename', help='Recipe to reconfigure')

Additionally, I would really like to see some oe-selftest tests for this along 
with the changes.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH v2] cmake: Reduce verbosity for make invocation

2019-03-11 Thread Douglas Royds

New variable OECMAKE_VERBOSE_MAKEFILE defaults to True.

Since the dawn of time, we have set CMAKE_VERBOSE_MAKEFILE=1 (True) in 
cmake.bbclass.
Back in 2016, we also explicitly set VERBOSE=1 in cmake_do_compile(),
to ensure that make (and ninja) output were verbose in log.do_compile.

Setting OECMAKE_VERBOSE_MAKEFILE to False means that make (or ninja)
invocations from the command-line are non-verbose,
giving CMake's default human-readable output on the terminal instead.
The user can still invoke VERBOSE=1 make if they do want verbose output.
This has no effect on the verbose output that goes into the logs.
---
 meta/classes/cmake.bbclass | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/meta/classes/cmake.bbclass b/meta/classes/cmake.bbclass
index fa7f68c99b..0d44a74046 100644
--- a/meta/classes/cmake.bbclass
+++ b/meta/classes/cmake.bbclass
@@ -62,6 +62,7 @@ EXTRA_OECMAKE_BUILD_prepend_task-install = 
"${PARALLEL_MAKEINST} "
 
 OECMAKE_TARGET_COMPILE ?= "all"
 OECMAKE_TARGET_INSTALL ?= "install"
+OECMAKE_VERBOSE_MAKEFILE ?= "True"
 
 # CMake expects target architectures in the format of uname(2),
 # which do not always match TARGET_ARCH, so all the necessary
@@ -164,7 +165,7 @@ cmake_do_configure() {
  
-DCMAKE_INSTALL_DATAROOTDIR:PATH=${@os.path.relpath(d.getVar('datadir'), 
d.getVar('prefix'))} \
  -DCMAKE_INSTALL_SO_NO_EXE=0 \
  -DCMAKE_TOOLCHAIN_FILE=${WORKDIR}/toolchain.cmake \
- -DCMAKE_VERBOSE_MAKEFILE=1 \
+ -DCMAKE_VERBOSE_MAKEFILE=${OECMAKE_VERBOSE_MAKEFILE} \
  -DCMAKE_NO_SYSTEM_FROM_IMPORTED=1 \
  ${EXTRA_OECMAKE} \
  -Wno-dev
-- 
2.17.1

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] resulttool/report: Enable roll-up report for a commit

2019-03-11 Thread Yeoh Ee Peng

Enable roll-up all test results belong to a commit
and to provide a roll-up report.

Signed-off-by: Yeoh Ee Peng 
---
 scripts/lib/resulttool/report.py | 16 +---
 1 file changed, 13 insertions(+), 3 deletions(-)

diff --git a/scripts/lib/resulttool/report.py b/scripts/lib/resulttool/report.py
index ff1b32c..9008620 100644
--- a/scripts/lib/resulttool/report.py
+++ b/scripts/lib/resulttool/report.py
@@ -107,9 +107,17 @@ class ResultsTextReport(object):
  maxlen=maxlen)
 print(output)
 
-def view_test_report(self, logger, source_dir, tag):
+def view_test_report(self, logger, source_dir, branch, commit, tag):
 test_count_reports = []
-if tag:
+if commit:
+if tag:
+logger.warning("Ignoring --tag as --commit was specified")
+tag_name = "{branch}/{commit_number}-g{commit}/{tag_number}"
+repo = GitRepo(source_dir)
+revs = gitarchive.get_test_revs(logger, repo, tag_name, 
branch=branch)
+rev_index = gitarchive.rev_find(revs, 'commit', commit)
+testresults = resultutils.git_get_result(repo, revs[rev_index][2])
+elif tag:
 repo = GitRepo(source_dir)
 testresults = resultutils.git_get_result(repo, [tag])
 else:
@@ -125,7 +133,7 @@ class ResultsTextReport(object):
 
 def report(args, logger):
 report = ResultsTextReport()
-report.view_test_report(logger, args.source_dir, args.tag)
+report.view_test_report(logger, args.source_dir, args.branch, args.commit, 
args.tag)
 return 0
 
 def register_commands(subparsers):
@@ -136,5 +144,7 @@ def register_commands(subparsers):
 parser_build.set_defaults(func=report)
 parser_build.add_argument('source_dir',
   help='source file/directory that contain the 
test result files to summarise')
+parser_build.add_argument('--branch', '-B', default='master', help="Branch 
to find commit in")
+parser_build.add_argument('--commit', help="Revision to report")
 parser_build.add_argument('-t', '--tag', default='',
   help='source_dir is a git repository, report on 
the tag specified from that repository')
-- 
2.7.4

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH v3] cmake: Reduce verbosity for make invocation

2019-03-11 Thread Douglas Royds

New variable OECMAKE_VERBOSE_MAKEFILE defaults to True.

Since the dawn of time, we have set CMAKE_VERBOSE_MAKEFILE=1 (True) in 
cmake.bbclass.
Back in 2016, we also explicitly set VERBOSE=1 in cmake_do_compile(),
to ensure that make (and ninja) output were verbose in log.do_compile.

Setting OECMAKE_VERBOSE_MAKEFILE to False means that make (or ninja)
invocations from the command-line are non-verbose,
giving CMake's default human-readable output on the terminal instead.
The user can still invoke VERBOSE=1 make if they do want verbose output.
This has no effect on the verbose output that goes into the logs.

Signed-off-by: Douglas Royds 
---
 meta/classes/cmake.bbclass | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/meta/classes/cmake.bbclass b/meta/classes/cmake.bbclass
index fa7f68c99b..0d44a74046 100644
--- a/meta/classes/cmake.bbclass
+++ b/meta/classes/cmake.bbclass
@@ -62,6 +62,7 @@ EXTRA_OECMAKE_BUILD_prepend_task-install = 
"${PARALLEL_MAKEINST} "
 
 OECMAKE_TARGET_COMPILE ?= "all"
 OECMAKE_TARGET_INSTALL ?= "install"
+OECMAKE_VERBOSE_MAKEFILE ?= "True"
 
 # CMake expects target architectures in the format of uname(2),
 # which do not always match TARGET_ARCH, so all the necessary
@@ -164,7 +165,7 @@ cmake_do_configure() {
  
-DCMAKE_INSTALL_DATAROOTDIR:PATH=${@os.path.relpath(d.getVar('datadir'), 
d.getVar('prefix'))} \
  -DCMAKE_INSTALL_SO_NO_EXE=0 \
  -DCMAKE_TOOLCHAIN_FILE=${WORKDIR}/toolchain.cmake \
- -DCMAKE_VERBOSE_MAKEFILE=1 \
+ -DCMAKE_VERBOSE_MAKEFILE=${OECMAKE_VERBOSE_MAKEFILE} \
  -DCMAKE_NO_SYSTEM_FROM_IMPORTED=1 \
  ${EXTRA_OECMAKE} \
  -Wno-dev
-- 
2.17.1

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] glibc: fix do_populate_sdk fail when multilib used

2019-03-11 Thread changqing.li

From: Changqing Li 

fix below error:

file /usr/include/bits/procfs-id.h conflicts between attempted installs of 
lib32-libc6-dev-2.29-r0.armv7vet2hf_vfp and libc6-dev-2.29-r0.aarch64
file /usr/include/bits/procfs.h conflicts between attempted installs of 
lib32-libc6-dev-2.29-r0.armv7vet2hf_vfp and libc6-dev-2.29-r0.aarch64
file /usr/include/bits/shmlba.h conflicts between attempted installs of 
lib32-libc6-dev-2.29-r0.armv7vet2hf_vfp and libc6-dev-2.29-r0.aarch64

Signed-off-by: Changqing Li 
---
 meta/recipes-core/glibc/glibc-package.inc | 1 +
 1 file changed, 1 insertion(+)

diff --git a/meta/recipes-core/glibc/glibc-package.inc 
b/meta/recipes-core/glibc/glibc-package.inc
index b925961..b7c64a0 100644
--- a/meta/recipes-core/glibc/glibc-package.inc
+++ b/meta/recipes-core/glibc/glibc-package.inc
@@ -148,6 +148,7 @@ do_install_armmultilib () {
oe_multilib_header bits/endian.h bits/fcntl.h bits/fenv.h 
bits/fp-fast.h bits/hwcap.h bits/ipc.h bits/link.h bits/wordsize.h
oe_multilib_header bits/local_lim.h bits/mman.h bits/msq.h 
bits/pthreadtypes.h bits/pthreadtypes-arch.h  bits/sem.h  bits/semaphore.h 
bits/setjmp.h
oe_multilib_header bits/shm.h bits/sigstack.h bits/stat.h bits/statfs.h 
bits/typesizes.h
+   oe_multilib_header bits/procfs-id.h bits/procfs.h bits/shmlba.h
 
oe_multilib_header fpu_control.h gnu/lib-names.h gnu/stubs.h ieee754.h
 
-- 
2.7.4

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 07/12] xev: update to 1.2.3

Re: [OE-core] [PATCH] scripts/resulttool: Enhance retrieving test cases value

[OE-core] [PATCH] resulttool/manualexecution: To output right test case id

[OE-core] [PATCH] scripts/resulttool: Enhance retrieving test cases value

[OE-core] [PATCH 0/1] oe-init-build-env: Error out when failed to locate cwd

[OE-core] [PATCH 1/1] oe-init-build-env: Error out when failed to locate cwd

[OE-core] [PATCH] correct do_patch for kernel bbappend in sdk

Re: [OE-core] [PATCH 4/5] linux-yocto: Fix systemtap issue on armv7

[OE-core] [PATCH] systemd: do not disable SELinux with musl

Re: [OE-core] [PATCH 4/5] linux-yocto: Fix systemtap issue on armv7

Re: [OE-core] Can't build product that uses DEFAULTTUNE="arm926ejs"

[OE-core] [PATCH 2/2] arm-tunes: Prefer the -mcpu option over -march

[OE-core] [PATCH 1/2] Revert "arm-tunes: Remove -march option if mcpu is already added"

Re: [OE-core] [PATCH 07/12] xev: update to 1.2.3

Re: [OE-core] [sumo][PATCH] busybox: backport fix for issues introduced by CVE-2011-5325.patch

Re: [OE-core] [PATCH 1/5] qemuarm: Swap for an arm7ve (A15) configuration

Re: [OE-core] [PATCH 1/5] qemuarm: Swap for an arm7ve (A15) configuration

Re: [OE-core] [PATCH 1/5] qemuarm: Swap for an arm7ve (A15) configuration

Re: [OE-core] [PATCH] cmake: Reduce verbosity for make invocation

[OE-core] [PATCH] gst-examples: switch to gitlab url and https protocol

[OE-core] Yocto Project Unassigned Bugs - Help Needed

[OE-core] [V2][PATCH] xev: update to 1.2.3

Re: [OE-core] [PATCH] cmake: Reduce verbosity for make invocation

[OE-core] [PATCH] virglrenderer: requires distro feature opengl

Re: [OE-core] [PATCH] linux-yocto/5.0: fix system tap for arm

Re: [OE-core] [PATCH] linux-yocto/5.0: fix system tap for arm

[OE-core] [PATCH] createrepo-c: fix for do_package_qa

Re: [OE-core] [PATCH] cmake: Reduce verbosity for make invocation

Re: [OE-core] [PATCH] cmake: Reduce verbosity for make invocation

Re: [OE-core] [OE-Core][PATCH v2 3/3] devtool: provide support for devtool menuconfig command.

[OE-core] [PATCH v2] cmake: Reduce verbosity for make invocation

[OE-core] [PATCH] resulttool/report: Enable roll-up report for a commit

[OE-core] [PATCH v3] cmake: Reduce verbosity for make invocation

[OE-core] [PATCH] glibc: fix do_populate_sdk fail when multilib used

34 matches

Site Navigation

Mail list logo

Footer information