[OE-core] [PATCH 1/2] perl: fix CVE-2016-6185

[mingli.yu]

From: Mingli Yu 

Backport patch to fix CVE-2016-6185 from perl upstream:
http://perl5.git.perl.org/perl.git/commitdiff/08e3451d7

Signed-off-by: Mingli Yu 
---
 .../perl/perl/perl-fix-CVE-2016-6185.patch | 127 +
 meta/recipes-devtools/perl/perl_5.22.1.bb  |   1 +
 2 files changed, 128 insertions(+)
 create mode 100644 meta/recipes-devtools/perl/perl/perl-fix-CVE-2016-6185.patch

diff --git a/meta/recipes-devtools/perl/perl/perl-fix-CVE-2016-6185.patch 
b/meta/recipes-devtools/perl/perl/perl-fix-CVE-2016-6185.patch
new file mode 100644
index 000..b4acb9b
--- /dev/null
+++ b/meta/recipes-devtools/perl/perl/perl-fix-CVE-2016-6185.patch
@@ -0,0 +1,127 @@
+From 7cedaa8bc2ca9e63369d0e2d4c4c23af9febb93a Mon Sep 17 00:00:00 2001
+From: Father Chrysostomos 
+Date: Sat, 2 Jul 2016 22:56:51 -0700
+Subject: [PATCH] perl: fix CVE-2016-6185
+MIME-Version: 1.0
+
+Don't let XSLoader load relative paths
+
+[rt.cpan.org #115808]
+
+The logic in XSLoader for determining the library goes like this:
+
+my $c = () = split(/::/,$caller,-1);
+$modlibname =~ s,[\\/][^\\/]+$,, while $c--;# Q basename
+my $file = "$modlibname/auto/$modpname/$modfname.bundle";
+
+(That last line varies by platform.)
+
+$caller is the calling package.  $modlibname is the calling file.  It
+removes as many path segments from $modlibname as there are segments
+in $caller.  So if you have Foo/Bar/XS.pm calling XSLoader from the
+Foo::Bar package, the $modlibname will end up containing the path in
+@INC where XS.pm was found, followed by "/Foo".  Usually the fallback
+to Dynaloader::bootstrap_inherit, which does an @INC search, makes
+things Just Work.
+
+But if our hypothetical Foo/Bar/XS.pm actually calls
+XSLoader::load from inside a string eval, then path ends up being
+"(eval 1)/auto/Foo/Bar/Bar.bundle".
+
+So if someone creates a directory named '(eval 1)' with a naughty
+binary file in it, it will be loaded if a script using Foo::Bar is run
+in the parent directory.
+
+This commit makes XSLoader fall back to Dynaloader's @INC search if
+the calling file has a relative path that is not found in @INC.
+
+Backport patch from http://perl5.git.perl.org/perl.git/commitdiff/08e3451d7
+
+Upstream-Status: Backport
+Signed-off-by: Mingli Yu 
+---
+ dist/XSLoader/XSLoader_pm.PL | 25 +
+ dist/XSLoader/t/XSLoader.t   | 27 ++-
+ 2 files changed, 51 insertions(+), 1 deletion(-)
+
+diff --git a/dist/XSLoader/XSLoader_pm.PL b/dist/XSLoader/XSLoader_pm.PL
+index 668411d..778e46b 100644
+--- a/dist/XSLoader/XSLoader_pm.PL
 b/dist/XSLoader/XSLoader_pm.PL
+@@ -104,6 +104,31 @@ print OUT <<'EOT';
+ my $modpname = join('/',@modparts);
+ my $c = () = split(/::/,$caller,-1);
+ $modlibname =~ s,[\\/][^\\/]+$,, while $c--;# Q basename
++# Does this look like a relative path?
++if ($modlibname !~ m|^[\\/]|) {
++# Someone may have a #line directive that changes the file name, or
++# may be calling XSLoader::load from inside a string eval.  We cer-
++# tainly do not want to go loading some code that is not in @INC,
++# as it could be untrusted.
++#
++# We could just fall back to DynaLoader here, but then the rest of
++# this function would go untested in the perl core, since all @INC
++# paths are relative during testing.  That would be a time bomb
++# waiting to happen, since bugs could be introduced into the code.
++#
++# So look through @INC to see if $modlibname is in it.  A rela-
++# tive $modlibname is not a common occurrence, so this block is
++# not hot code.
++FOUND: {
++for (@INC) {
++if ($_ eq $modlibname) {
++last FOUND;
++}
++}
++# Not found.  Fall back to DynaLoader.
++goto \::bootstrap_inherit;
++}
++}
+ EOT
+ 
+ my $dl_dlext = quotemeta($Config::Config{'dlext'});
+diff --git a/dist/XSLoader/t/XSLoader.t b/dist/XSLoader/t/XSLoader.t
+index 2ff11fe..1e86faa 100644
+--- a/dist/XSLoader/t/XSLoader.t
 b/dist/XSLoader/t/XSLoader.t
+@@ -33,7 +33,7 @@ my %modules = (
+ 'Time::HiRes'=> q| ::can_ok( 'Time::HiRes' => 'usleep'  ) |,  # 5.7.3
+ );
+ 
+-plan tests => keys(%modules) * 3 + 9;
++plan tests => keys(%modules) * 3 + 10;
+ 
+ # Try to load the module
+ use_ok( 'XSLoader' );
+@@ -125,3 +125,28 @@ XSLoader::load("Devel::Peek");
+ EOS
+ or ::diag $@;
+ }
++
++SKIP: {
++  skip "File::Path not available", 1
++unless eval { require File::Path };
++  my $name = "phooo$$";
++  File::Path::make_path("$name/auto/Foo/Bar");
++  open my $fh,
++">$name/auto/Foo/Bar/Bar.$Config::Config{'dlext'}";
++  close $fh;
++  my $fell_back;
++  local *XSLoader::bootstrap_inherit = sub {
++$fell_back++;
++# Break out of 

[OE-core] [PATCH 2/2] perl: fix CVE-2015-8607

[mingli.yu]

From: Mingli Yu 

Backport patch to fix CVE-2015-8607 from perl upstream:
http://perl5.git.perl.org/perl.git/commitdiff/0b6f93036de171c12ba95d415e264d9cf7f4e1fd

Signed-off-by: Mingli Yu 
---
 .../perl/perl/perl-fix-CVE-2015-8607.patch | 74 ++
 meta/recipes-devtools/perl/perl_5.22.1.bb  |  1 +
 2 files changed, 75 insertions(+)
 create mode 100644 meta/recipes-devtools/perl/perl/perl-fix-CVE-2015-8607.patch

diff --git a/meta/recipes-devtools/perl/perl/perl-fix-CVE-2015-8607.patch 
b/meta/recipes-devtools/perl/perl/perl-fix-CVE-2015-8607.patch
new file mode 100644
index 000..ca27ee6
--- /dev/null
+++ b/meta/recipes-devtools/perl/perl/perl-fix-CVE-2015-8607.patch
@@ -0,0 +1,74 @@
+From 652c8d4852a69f1bb4d387946f9b76350a1f0d0e Mon Sep 17 00:00:00 2001
+From: Tony Cook 
+Date: Tue, 15 Dec 2015 10:56:54 +1100
+Subject: [PATCH] perl: fix CVE-2015-8607
+
+ensure File::Spec::canonpath() preserves taint
+
+Previously the unix specific XS implementation of canonpath() would
+return an untainted path when supplied a tainted path.
+
+For the empty string case, newSVpvs() already sets taint as needed on
+its result.
+
+This issue was assigned CVE-2015-8607.  [perl #126862]
+
+Backport patch from 
http://perl5.git.perl.org/perl.git/commitdiff/0b6f93036de171c12ba95d415e264d9cf7f4e1fd
+
+Upstream-Status: Backport
+
+Signed-off-by: Mingli Yu 
+---
+ dist/PathTools/Cwd.xs|  1 +
+ dist/PathTools/t/taint.t | 19 ++-
+ 2 files changed, 19 insertions(+), 1 deletion(-)
+
+diff --git a/dist/PathTools/Cwd.xs b/dist/PathTools/Cwd.xs
+index 9d4dcf0..3d018dc 100644
+--- a/dist/PathTools/Cwd.xs
 b/dist/PathTools/Cwd.xs
+@@ -535,6 +535,7 @@ THX_unix_canonpath(pTHX_ SV *path)
+ *o = 0;
+ SvPOK_on(retval);
+ SvCUR_set(retval, o - SvPVX(retval));
++SvTAINT(retval);
+ return retval;
+ }
+ 
+diff --git a/dist/PathTools/t/taint.t b/dist/PathTools/t/taint.t
+index 309b3e5..48f8c5b 100644
+--- a/dist/PathTools/t/taint.t
 b/dist/PathTools/t/taint.t
+@@ -12,7 +12,7 @@ use Test::More;
+ BEGIN {
+ plan(
+ ${^TAINT}
+-? (tests => 17)
++? (tests => 21)
+ : (skip_all => "A perl without taint support")
+ );
+ }
+@@ -34,3 +34,20 @@ foreach my $func (@Functions) {
+ 
+ # Previous versions of Cwd tainted $^O
+ is !tainted($^O), 1, "\$^O should not be tainted";
++
++{
++# [perl #126862] canonpath() loses taint
++my $tainted = substr($ENV{PATH}, 0, 0);
++# yes, getcwd()'s result should be tainted, and is tested above
++# but be sure
++ok tainted(File::Spec->canonpath($tainted . Cwd::getcwd)),
++"canonpath() keeps taint on non-empty string";
++ok tainted(File::Spec->canonpath($tainted)),
++"canonpath() keeps taint on empty string";
++
++(Cwd::getcwd() =~ /^(.*)/);
++my $untainted = $1;
++ok !tainted($untainted), "make sure our untainted value is untainted";
++ok !tainted(File::Spec->canonpath($untainted)),
++"canonpath() doesn't add taint to untainted string";
++}
+-- 
+2.8.1
+
diff --git a/meta/recipes-devtools/perl/perl_5.22.1.bb 
b/meta/recipes-devtools/perl/perl_5.22.1.bb
index 33cad9e..b904674 100644
--- a/meta/recipes-devtools/perl/perl_5.22.1.bb
+++ b/meta/recipes-devtools/perl/perl_5.22.1.bb
@@ -67,6 +67,7 @@ SRC_URI += " \
 file://perl-test-customized.patch \
 file://perl-fix-CVE-2016-2381.patch \
 file://perl-fix-CVE-2016-6185.patch \
+file://perl-fix-CVE-2015-8607.patch \
 "
 
 # Fix test case issues
-- 
2.8.1

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

[OE-core] [PATCH 2/2] scons.bbclass: reduce build time by adding PARALLEL_MAKEINST to scons install params

[Andreas Müller]

During install all files are recompiled. This should be investigated further
later. Currently only one file is recompiled at the same time. Reduce install
time significantly by setting PARALLEL_MAKEINST option in do_install task.

Measured with recipes inheriting scons (gpsd do_compile broken for me) by
the following sequence:

without this patch:
bitbake pingus mongodb mixxx
bitbake -ccleansstate pingus mongodb mixxx
time bitbake pingus mongodb mixxx
...
real48m5.467s
user138m47.763s
sys 11m9.423s

with this patch
bitbake -ccleansstate pingus mongodb mixxx
time bitbake pingus mongodb mixxx
...
real27m28.521s
user146m59.951s
sys 10m56.218s

Signed-off-by: Andreas Müller 
---
 meta/classes/scons.bbclass | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/classes/scons.bbclass b/meta/classes/scons.bbclass
index 1579b05..4f84ec0 100644
--- a/meta/classes/scons.bbclass
+++ b/meta/classes/scons.bbclass
@@ -10,7 +10,7 @@ scons_do_compile() {
 }
 
 scons_do_install() {
-${STAGING_BINDIR_NATIVE}/scons PREFIX=${D}${prefix} 
prefix=${D}${prefix} install ${EXTRA_OESCONS}|| \
+${STAGING_BINDIR_NATIVE}/scons ${PARALLEL_MAKEINST} 
PREFIX=${D}${prefix} prefix=${D}${prefix} install ${EXTRA_OESCONS}|| \
 die "scons install execution failed."
 }
 
-- 
2.5.5

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

[OE-core] [PATCH 1/2] libunwind: fix build by linking with bfd instead of gold

[Andreas Müller]

works around:
/ld: error: Gperf-simple.o: cannot make copy relocation for 
protected symbol '_Uarm_local_addr_space', defined in 
../src/.libs/libunwind-arm.so
collect2: error: ld returned 1 exit status
Makefile:1038: recipe for target 'Gperf-simple' failed
make[1]: *** [Gperf-simple] Error 1
make[1]: *** Waiting for unfinished jobs
<...>
/ld: error: Lperf-simple.o: cannot make copy relocation for 
protected symbol '_ULarm_local_addr_space', defined in ../src/.libs/libunwind.so
collect2: error: ld returned 1 exit status
Makefile:1094: recipe for target 'Lperf-simple' failed
make[1]: *** [Lperf-simple] Error 1
<...>
ERROR: oe_runmake failed
/ld: error: Gperf-trace.o: cannot make copy relocation for 
protected symbol '_Uarm_local_addr_space', defined in 
../src/.libs/libunwind-arm.so
collect2: error: ld returned 1 exit status
Makefile:1042: recipe for target 'Gperf-trace' failed
make[1]: *** [Gperf-trace] Error 1
/ld: error: Lperf-trace.o: cannot make copy relocation for 
protected symbol '_ULarm_local_addr_space', defined in ../src/.libs/libunwind.so
collect2: error: ld returned 1 exit status
Makefile:1098: recipe for target 'Lperf-trace' failed
make[1]: *** [Lperf-trace] Error 1
<...>
/ld: error: test-coredump-unwind.o: cannot make copy relocation 
for protected symbol '_UCD_accessors', defined in 
../src/.libs/libunwind-coredump.so
collect2: error: ld returned 1 exit status
Makefile:1186: recipe for target 'test-coredump-unwind' failed

Signed-off-by: Andreas Müller 
---
 meta/recipes-support/libunwind/libunwind_git.bb | 1 +
 1 file changed, 1 insertion(+)

diff --git a/meta/recipes-support/libunwind/libunwind_git.bb 
b/meta/recipes-support/libunwind/libunwind_git.bb
index cd4cb89..4249430 100644
--- a/meta/recipes-support/libunwind/libunwind_git.bb
+++ b/meta/recipes-support/libunwind/libunwind_git.bb
@@ -26,3 +26,4 @@ SECURITY_CFLAGS_append_aarch64 = " -fPIE"
 
 S = "${WORKDIR}/git"
 
+LDFLAGS += "-Wl,-z,relro,-z,now ${@bb.utils.contains('DISTRO_FEATURES', 
'ld-is-gold', ' -fuse-ld=bfd ', '', d)}"
-- 
2.5.5

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

[OE-core] [PATCH] perf: Fix to obey LD failure on qemux86-64

[Sujith H]

From: Christopher Larson 

When built on an i686 host for qemux86-64 without the
fix to obey LD and it fails:

/scratch/dogwood/toolchains/x86_64/bin/i686-pc-linux-gnu-ld:
Relocatable linking with relocations from format elf64-x86-64
(/scratch/dogwood/perf-ld-test/build/tmp/work/qemux86_64-mel-linux/perf/1.0-r9/perf-1.0/fs/fs.o)
to format elf32-i386 
(/scratch/dogwood/perf-ld-test/build/tmp/work/qemux86_64-mel-linux/perf/1.0-r9/perf-1.0/fs/libapi-in.o)
is not supported

This is because LD includes HOST_LD_ARCH, which contains TUNE_LDARGS,
which is -m elf32_x86_64 for x86_64. Without that, direct use of ld will fail.

Signed-off-by: Christopher Larson 
Signed-off-by: Sujith Haridasan 
---
 meta/recipes-kernel/perf/perf.bb | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/meta/recipes-kernel/perf/perf.bb b/meta/recipes-kernel/perf/perf.bb
index 88e3a0a..0d104d3 100644
--- a/meta/recipes-kernel/perf/perf.bb
+++ b/meta/recipes-kernel/perf/perf.bb
@@ -79,6 +79,7 @@ EXTRA_OEMAKE = '\
 ARCH=${ARCH} \
 CC="${CC}" \
 AR="${AR}" \
+LD="${LD}" \
 EXTRA_CFLAGS="-ldw" \
 perfexecdir=${libexecdir} \
 NO_GTK2=1 ${TUI_DEFINES} NO_DWARF=1 ${LIBUNWIND_DEFINES} \
@@ -98,7 +99,6 @@ EXTRA_OEMAKE += "\
 'infodir=${@os.path.relpath(infodir, prefix)}' \
 "
 
-
 do_compile() {
# Linux kernel build system is expected to do the right thing
unset CFLAGS
@@ -174,6 +174,7 @@ do_configure_prepend () {
 if [ -e "${S}/tools/lib/api/Makefile" ]; then
 sed -i 's,CC = $(CROSS_COMPILE)gcc,#CC,' ${S}/tools/lib/api/Makefile
 sed -i 's,AR = $(CROSS_COMPILE)ar,#AR,' ${S}/tools/lib/api/Makefile
+sed -i 's,LD = $(CROSS_COMPILE)ld,#LD,' ${S}/tools/lib/api/Makefile
 fi
 if [ -e "${S}/tools/lib/subcmd/Makefile" ]; then
 sed -i 's,CC = $(CROSS_COMPILE)gcc,#CC,' ${S}/tools/lib/subcmd/Makefile
-- 
1.9.1

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

Re: [OE-core] [PATCH] perf: Fix to obey LD failure on host i686

[sujith h]

On Wed, Sep 21, 2016 at 3:22 AM, Andre McCurdy  wrote:

> On Mon, Sep 19, 2016 at 11:00 AM, Christopher Larson
>  wrote:
> >
> > On Mon, Sep 19, 2016 at 4:10 AM, sujith h  wrote:
> >>
> >> On Thu, Sep 8, 2016 at 12:36 PM, Andre McCurdy 
> >> wrote:
> >>>
> >>> On Wed, Sep 7, 2016 at 11:51 PM, Sujith H  wrote:
> >>> > From: Christopher Larson 
> >>> >
> >>> > When built on an i686 host for qemux86-64 without the
> >>> > fix to obey LD and it fails:
> >>> >
> >>> > /scratch/dogwood/toolchains/x86_64/bin/i686-pc-linux-gnu-ld:
> >>> > Relocatable linking with relocations from format elf64-x86-64
> >>> >
> >>> > (/scratch/dogwood/perf-ld-test/build/tmp/work/qemux86_
> 64-mel-linux/perf/1.0-r9/perf-1.0/fs/fs.o)
> >>> > to format elf32-i386
> >>> > (/scratch/dogwood/perf-ld-test/build/tmp/work/qemux86_
> 64-mel-linux/perf/1.0-r9/perf-1.0/fs/libapi-in.o)
> >>> > is not supported
> >>> >
> >>> > This is because LD includes HOST_LD_ARCH, which contains TUNE_LDARGS,
> >>> > which is -m elf32_x86_64 for x86_64. Without that, direct use of ld
> >>> > will fail.
> >>> >
> >>> > Signed-off-by: Christopher Larson 
> >>> > Signed-off-by: Sujith Haridasan 
> >>> > ---
> >>> >  meta/recipes-kernel/perf/perf.bb | 9 +
> >>> >  1 file changed, 9 insertions(+)
> >>> >
> >>> > diff --git a/meta/recipes-kernel/perf/perf.bb
> >>> > b/meta/recipes-kernel/perf/perf.bb
> >>> > index 88e3a0a..85fe0ea 100644
> >>> > --- a/meta/recipes-kernel/perf/perf.bb
> >>> > +++ b/meta/recipes-kernel/perf/perf.bb
> >>> > @@ -79,6 +79,7 @@ EXTRA_OEMAKE = '\
> >>> >  ARCH=${ARCH} \
> >>> >  CC="${CC}" \
> >>> >  AR="${AR}" \
> >>> > +LD="${LD}" \
> >>> >  EXTRA_CFLAGS="-ldw" \
> >>> >  perfexecdir=${libexecdir} \
> >>> >  NO_GTK2=1 ${TUI_DEFINES} NO_DWARF=1 ${LIBUNWIND_DEFINES} \
> >>> > @@ -98,6 +99,14 @@ EXTRA_OEMAKE += "\
> >>> >  'infodir=${@os.path.relpath(infodir, prefix)}' \
> >>> >  "
> >>> >
> >>> > +do_configure_prepend () {
> >>> > +for makefile in "${S}/tools/perf/Makefile.perf" \
> >>> > +"${S}/tools/lib/api/Makefile"; do
> >>> > +if [ -e "$makefile" ]; then
> >>> > +sed -i 's,LD = $(CROSS_COMPILE)ld,#LD,' "$makefile"
> >>> > +fi
> >>> > +done
> >>> > +}
> >>>
> >>> Isn't passing LD via the Make command line enough to over-ride these
> >>> definitions in the Makefiles?
> >>
> >> Unfortunately that didn't helped I believe. That's the reason, this
> patch
> >> was created.
> >
> > The patch mirrored the handling of CC/AR, which also used sed at the time
> > the append was created. If upstream removed the sed for those, then we
> can
> > remove it for LD as well, presumably. I’d recommend actually testing
> that.
>
> Brief testing suggests that commenting out LD in
> ${S}/tools/lib/api/Makefile is still required.
>
> For clarity the new sed command should probably be added next to the
> existing ones for CC and AR though, rather than on its own in a new
> do_configure_prepend().
>
> There is no "LD = ..." line to comment out in
> ${S}/tools/perf/Makefile.perf.
>

I will update the patch  as per the suggestion.

>
> > --
> > Christopher Larson
> > kergoth at gmail dot com
> > Founder - BitBake, OpenEmbedded, OpenZaurus
> > Maintainer - Tslib
> > Senior Software Engineer, Mentor Graphics
>



-- 
സുജിത് ഹരിദാസന്
Bangalore
Contributor to KDE project
Contributor to Yocto project
http://fci.wikia.com/wiki/Anti-DRM-Campaign
 http://sujithh.info
C-x C-c
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 1/1] rpm: make install with --nosignature and --nodigest work

[Robert Yang]

On 09/21/2016 04:33 AM, Mark Hatle wrote:

On 9/20/16 10:00 AM, Burton, Ross wrote:


On 20 September 2016 at 09:15, Hongxu Jia > wrote:

-Upstream-Status: Submitted [Sent email to rpm-de...@rpm5.org
]
+Upstream-Status: Rejected [Sent email to rpm-de...@rpm5.org
]
+http://rpm5.org/community/rpm-devel/5655.html



Considering upstream has explicitly rejected this patch, why should we accept 
it?

Ross




I'm confused by what the patch is doing looking at it.

It sounds like from the description there is a bug that without the change,
packages with (intentionally) bad checksums and such are allowed to be 
installed.

The bug is caused by a previous patch that enabled nosignature, etc -- because
the comparisons turned out to be backwards.

So really nosignature, etc is already in place -- it's just not working 
properly?

What was rejected upstream is the use of nosignature in any context.  RPM5
maintainer believes it is unwise and unsafe to permit uses to install packages
that have failed basic validation.  (I tend to agree.)  Similarly, even being
able to run queries and other operations against them may be dangerous as well.


If command like "rpm5 -qp --nosignature --nodigest " queries database,
then it would cause rpm5 hang when more than one "rpm5 -qp" is running, so I
fixed the *query* problem, and the *install* problem is not caused by the fix.
Btw., *rpm4* doesn't query database when "rpm -qp file.rpm", if we are going
to use dnf in next release, maybe we can consider using rpm4 as Fedora does.
I did a rough statistics for oe-core's local patches, the winner is rpm, it
has 77 local patches, that's not good for maintaining, and you can imagine that
how many times it surprised us. rpm4 should be more stable than rpm5, I don't
know how many distros use rpm5, I can't access rpm5.org atm, it seems that the
web is down (It was OK yesterday), but widely used distros like Redhat and Suse
uses rpm4, so maybe rpm4 will make our life much more easier, and also for
yocto's user. I think that why we need rpm5 before was because we need use it
to compute the package dependencies, but now we have smartpm, so we don't rely
on that any more.

Here is the recipe list which has more than 10 local patches, and we have 1762
patches atm:
 77 rpm
 59 gcc-5.4
 49 gcc-6.2
 36 ltp
 31 python3
 30 perl
 29 openssl
 28 man
 27 glibc
 24 python
 23 tcp-wrappers-7.6
 23 systemd
 18 busybox
 14 syslinux
 14 python-smartpm
 14 elfutils-0.166
 14 apt
 13 qemu
 13 libtool
 13 gstreamer1.0-plugins-bad
 13 glib-2.0
 13 binutils
 13 bind
 12 coreutils-6.9
 11 valgrind
 11 gdb
 11 dhcp
 11 autoconf
 10 unzip
 10 dpkg
 10 console-tools-0.3.2



If fixing the problem is as simple as reverting the other change -- and that
doesn't cause other problems elsewhere...  I'd rather see that.


We can't revert the patch, it would break packagefeed-stability.bbclass,
we will see the hang



--Mark


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

Re: [OE-core] [PATCH V2 1/1] kernel.bbclass: Add kernel_version_sanity_check function

[Robert Yang]

Hi,

There is an error on autobuilder related to this patch:

http://autobuilder.yocto.io:8010/builders/nightly-x86-64-lsb/builds/60/steps/BuildImages_1/logs/stdio

// Robert

On 09/17/2016 07:48 AM, California Sullivan wrote:

The kernel being built should match what the recipe claims it is
building. This function ensures that happens by comparing the version
information in the kernel's Makefile to the PV the recipe is using.

v2 changes:
* Match against PV instead of LINUX_VERSION
* Match against EXTRAVERSION as well (e.g., -rc4)
* Cleaned up version string building

Fixes [YOCTO #6767].

Signed-off-by: California Sullivan 
---
 meta/classes/kernel.bbclass   | 30 ++
 meta/recipes-kernel/linux/linux-yocto.inc |  1 +
 2 files changed, 31 insertions(+)

diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index a6112e8..f894795 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -327,6 +327,36 @@ kernel_do_install() {
 }
 do_install[prefuncs] += "package_get_auto_pr"

+# Must be ran no earlier than after do_kernel_checkout or else Makefile won't 
be in ${S}/Makefile
+do_kernel_version_sanity_check() {
+   # The Makefile determines the kernel version shown at runtime
+   # Don't use KERNEL_VERSION because the headers it grabs the version 
from aren't generated until do_compile
+   VERSION=$(grep "^VERSION =" ${S}/Makefile | sed s/.*=\ *//)
+   PATCHLEVEL=$(grep "^PATCHLEVEL =" ${S}/Makefile | sed s/.*=\ *//)
+   SUBLEVEL=$(grep "^SUBLEVEL =" ${S}/Makefile | sed s/.*=\ *//)
+   EXTRAVERSION=$(grep "^EXTRAVERSION =" ${S}/Makefile | sed s/.*=\ *//)
+
+   # Build a string for regex and a plain version string
+   reg="^${VERSION}\.${PATCHLEVEL}"
+   vers="${VERSION}.${PATCHLEVEL}"
+   if [ -n "${SUBLEVEL}" ]; then
+   # Ignoring a SUBLEVEL of zero is fine
+   if [ "${SUBLEVEL}" = "0" ]; then
+   reg="${reg}(\.${SUBLEVEL})?"
+   else
+   reg="${reg}\.${SUBLEVEL}"
+   vers="${vers}.${SUBLEVEL}"
+   fi
+   fi
+   vers="${vers}${EXTRAVERSION}"
+   reg="${reg}${EXTRAVERSION}"
+
+   if [ -z `echo ${PV} | grep -E "${reg}"` ]; then
+   bbfatal "Package Version (${PV}) does not match of kernel being 
built (${vers}). Please update the PV variable to match the kernel source."
+   fi
+   exit 0
+}
+
 addtask shared_workdir after do_compile before do_compile_kernelmodules
 addtask shared_workdir_setscene

diff --git a/meta/recipes-kernel/linux/linux-yocto.inc 
b/meta/recipes-kernel/linux/linux-yocto.inc
index 98a48ec..d979662 100644
--- a/meta/recipes-kernel/linux/linux-yocto.inc
+++ b/meta/recipes-kernel/linux/linux-yocto.inc
@@ -55,6 +55,7 @@ do_install_append(){
 }

 # extra tasks
+addtask kernel_version_sanity_check after do_kernel_checkout before do_compile
 addtask kernel_link_images after do_compile before do_install
 addtask validate_branches before do_patch after do_kernel_checkout
 addtask kernel_configcheck after do_configure before do_compile


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

[OE-core] [PATCH] wpa_supplicant: Security Advisory-CVE-2016-4477

[Zhixiong Chi]

Add CVE-2016-4476 patch for avoiding \n and \r characters in passphrase
parameters, which allows remote attackers to cause a denial of service
(daemon outage) via a crafted WPS operation.
Patches came from http://w1.fi/security/2016-1/

Signed-off-by: Zhixiong Chi 
---
 ...parameter-set-with-invalid-passphrase-cha.patch | 52 ++
 ...CRED-commands-with-newline-characters-in-.patch | 63 ++
 ...commands-with-newline-characters-in-the-s.patch | 51 ++
 .../wpa-supplicant/wpa-supplicant_2.5.bb   |  3 ++
 4 files changed, 169 insertions(+)
 create mode 100644 
meta/recipes-connectivity/wpa-supplicant/wpa-supplicant/0001-Reject-psk-parameter-set-with-invalid-passphrase-cha.patch
 create mode 100644 
meta/recipes-connectivity/wpa-supplicant/wpa-supplicant/0002-Reject-SET_CRED-commands-with-newline-characters-in-.patch
 create mode 100644 
meta/recipes-connectivity/wpa-supplicant/wpa-supplicant/0003-Reject-SET-commands-with-newline-characters-in-the-s.patch

diff --git 
a/meta/recipes-connectivity/wpa-supplicant/wpa-supplicant/0001-Reject-psk-parameter-set-with-invalid-passphrase-cha.patch
 
b/meta/recipes-connectivity/wpa-supplicant/wpa-supplicant/0001-Reject-psk-parameter-set-with-invalid-passphrase-cha.patch
new file mode 100644
index 000..5384511
--- /dev/null
+++ 
b/meta/recipes-connectivity/wpa-supplicant/wpa-supplicant/0001-Reject-psk-parameter-set-with-invalid-passphrase-cha.patch
@@ -0,0 +1,52 @@
+From 73e4abb24a936014727924d8b0b2965edfc117dd Mon Sep 17 00:00:00 2001
+From: Jouni Malinen 
+Date: Fri, 4 Mar 2016 18:46:41 +0200
+Subject: [PATCH 1/3] Reject psk parameter set with invalid passphrase
+ character
+
+WPA/WPA2-Personal passphrase is not allowed to include control
+characters. Reject a passphrase configuration attempt if that passphrase
+includes an invalid passphrase.
+
+This fixes an issue where wpa_supplicant could have updated the
+configuration file psk parameter with arbitrary data from the control
+interface or D-Bus interface. While those interfaces are supposed to be
+accessible only for trusted users/applications, it may be possible that
+an untrusted user has access to a management software component that
+does not validate the passphrase value before passing it to
+wpa_supplicant.
+
+This could allow such an untrusted user to inject up to 63 characters of
+almost arbitrary data into the configuration file. Such configuration
+file could result in wpa_supplicant trying to load a library (e.g.,
+opensc_engine_path, pkcs11_engine_path, pkcs11_module_path,
+load_dynamic_eap) from user controlled location when starting again.
+This would allow code from that library to be executed under the
+wpa_supplicant process privileges.
+
+Upstream-Status: Backport
+
+Signed-off-by: Jouni Malinen 
+---
+ wpa_supplicant/config.c | 6 ++
+ 1 file changed, 6 insertions(+)
+
+diff --git a/wpa_supplicant/config.c b/wpa_supplicant/config.c
+index b1c7870..fdd9643 100644
+--- a/wpa_supplicant/config.c
 b/wpa_supplicant/config.c
+@@ -478,6 +478,12 @@ static int wpa_config_parse_psk(const struct parse_data 
*data,
+   }
+   wpa_hexdump_ascii_key(MSG_MSGDUMP, "PSK (ASCII passphrase)",
+ (u8 *) value, len);
++  if (has_ctrl_char((u8 *) value, len)) {
++  wpa_printf(MSG_ERROR,
++ "Line %d: Invalid passphrase character",
++ line);
++  return -1;
++  }
+   if (ssid->passphrase && os_strlen(ssid->passphrase) == len &&
+   os_memcmp(ssid->passphrase, value, len) == 0) {
+   /* No change to the previously configured value */
+-- 
+1.9.1
diff --git 
a/meta/recipes-connectivity/wpa-supplicant/wpa-supplicant/0002-Reject-SET_CRED-commands-with-newline-characters-in-.patch
 
b/meta/recipes-connectivity/wpa-supplicant/wpa-supplicant/0002-Reject-SET_CRED-commands-with-newline-characters-in-.patch
new file mode 100644
index 000..3289b41
--- /dev/null
+++ 
b/meta/recipes-connectivity/wpa-supplicant/wpa-supplicant/0002-Reject-SET_CRED-commands-with-newline-characters-in-.patch
@@ -0,0 +1,63 @@
+From b166cd84a77a6717be9600bf95378a0055d6f5a5 Mon Sep 17 00:00:00 2001
+From: Jouni Malinen 
+Date: Tue, 5 Apr 2016 23:33:10 +0300
+Subject: [PATCH 2/3] Reject SET_CRED commands with newline characters in the
+ string values
+
+Most of the cred block parameters are written as strings without
+filtering and if there is an embedded newline character in the value,
+unexpected configuration file data might be written.
+
+This fixes an issue where wpa_supplicant could have updated the
+configuration file cred parameter with arbitrary data from the control
+interface or D-Bus interface. While those interfaces are supposed to be
+accessible 

[OE-core] [PATCH] wpa_supplicant: Security Advisory-wpa_supplicant-CVE-2016-4476

[Zhixiong Chi]

Add CVE-2016-4476 patch for avoiding \n and \r characters in passphrase
parameters, which allows remote attackers to cause a denial of service
(daemon outage) via a crafted WPS operation.
Patches came from http://w1.fi/security/2016-1/

Signed-off-by: Zhixiong Chi 
---
 ...ject-a-Credential-with-invalid-passphrase.patch | 83 ++
 ...ines-from-wpa_supplicant-config-network-o.patch | 83 ++
 .../wpa-supplicant/wpa-supplicant_2.5.bb   |  2 +
 3 files changed, 168 insertions(+)
 create mode 100644 
meta/recipes-connectivity/wpa-supplicant/wpa-supplicant/0001-WPS-Reject-a-Credential-with-invalid-passphrase.patch
 create mode 100644 
meta/recipes-connectivity/wpa-supplicant/wpa-supplicant/0002-Remove-newlines-from-wpa_supplicant-config-network-o.patch

diff --git 
a/meta/recipes-connectivity/wpa-supplicant/wpa-supplicant/0001-WPS-Reject-a-Credential-with-invalid-passphrase.patch
 
b/meta/recipes-connectivity/wpa-supplicant/wpa-supplicant/0001-WPS-Reject-a-Credential-with-invalid-passphrase.patch
new file mode 100644
index 000..f01403d
--- /dev/null
+++ 
b/meta/recipes-connectivity/wpa-supplicant/wpa-supplicant/0001-WPS-Reject-a-Credential-with-invalid-passphrase.patch
@@ -0,0 +1,83 @@
+From ecbb0b3dc122b0d290987cf9c84010bbe53e1022 Mon Sep 17 00:00:00 2001
+From: Jouni Malinen 
+Date: Fri, 4 Mar 2016 17:20:18 +0200
+Subject: [PATCH 1/2] WPS: Reject a Credential with invalid passphrase
+
+WPA/WPA2-Personal passphrase is not allowed to include control
+characters. Reject a Credential received from a WPS Registrar both as
+STA (Credential) and AP (AP Settings) if the credential is for WPAPSK or
+WPA2PSK authentication type and includes an invalid passphrase.
+
+This fixes an issue where hostapd or wpa_supplicant could have updated
+the configuration file PSK/passphrase parameter with arbitrary data from
+an external device (Registrar) that may not be fully trusted. Should
+such data include a newline character, the resulting configuration file
+could become invalid and fail to be parsed.
+
+Upstream-Status: Backport
+
+Signed-off-by: Jouni Malinen 
+---
+ src/utils/common.c | 12 
+ src/utils/common.h |  1 +
+ src/wps/wps_attr_process.c | 10 ++
+ 3 files changed, 23 insertions(+)
+
+diff --git a/src/utils/common.c b/src/utils/common.c
+index 450e2c6..27b7c02 100644
+--- a/src/utils/common.c
 b/src/utils/common.c
+@@ -697,6 +697,18 @@ int is_hex(const u8 *data, size_t len)
+ }
+ 
+ 
++int has_ctrl_char(const u8 *data, size_t len)
++{
++  size_t i;
++
++  for (i = 0; i < len; i++) {
++  if (data[i] < 32 || data[i] == 127)
++  return 1;
++  }
++  return 0;
++}
++
++
+ size_t merge_byte_arrays(u8 *res, size_t res_len,
+const u8 *src1, size_t src1_len,
+const u8 *src2, size_t src2_len)
+diff --git a/src/utils/common.h b/src/utils/common.h
+index 701dbb2..a972240 100644
+--- a/src/utils/common.h
 b/src/utils/common.h
+@@ -488,6 +488,7 @@ const char * wpa_ssid_txt(const u8 *ssid, size_t ssid_len);
+ 
+ char * wpa_config_parse_string(const char *value, size_t *len);
+ int is_hex(const u8 *data, size_t len);
++int has_ctrl_char(const u8 *data, size_t len);
+ size_t merge_byte_arrays(u8 *res, size_t res_len,
+const u8 *src1, size_t src1_len,
+const u8 *src2, size_t src2_len);
+diff --git a/src/wps/wps_attr_process.c b/src/wps/wps_attr_process.c
+index eadb22f..e8c4579 100644
+--- a/src/wps/wps_attr_process.c
 b/src/wps/wps_attr_process.c
+@@ -229,6 +229,16 @@ static int wps_workaround_cred_key(struct wps_credential 
*cred)
+   cred->key_len--;
+ #endif /* CONFIG_WPS_STRICT */
+   }
++
++
++  if (cred->auth_type & (WPS_AUTH_WPAPSK | WPS_AUTH_WPA2PSK) &&
++  (cred->key_len < 8 || has_ctrl_char(cred->key, cred->key_len))) {
++  wpa_printf(MSG_INFO, "WPS: Reject credential with invalid 
WPA/WPA2-Personal passphrase");
++  wpa_hexdump_ascii_key(MSG_INFO, "WPS: Network Key",
++cred->key, cred->key_len);
++  return -1;
++  }
++
+   return 0;
+ }
+ 
+-- 
+1.9.1
diff --git 
a/meta/recipes-connectivity/wpa-supplicant/wpa-supplicant/0002-Remove-newlines-from-wpa_supplicant-config-network-o.patch
 
b/meta/recipes-connectivity/wpa-supplicant/wpa-supplicant/0002-Remove-newlines-from-wpa_supplicant-config-network-o.patch
new file mode 100644
index 000..c8686a0
--- /dev/null
+++ 
b/meta/recipes-connectivity/wpa-supplicant/wpa-supplicant/0002-Remove-newlines-from-wpa_supplicant-config-network-o.patch
@@ -0,0 +1,83 @@
+From 0fe5a234240a108b294a87174ad197f6b5cb38e9 Mon Sep 17 00:00:00 2001
+From: Paul Stewart 
+Date: Thu, 3 Mar 2016 15:40:19 -0800
+Subject: [PATCH 2/2] Remove newlines from wpa_supplicant 

Re: [OE-core] [PATCH 1/1] gcc-sanitizers: Fix libtool library files

[Yuanjie Huang]

Thanks, commit message revised.

Best,
Yuanjie

On 09/20/2016 09:35 PM, Burton, Ross wrote:


On 20 September 2016 at 10:19, Yuanjie Huang 
> wrote:


Upstream-Status: Inappropriate [embedded specific]
(LOCAL REV; NOT UPSTREAM) -- sent to oe-core on 2016-09-20


You don't need upstream-status tags in commit messages, only patches 
that the recipe is applying.


Also please remove your internal tracking data from the commit message.

Ross


>From 6ceafbc3a69a0b87bcddf718050c6958baab7759 Mon Sep 17 00:00:00 2001
From: Yuanjie Huang 
Date: Sun, 18 Sep 2016 16:36:55 +0800
Subject: [PATCH V2] gcc-sanitizers: Fix libtool library files

Since libtool sysroot is not set when compiling sanitizers, the libtool
does no prefix the dependency path correctly. Fix it, so that programs
can link to sanitizer libraries without error.

This patch changes the depenedency_libs line in libasan.la and
libusan.la from
	dependency_libs=' -lpthread -ldl '/usr/lib'/libstdc++.la '/usr/lib'/libstdc++.la'
to
	dependency_libs=' -lpthread -ldl =/usr/lib/libstdc++.la =/usr/lib/libstdc++.la'

Signed-off-by: Yuanjie Huang 
---
 meta/recipes-devtools/gcc/gcc-sanitizers.inc | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/meta/recipes-devtools/gcc/gcc-sanitizers.inc b/meta/recipes-devtools/gcc/gcc-sanitizers.inc
index c987ccb..5fe5eaf 100644
--- a/meta/recipes-devtools/gcc/gcc-sanitizers.inc
+++ b/meta/recipes-devtools/gcc/gcc-sanitizers.inc
@@ -50,6 +50,8 @@ do_install () {
 rmdir --ignore-fail-on-non-empty -p ${D}${infodir}
 fi
 chown -R root:root ${D}
+# Fix broken libtool with stdc++, as sysroot is not set.
+find ${D} -name \*.la -exec sed -i "/^dependency_libs=/s@'/usr/lib'@=/usr/lib@g" {} \;
 }
 
 INHIBIT_DEFAULT_DEPS = "1"
-- 
1.9.1

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

Re: [OE-core] [PATCH 1/1] gcc-sanitizers: Fix libtool library files

[Yuanjie Huang]

On 09/21/2016 04:48 AM, Khem Raj wrote:

On Tue, Sep 20, 2016 at 2:19 AM, Yuanjie Huang
 wrote:

From: Yuanjie Huang 

Since libtool sysroot is not set when compiling sanitizers, the libtool
does no prefix the dependency path correctly. Fix it, so that programs
can link to sanitizer libraries without error.

This patch changes the depenedency_libs line in libasan.la and
libusan.la from
 dependency_libs=' -lpthread -ldl '/usr/lib'/libstdc++.la 
'/usr/lib'/libstdc++.la'
to
 dependency_libs=' -lpthread -ldl =/usr/lib/libstdc++.la 
=/usr/lib/libstdc++.la'

Upstream-Status: Inappropriate [embedded specific]
(LOCAL REV; NOT UPSTREAM) -- sent to oe-core on 2016-09-20

Signed-off-by: Yuanjie Huang 
---
  meta/recipes-devtools/gcc/gcc-sanitizers.inc | 2 ++
  1 file changed, 2 insertions(+)

diff --git a/meta/recipes-devtools/gcc/gcc-sanitizers.inc 
b/meta/recipes-devtools/gcc/gcc-sanitizers.inc
index c987ccb..5fe5eaf 100644
--- a/meta/recipes-devtools/gcc/gcc-sanitizers.inc
+++ b/meta/recipes-devtools/gcc/gcc-sanitizers.inc
@@ -50,6 +50,8 @@ do_install () {
  rmdir --ignore-fail-on-non-empty -p ${D}${infodir}
  fi
  chown -R root:root ${D}
+# Fix broken libtool with stdc++, as sysroot is not set.
+find ${D} -name \*.la -exec sed -i 
"/^dependency_libs=/s@'/usr/lib'@=/usr/lib@g" {} \;

what happens if you remove the .la files completely.
We have some user making use of these libraries directly, otherwise, 
cross gcc can link these sanitizer libraries with just -fsantizer flag 
without problem. Without .la files, his flow can not be libtoolized.


Best,
Yuanjie

  }

  INHIBIT_DEFAULT_DEPS = "1"
--
1.9.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

Re: [OE-core] [PATCH 1/1] rpm: make install with --nosignature and --nodigest work

[Hongxu Jia]

On 09/20/2016 11:00 PM, Burton, Ross wrote:


On 20 September 2016 at 09:15, Hongxu Jia > wrote:


-Upstream-Status: Submitted [Sent email to rpm-de...@rpm5.org
]
+Upstream-Status: Rejected [Sent email to rpm-de...@rpm5.org
]
+http://rpm5.org/community/rpm-devel/5655.html



Considering upstream has explicitly rejected this patch, why should we 
accept it?




From his reply, he will remove "SUPPORT_NOSIGNATURES" code in future:

Note that all the code marked with "SUPPORT_NOSIGNATURES" is targeted
for removal. RPM5 has been producing MANDATORY signed packages for
more than 5 years, so all packages produced by RPM5 SHOULD have
both verifiable signatures/pubkeys included for many years now.

Your alternative (of course) is to re-patch rpm to re-add --nosignatures as
you wish: I will be happy to send you the needed patch when I remove
all the SUPPORT_NOSIGNATURES code.


If we need to support --nosignatures, we have to re-patch rpm locally.
We could drop it after upstream removes "SUPPORT_NOSIGNATURES"
code.

//Hongxu


Ross



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

Re: [OE-core] [PATCH] perf: Fix to obey LD failure on host i686

[Andre McCurdy]

On Mon, Sep 19, 2016 at 11:00 AM, Christopher Larson
 wrote:
>
> On Mon, Sep 19, 2016 at 4:10 AM, sujith h  wrote:
>>
>> On Thu, Sep 8, 2016 at 12:36 PM, Andre McCurdy 
>> wrote:
>>>
>>> On Wed, Sep 7, 2016 at 11:51 PM, Sujith H  wrote:
>>> > From: Christopher Larson 
>>> >
>>> > When built on an i686 host for qemux86-64 without the
>>> > fix to obey LD and it fails:
>>> >
>>> > /scratch/dogwood/toolchains/x86_64/bin/i686-pc-linux-gnu-ld:
>>> > Relocatable linking with relocations from format elf64-x86-64
>>> >
>>> > (/scratch/dogwood/perf-ld-test/build/tmp/work/qemux86_64-mel-linux/perf/1.0-r9/perf-1.0/fs/fs.o)
>>> > to format elf32-i386
>>> > (/scratch/dogwood/perf-ld-test/build/tmp/work/qemux86_64-mel-linux/perf/1.0-r9/perf-1.0/fs/libapi-in.o)
>>> > is not supported
>>> >
>>> > This is because LD includes HOST_LD_ARCH, which contains TUNE_LDARGS,
>>> > which is -m elf32_x86_64 for x86_64. Without that, direct use of ld
>>> > will fail.
>>> >
>>> > Signed-off-by: Christopher Larson 
>>> > Signed-off-by: Sujith Haridasan 
>>> > ---
>>> >  meta/recipes-kernel/perf/perf.bb | 9 +
>>> >  1 file changed, 9 insertions(+)
>>> >
>>> > diff --git a/meta/recipes-kernel/perf/perf.bb
>>> > b/meta/recipes-kernel/perf/perf.bb
>>> > index 88e3a0a..85fe0ea 100644
>>> > --- a/meta/recipes-kernel/perf/perf.bb
>>> > +++ b/meta/recipes-kernel/perf/perf.bb
>>> > @@ -79,6 +79,7 @@ EXTRA_OEMAKE = '\
>>> >  ARCH=${ARCH} \
>>> >  CC="${CC}" \
>>> >  AR="${AR}" \
>>> > +LD="${LD}" \
>>> >  EXTRA_CFLAGS="-ldw" \
>>> >  perfexecdir=${libexecdir} \
>>> >  NO_GTK2=1 ${TUI_DEFINES} NO_DWARF=1 ${LIBUNWIND_DEFINES} \
>>> > @@ -98,6 +99,14 @@ EXTRA_OEMAKE += "\
>>> >  'infodir=${@os.path.relpath(infodir, prefix)}' \
>>> >  "
>>> >
>>> > +do_configure_prepend () {
>>> > +for makefile in "${S}/tools/perf/Makefile.perf" \
>>> > +"${S}/tools/lib/api/Makefile"; do
>>> > +if [ -e "$makefile" ]; then
>>> > +sed -i 's,LD = $(CROSS_COMPILE)ld,#LD,' "$makefile"
>>> > +fi
>>> > +done
>>> > +}
>>>
>>> Isn't passing LD via the Make command line enough to over-ride these
>>> definitions in the Makefiles?
>>
>> Unfortunately that didn't helped I believe. That's the reason, this patch
>> was created.
>
> The patch mirrored the handling of CC/AR, which also used sed at the time
> the append was created. If upstream removed the sed for those, then we can
> remove it for LD as well, presumably. I’d recommend actually testing that.

Brief testing suggests that commenting out LD in
${S}/tools/lib/api/Makefile is still required.

For clarity the new sed command should probably be added next to the
existing ones for CC and AR though, rather than on its own in a new
do_configure_prepend().

There is no "LD = ..." line to comment out in ${S}/tools/perf/Makefile.perf.

> --
> Christopher Larson
> kergoth at gmail dot com
> Founder - BitBake, OpenEmbedded, OpenZaurus
> Maintainer - Tslib
> Senior Software Engineer, Mentor Graphics
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] ltp: 20160126 -> 20160510

[Khem Raj]

On Sun, Sep 11, 2016 at 7:11 AM, Wang Xin
 wrote:
> 1) Upgrade ltp from 20160126 to 20160510.
> 2) Modify some patches, since the data has been changed.
> 0011-Rename-sigset-variable-to-sigset1.patch
> 0030-lib-Use-PTHREAD_MUTEX_RECURSIVE-in-place-of-PTHREAD_.patch
> 3) Delete some patches, since they are no use.
> 0001-ltp-Don-t-link-against-libfl.patch
> 0006-sendfile-Use-off64_t-instead-of-__off64_t.patch
> 0012-fsstress.c-Replace-__int64_t-with-int64_t.patch
> 0013-include-fcntl.h-for-getting-O_-definitions.patch
> 0014-hyperthreading-Include-sys-types.h-for-pid_t-definit.patch
> 0015-mincore01-Rename-PAGESIZE-to-pagesize.patch
> 0016-ustat-Change-header-from-ustat.h-to-sys-ustat.h.patch
> 0017-replace-sigval_t-with-union-sigval.patch
> 0019-tomoyo-Replace-canonicalize_file_name-with-realpath.patch
> 0032-regen.sh-Include-asm-unistd.h-explicitly.patch
>

Please test this on musl as well. Please backport the needed patches from
https://github.com/kraj/ltp/tree/oe/master

Some of these patches are merged upstream but new ones may be needed.

> Signed-off-by: Wang Xin 
> ---
>  .../0011-Rename-sigset-variable-to-sigset1.patch   | 60 
> +++---
>  ...READ_MUTEX_RECURSIVE-in-place-of-PTHREAD_.patch |  6 +--
>  .../ltp/{ltp_20160126.bb => ltp_20160510.bb}   | 12 +
>  3 files changed, 34 insertions(+), 44 deletions(-)
>  rename meta/recipes-extended/ltp/{ltp_20160126.bb => ltp_20160510.bb} (88%)
>
> diff --git 
> a/meta/recipes-extended/ltp/ltp/0011-Rename-sigset-variable-to-sigset1.patch 
> b/meta/recipes-extended/ltp/ltp/0011-Rename-sigset-variable-to-sigset1.patch
> index 945280c..6eace63 100644
> --- 
> a/meta/recipes-extended/ltp/ltp/0011-Rename-sigset-variable-to-sigset1.patch
> +++ 
> b/meta/recipes-extended/ltp/ltp/0011-Rename-sigset-variable-to-sigset1.patch
> @@ -20,8 +20,8 @@ index 7203e9e..fce87d6 100644
>   /**/
>
>   key_t key;
> --sigset_t sigset;
> -+sigset_t sigset1;
> +-sigset_t set;
> ++sigset_t set1;
>
>   #define  SIZE  16*1024
>
> @@ -29,12 +29,12 @@ index 7203e9e..fce87d6 100644
>
> key = (key_t) getpid();
>
> --  sigemptyset();
> --  sigaddset(, SIGUSR1);
> --  sigprocmask(SIG_BLOCK, , NULL);
> -+  sigemptyset();
> -+  sigaddset(, SIGUSR1);
> -+  sigprocmask(SIG_BLOCK, , NULL);
> +-  sigemptyset();
> +-  sigaddset(, SIGUSR1);
> +-  sigprocmask(SIG_BLOCK, , NULL);
> ++  sigemptyset();
> ++  sigaddset(, SIGUSR1);
> ++  sigprocmask(SIG_BLOCK, , NULL);
>
> pid = fork();
> switch (pid) {
> @@ -42,8 +42,8 @@ index 7203e9e..fce87d6 100644
> char *cp;
> int sig;
>
> --  sigwait(, );
> -+  sigwait(, );
> +-  sigwait(, );
> ++  sigwait(, );
> chld_pid = getpid();
>   /**/
>
> @@ -55,8 +55,8 @@ index a3c9ca3..77b0fc9 100644
>   /**/
>
>   key_t key;
> --sigset_t sigset;
> -+sigset_t sigset1;
> +-sigset_t set;
> ++sigset_t set1;
>
>   int child();
>   static int rm_shm(int);
> @@ -64,12 +64,12 @@ index a3c9ca3..77b0fc9 100644
>
> key = (key_t) getpid();
>
> --  sigemptyset();
> --  sigaddset(, SIGUSR1);
> --  sigprocmask(SIG_BLOCK, , NULL);
> -+  sigemptyset();
> -+  sigaddset(, SIGUSR1);
> -+  sigprocmask(SIG_BLOCK, , NULL);
> +-  sigemptyset();
> +-  sigaddset(, SIGUSR1);
> +-  sigprocmask(SIG_BLOCK, , NULL);
> ++  sigemptyset();
> ++  sigaddset(, SIGUSR1);
> ++  sigprocmask(SIG_BLOCK, , NULL);
>
> pid = fork();
> switch (pid) {
> @@ -77,8 +77,8 @@ index a3c9ca3..77b0fc9 100644
> char *cp;
> int sig;
>
> --  sigwait(, );
> -+  sigwait(, );
> +-  sigwait(, );
> ++  sigwait(, );
> chld_pid = getpid();
>
> if ((shmid = shmget(key, SIZE, 0)) < 0) {
> @@ -90,8 +90,8 @@ index 20fca52..6fb1d57 100644
>   int sig_catch = 0;/* variable to blocked/unblocked signals */
>
>   struct sigaction sa_new;  /* struct to hold signal info */
> --sigset_t sigset;  /* signal set to hold signal lists */
> -+sigset_t sigset1; /* signal set to hold signal lists */
> +-sigset_t set; /* signal set to hold signal lists */
> ++sigset_t set1;/* signal set to hold signal lists */
>   sigset_t sigset2;
>
>   int main(int ac, char **av)
> @@ -99,8 +99,8 @@ index 20fca52..6fb1d57 100644
>  * so that, signal will not be delivered to
>  * the test process.
>  */
> --  TEST(sigprocmask(SIG_BLOCK, , 0));
> -+  TEST(sigprocmask(SIG_BLOCK, , 0));
> +-  TEST(sigprocmask(SIG_BLOCK, , 0));
> ++  TEST(sigprocmask(SIG_BLOCK, , 0));
>
> /* Get the process id of test process */
> my_pid = getpid();
> @@ -108,8 

Re: [OE-core] [PATCH v2] gcc-configure: Enable initfini-array

[Khem Raj]

On Mon, Sep 19, 2016 at 10:16 AM, Saul Wold  wrote:
> This adds the correct support for initfini-array which replaces .init
> and .fini with .init-array and .fini-array.  There is no appreciable
> size difference with this change.
>
> The change is needed since configure will not correctly detect support
> when building cross-compilers.
>
> Signed-off-by: Haitao Huang 
> Signed-off-by: Saul Wold 
> ---
> v2: Enable for all Architectures

What is original motivation for this patch ? this change expects libc
to support init fini arrays
please test it on all supported libcs as well.

>
>  meta/recipes-devtools/gcc/gcc-configure-common.inc | 4 
>  1 file changed, 4 insertions(+)
>
> diff --git a/meta/recipes-devtools/gcc/gcc-configure-common.inc 
> b/meta/recipes-devtools/gcc/gcc-configure-common.inc
> index f4f76bd..b374c30 100644
> --- a/meta/recipes-devtools/gcc/gcc-configure-common.inc
> +++ b/meta/recipes-devtools/gcc/gcc-configure-common.inc
> @@ -44,6 +44,10 @@ EXTRA_OECONF = "\
>  ${@get_gcc_multiarch_setting(bb, d)} \
>  "
>
> +# Set this here since GCC configure won't auto-detect and enable
> +# initfini-arry when cross compiling.
> +EXTRA_OECONF_append = " --enable-initfini-array"
> +
>  export gcc_cv_collect2_libs = 'none required'
>  # We need to set gcc_cv_collect2_libs else there is cross-compilation badness
>  # in the config.log files (which might not get generated until do_compile
> --
> 2.5.0
>
> --
> ___
> 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

Re: [OE-core] [PATCH 1/1] gcc-sanitizers: Fix libtool library files

[Khem Raj]

On Tue, Sep 20, 2016 at 2:19 AM, Yuanjie Huang
 wrote:
> From: Yuanjie Huang 
>
> Since libtool sysroot is not set when compiling sanitizers, the libtool
> does no prefix the dependency path correctly. Fix it, so that programs
> can link to sanitizer libraries without error.
>
> This patch changes the depenedency_libs line in libasan.la and
> libusan.la from
> dependency_libs=' -lpthread -ldl '/usr/lib'/libstdc++.la 
> '/usr/lib'/libstdc++.la'
> to
> dependency_libs=' -lpthread -ldl =/usr/lib/libstdc++.la 
> =/usr/lib/libstdc++.la'
>
> Upstream-Status: Inappropriate [embedded specific]
> (LOCAL REV; NOT UPSTREAM) -- sent to oe-core on 2016-09-20
>
> Signed-off-by: Yuanjie Huang 
> ---
>  meta/recipes-devtools/gcc/gcc-sanitizers.inc | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/meta/recipes-devtools/gcc/gcc-sanitizers.inc 
> b/meta/recipes-devtools/gcc/gcc-sanitizers.inc
> index c987ccb..5fe5eaf 100644
> --- a/meta/recipes-devtools/gcc/gcc-sanitizers.inc
> +++ b/meta/recipes-devtools/gcc/gcc-sanitizers.inc
> @@ -50,6 +50,8 @@ do_install () {
>  rmdir --ignore-fail-on-non-empty -p ${D}${infodir}
>  fi
>  chown -R root:root ${D}
> +# Fix broken libtool with stdc++, as sysroot is not set.
> +find ${D} -name \*.la -exec sed -i 
> "/^dependency_libs=/s@'/usr/lib'@=/usr/lib@g" {} \;

what happens if you remove the .la files completely.

>  }
>
>  INHIBIT_DEFAULT_DEPS = "1"
> --
> 1.9.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

Re: [OE-core] [PATCH v2] libunwind: add aarch64 support

[Khem Raj]

On Tue, Sep 20, 2016 at 7:21 AM, Randy MacLeod
 wrote:
> On 2016-09-20 07:57 AM, Fathi Boudra wrote:
>>
>> Hi,
>>
>> On 20 September 2016 at 05:12, ChenQi > > wrote:
>>>
>>> On 09/26/2014 05:59 PM, Fathi Boudra wrote:


 * pass --enable-debug-frame on aarch64 architecture
>>>
>>>
>>>
>>> Hi Fathi,
>>>
>>> I'm now dealing with a problem related to libunwind support on aarch64.
>>> Could you please tell me why '--enable-debug-frame' is needed for
>>> aarch64?
>>
>>
>> libunwind needs to be configured with --enable-debug-frame to prevent a
>> linkage error.
>> Note: --enable-debug-frame is automatically selected on ARM32, not on
>> ARM64.
>>
>
> Thanks.
> We dropped the configuration flag and don't see any linking/linkage
> problems yet. Can you be more specific about the problems encountered?

This would enable .debug_frame instead of .eh_frame for unwinding.
AFAICT it was only
needed on arm ( 32bit) not sure you need this on aarch64

>
> Our goal is to make tcmalloc from gperftools work on ARM64.
>
> ../Randy
>
>
>>> Best Regards,
>>> Chen Qi
>>
>>
>> Cheers,
>> Fathi
>>
>>
>
>
> --
> # Randy MacLeod. SMTS, Linux, Wind River
> Direct: 613.963.1350 | 350 Terry Fox Drive, Suite 200, Ottawa, ON, Canada,
> K2K 2W5
> --
> ___
> 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

Re: [OE-core] [PATCH 1/1] rpm: make install with --nosignature and --nodigest work

[Mark Hatle]

On 9/20/16 10:00 AM, Burton, Ross wrote:
> 
> On 20 September 2016 at 09:15, Hongxu Jia  > wrote:
> 
> -Upstream-Status: Submitted [Sent email to rpm-de...@rpm5.org
> ]
> +Upstream-Status: Rejected [Sent email to rpm-de...@rpm5.org
> ]
> +http://rpm5.org/community/rpm-devel/5655.html
> 
> 
> 
> Considering upstream has explicitly rejected this patch, why should we accept 
> it?
> 
> Ross
> 
> 

I'm confused by what the patch is doing looking at it.

It sounds like from the description there is a bug that without the change,
packages with (intentionally) bad checksums and such are allowed to be 
installed.

The bug is caused by a previous patch that enabled nosignature, etc -- because
the comparisons turned out to be backwards.

So really nosignature, etc is already in place -- it's just not working 
properly?

What was rejected upstream is the use of nosignature in any context.  RPM5
maintainer believes it is unwise and unsafe to permit uses to install packages
that have failed basic validation.  (I tend to agree.)  Similarly, even being
able to run queries and other operations against them may be dangerous as well.

If fixing the problem is as simple as reverting the other change -- and that
doesn't cause other problems elsewhere...  I'd rather see that.

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

[OE-core] [PATCH 0/7] Jethro pull request #2

[Armin Kuster]

From: Armin Kuster 

please consider these changes for Jethro

Similar fixes for krogoth are in my staging branch

The following changes since commit 6f0350d1cbf5829bfbaa3a43227f8d564903743a:

  wget: Security fix CVE-2016-4971 (2016-09-17 22:33:07 -0700)

are available in the git repository at:

  git://git.openembedded.org/openembedded-core-contrib akuster/jethro-next
  
http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=akuster/jethro-next

Armin Kuster (7):
  qemu: Security Fix CVE-2016-3710
  qemu: Security Fix CVE-2016-3712
  qemu: Security fix CVE-2016-4439
  qemu: Security fix CVE-2016-6351
  qemu: Security fix for CVE-2016-4002
  qemu: Secuirty fix for CVE-2016-5403
  util-linux: Security fix for CVE-2016-5011

 .../util-linux/util-linux/CVE-2016-5011.patch  |  59 +
 .../util-linux/util-linux/CVE-2016-5011_p2.patch   |  91 ++
 meta/recipes-core/util-linux/util-linux_2.26.2.bb  |   2 +
 .../recipes-devtools/qemu/qemu/CVE-2016-3710.patch | 112 +
 .../qemu/qemu/CVE-2016-3712_p1.patch   |  73 
 .../qemu/qemu/CVE-2016-3712_p2.patch   | 132 +
 .../qemu/qemu/CVE-2016-3712_p3.patch   |  34 ++
 .../qemu/qemu/CVE-2016-3712_p4.patch   |  80 +
 .../recipes-devtools/qemu/qemu/CVE-2016-4002.patch |  39 ++
 .../recipes-devtools/qemu/qemu/CVE-2016-4439.patch |  46 +++
 .../recipes-devtools/qemu/qemu/CVE-2016-5403.patch |  67 +++
 .../qemu/qemu/CVE-2016-6351_p1.patch   |  75 
 .../qemu/qemu/CVE-2016-6351_p2.patch   |  60 ++
 meta/recipes-devtools/qemu/qemu_2.4.0.bb   |  10 ++
 14 files changed, 880 insertions(+)
 create mode 100644 meta/recipes-core/util-linux/util-linux/CVE-2016-5011.patch
 create mode 100644 
meta/recipes-core/util-linux/util-linux/CVE-2016-5011_p2.patch
 create mode 100644 meta/recipes-devtools/qemu/qemu/CVE-2016-3710.patch
 create mode 100644 meta/recipes-devtools/qemu/qemu/CVE-2016-3712_p1.patch
 create mode 100644 meta/recipes-devtools/qemu/qemu/CVE-2016-3712_p2.patch
 create mode 100644 meta/recipes-devtools/qemu/qemu/CVE-2016-3712_p3.patch
 create mode 100644 meta/recipes-devtools/qemu/qemu/CVE-2016-3712_p4.patch
 create mode 100644 meta/recipes-devtools/qemu/qemu/CVE-2016-4002.patch
 create mode 100644 meta/recipes-devtools/qemu/qemu/CVE-2016-4439.patch
 create mode 100644 meta/recipes-devtools/qemu/qemu/CVE-2016-5403.patch
 create mode 100644 meta/recipes-devtools/qemu/qemu/CVE-2016-6351_p1.patch
 create mode 100644 meta/recipes-devtools/qemu/qemu/CVE-2016-6351_p2.patch

-- 
2.7.4

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

[OE-core] [PATCH 1/3] linux-yocto/4.1: 4.1.32 content and configuration warning fixes

[Bruce Ashfield]

The LINUX_VERSION was previously updated to 4.1.32, but the
SRCREVs for the actual content were missed. This gets our actual
version and the PV back in sync.

We also update the meta data to fix configuration audit warnings
from the beaglebone builds.

Signed-off-by: Bruce Ashfield 

squash with 4.1

Signed-off-by: Bruce Ashfield 
---
 meta/recipes-kernel/linux/linux-yocto-rt_4.1.bb   |  4 ++--
 meta/recipes-kernel/linux/linux-yocto-tiny_4.1.bb |  4 ++--
 meta/recipes-kernel/linux/linux-yocto_4.1.bb  | 18 +-
 3 files changed, 13 insertions(+), 13 deletions(-)

diff --git a/meta/recipes-kernel/linux/linux-yocto-rt_4.1.bb 
b/meta/recipes-kernel/linux/linux-yocto-rt_4.1.bb
index 4308a07a9765..1f38a54bf551 100644
--- a/meta/recipes-kernel/linux/linux-yocto-rt_4.1.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-rt_4.1.bb
@@ -11,8 +11,8 @@ python () {
 raise bb.parse.SkipPackage("Set PREFERRED_PROVIDER_virtual/kernel to 
linux-yocto-rt to enable it")
 }
 
-SRCREV_machine ?= "ee83bffe0f76032fe0a0b7fde436f0f596101df2"
-SRCREV_meta ?= "b30b6b9ef215433b28e8966c73ebb6b98a7f4d1f"
+SRCREV_machine ?= "91821a6c3a54fabf964037dd478944a8f3597f88"
+SRCREV_meta ?= "19cafe114e7d35e6202afa1079b32ce600646660"
 
 SRC_URI = 
"git://git.yoctoproject.org/linux-yocto-4.1.git;branch=${KBRANCH};name=machine \

git://git.yoctoproject.org/yocto-kernel-cache;type=kmeta;name=meta;branch=yocto-4.1;destsuffix=${KMETA}"
diff --git a/meta/recipes-kernel/linux/linux-yocto-tiny_4.1.bb 
b/meta/recipes-kernel/linux/linux-yocto-tiny_4.1.bb
index 2294a3db87da..5058954a814a 100644
--- a/meta/recipes-kernel/linux/linux-yocto-tiny_4.1.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-tiny_4.1.bb
@@ -9,8 +9,8 @@ LINUX_VERSION ?= "4.1.32"
 KMETA = "kernel-meta"
 KCONF_BSP_AUDIT_LEVEL = "2"
 
-SRCREV_machine ?= "93b1a6cee7d4a4437a1c0edf3e54ffe78edb4462"
-SRCREV_meta ?= "b30b6b9ef215433b28e8966c73ebb6b98a7f4d1f"
+SRCREV_machine ?= "a6b3a8cc120640bf5e528c8558ce060675757fc1"
+SRCREV_meta ?= "19cafe114e7d35e6202afa1079b32ce600646660"
 
 PV = "${LINUX_VERSION}+git${SRCPV}"
 
diff --git a/meta/recipes-kernel/linux/linux-yocto_4.1.bb 
b/meta/recipes-kernel/linux/linux-yocto_4.1.bb
index f4006b74d096..249209d6495f 100644
--- a/meta/recipes-kernel/linux/linux-yocto_4.1.bb
+++ b/meta/recipes-kernel/linux/linux-yocto_4.1.bb
@@ -11,15 +11,15 @@ KBRANCH_qemux86  ?= "standard/base"
 KBRANCH_qemux86-64 ?= "standard/base"
 KBRANCH_qemumips64 ?= "standard/mti-malta64"
 
-SRCREV_machine_qemuarm ?= "4db58705727e27bea8ccf805bd5c7d04d2d029ed"
-SRCREV_machine_qemuarm64 ?= "93b1a6cee7d4a4437a1c0edf3e54ffe78edb4462"
-SRCREV_machine_qemumips ?= "d6237b3b244b894d4b3479ecf37acef041416dfa"
-SRCREV_machine_qemuppc ?= "8520e65497ae10e14c38c76920a3457dc64349bf"
-SRCREV_machine_qemux86 ?= "93b1a6cee7d4a4437a1c0edf3e54ffe78edb4462"
-SRCREV_machine_qemux86-64 ?= "93b1a6cee7d4a4437a1c0edf3e54ffe78edb4462"
-SRCREV_machine_qemumips64 ?= "d0524e144cd15a3c0edf768f68400968a4477cbe"
-SRCREV_machine ?= "93b1a6cee7d4a4437a1c0edf3e54ffe78edb4462"
-SRCREV_meta ?= "b30b6b9ef215433b28e8966c73ebb6b98a7f4d1f"
+SRCREV_machine_qemuarm ?= "a2fde8c9a8b709574b36931f728fb78617892d98"
+SRCREV_machine_qemuarm64 ?= "a6b3a8cc120640bf5e528c8558ce060675757fc1"
+SRCREV_machine_qemumips ?= "33efda07565f45c576671358e75b39dc6a069cbf"
+SRCREV_machine_qemuppc ?= "96b9a39490bc348b36d0de13397a086e66a4b1cb"
+SRCREV_machine_qemux86 ?= "a6b3a8cc120640bf5e528c8558ce060675757fc1"
+SRCREV_machine_qemux86-64 ?= "a6b3a8cc120640bf5e528c8558ce060675757fc1"
+SRCREV_machine_qemumips64 ?= "a46e08c52a6764b0e54f4dbbdfaa3050a379ac4a"
+SRCREV_machine ?= "a6b3a8cc120640bf5e528c8558ce060675757fc1"
+SRCREV_meta ?= "19cafe114e7d35e6202afa1079b32ce600646660"
 
 SRC_URI = 
"git://git.yoctoproject.org/linux-yocto-4.1.git;name=machine;branch=${KBRANCH}; 
\

git://git.yoctoproject.org/yocto-kernel-cache;type=kmeta;name=meta;branch=yocto-4.1;destsuffix=${KMETA}"
-- 
2.5.0

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

[OE-core] [PATCH 2/3] linux-yocto/4.8: integrate 4.8-rc7

[Bruce Ashfield]

Updating to the latest release candidate.

Signed-off-by: Bruce Ashfield 
---
 meta/recipes-kernel/linux/linux-yocto-rt_4.8.bb   |  6 +++---
 meta/recipes-kernel/linux/linux-yocto-tiny_4.8.bb |  6 +++---
 meta/recipes-kernel/linux/linux-yocto_4.8.bb  | 20 ++--
 3 files changed, 16 insertions(+), 16 deletions(-)

diff --git a/meta/recipes-kernel/linux/linux-yocto-rt_4.8.bb 
b/meta/recipes-kernel/linux/linux-yocto-rt_4.8.bb
index 10dd349eb002..17aae6b2c7bd 100644
--- a/meta/recipes-kernel/linux/linux-yocto-rt_4.8.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-rt_4.8.bb
@@ -11,13 +11,13 @@ python () {
 raise bb.parse.SkipPackage("Set PREFERRED_PROVIDER_virtual/kernel to 
linux-yocto-rt to enable it")
 }
 
-SRCREV_machine ?= "e6e0dea72e605a070373bd52c6c2637202ce4b38"
-SRCREV_meta ?= "25fb74eaaef249519f25e243e7f9bf0cab0e1781"
+SRCREV_machine ?= "cde1a7d656b7fdd96f82f619e4251965a4e96489"
+SRCREV_meta ?= "a9240b538ce4de29ff1fc7eaf328450c51ab9e80"
 
 SRC_URI = 
"git://git.yoctoproject.org/linux-yocto-4.8.git;branch=${KBRANCH};name=machine \

git://git.yoctoproject.org/yocto-kernel-cache;type=kmeta;name=meta;branch=yocto-4.8;destsuffix=${KMETA}"
 
-LINUX_VERSION ?= "4.8-rc6"
+LINUX_VERSION ?= "4.8-rc7"
 
 PV = "${LINUX_VERSION}+git${SRCPV}"
 
diff --git a/meta/recipes-kernel/linux/linux-yocto-tiny_4.8.bb 
b/meta/recipes-kernel/linux/linux-yocto-tiny_4.8.bb
index 50a54a1a48ea..5df5e0c3c0b9 100644
--- a/meta/recipes-kernel/linux/linux-yocto-tiny_4.8.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-tiny_4.8.bb
@@ -4,13 +4,13 @@ KCONFIG_MODE = "--allnoconfig"
 
 require recipes-kernel/linux/linux-yocto.inc
 
-LINUX_VERSION ?= "4.8-rc6"
+LINUX_VERSION ?= "4.8-rc7"
 
 KMETA = "kernel-meta"
 KCONF_BSP_AUDIT_LEVEL = "2"
 
-SRCREV_machine ?= "e6e0dea72e605a070373bd52c6c2637202ce4b38"
-SRCREV_meta ?= "25fb74eaaef249519f25e243e7f9bf0cab0e1781"
+SRCREV_machine ?= "eb9c19c72d40a4bb8a6a3b7b949e41e5c31c0d94"
+SRCREV_meta ?= "fb4159467f0f46f788b59f0aff31e3fcd757d00d"
 
 PV = "${LINUX_VERSION}+git${SRCPV}"
 
diff --git a/meta/recipes-kernel/linux/linux-yocto_4.8.bb 
b/meta/recipes-kernel/linux/linux-yocto_4.8.bb
index f4f4bfe855ec..2e0dbfa34625 100644
--- a/meta/recipes-kernel/linux/linux-yocto_4.8.bb
+++ b/meta/recipes-kernel/linux/linux-yocto_4.8.bb
@@ -11,20 +11,20 @@ KBRANCH_qemux86  ?= "standard/base"
 KBRANCH_qemux86-64 ?= "standard/base"
 KBRANCH_qemumips64 ?= "standard/mti-malta64"
 
-SRCREV_machine_qemuarm ?= "29b1dac023fac237c408620aaa79a60a611dc2df"
-SRCREV_machine_qemuarm64 ?= "e6e0dea72e605a070373bd52c6c2637202ce4b38"
-SRCREV_machine_qemumips ?= "edb3f19ae13818cd5af56f21566e843c975ba897"
-SRCREV_machine_qemuppc ?= "e6e0dea72e605a070373bd52c6c2637202ce4b38"
-SRCREV_machine_qemux86 ?= "e6e0dea72e605a070373bd52c6c2637202ce4b38"
-SRCREV_machine_qemux86-64 ?= "e6e0dea72e605a070373bd52c6c2637202ce4b38"
-SRCREV_machine_qemumips64 ?= "c583570fc64c2e01e3cf51edd0e732ee6789c9ef"
-SRCREV_machine ?= "e6e0dea72e605a070373bd52c6c2637202ce4b38"
-SRCREV_meta ?= "25fb74eaaef249519f25e243e7f9bf0cab0e1781"
+SRCREV_machine_qemuarm ?= "ba792fae8c979ae4ecaae5e8403b150863173509"
+SRCREV_machine_qemuarm64 ?= "eb9c19c72d40a4bb8a6a3b7b949e41e5c31c0d94"
+SRCREV_machine_qemumips ?= "19b41be93a8fefc65ef4c1c1ab3e8b2d815de93d"
+SRCREV_machine_qemuppc ?= "eb9c19c72d40a4bb8a6a3b7b949e41e5c31c0d94"
+SRCREV_machine_qemux86 ?= "eb9c19c72d40a4bb8a6a3b7b949e41e5c31c0d94"
+SRCREV_machine_qemux86-64 ?= "eb9c19c72d40a4bb8a6a3b7b949e41e5c31c0d94"
+SRCREV_machine_qemumips64 ?= "c6e9e8d1caacea5deca7e41b47fd6076a747b6fa"
+SRCREV_machine ?= "eb9c19c72d40a4bb8a6a3b7b949e41e5c31c0d94"
+SRCREV_meta ?= "fb4159467f0f46f788b59f0aff31e3fcd757d00d"
 
 SRC_URI = 
"git://git.yoctoproject.org/linux-yocto-4.8.git;name=machine;branch=${KBRANCH}; 
\

git://git.yoctoproject.org/yocto-kernel-cache;type=kmeta;name=meta;branch=yocto-4.8;destsuffix=${KMETA}"
 
-LINUX_VERSION ?= "4.8-rc6"
+LINUX_VERSION ?= "4.8-rc7"
 
 PV = "${LINUX_VERSION}+git${SRCPV}"
 
-- 
2.5.0

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

[OE-core] [PATCH 3/3] linux-yocto/4.8: introduce preempt-rt

[Bruce Ashfield]

Paul Gortmaker has made the preempt-rt patch available for the
4.8 kernel.

This commit merges his queue to standard/preempt-rt/rebase, which
will be kept up to date with a clean history, and it also makes
it available in standard/preempt-rt/base, which will be kept fast
forward for board support.

Signed-off-by: Bruce Ashfield 
---
 meta/recipes-kernel/linux/linux-yocto-rt_4.8.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-kernel/linux/linux-yocto-rt_4.8.bb 
b/meta/recipes-kernel/linux/linux-yocto-rt_4.8.bb
index 17aae6b2c7bd..ab5b0bdd1a00 100644
--- a/meta/recipes-kernel/linux/linux-yocto-rt_4.8.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-rt_4.8.bb
@@ -11,7 +11,7 @@ python () {
 raise bb.parse.SkipPackage("Set PREFERRED_PROVIDER_virtual/kernel to 
linux-yocto-rt to enable it")
 }
 
-SRCREV_machine ?= "cde1a7d656b7fdd96f82f619e4251965a4e96489"
+SRCREV_machine ?= "fcd201c964c1092e8cdc39be4ba86fb9248d7aa7"
 SRCREV_meta ?= "a9240b538ce4de29ff1fc7eaf328450c51ab9e80"
 
 SRC_URI = 
"git://git.yoctoproject.org/linux-yocto-4.8.git;branch=${KBRANCH};name=machine \
-- 
2.5.0

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

Re: [OE-core] [OE-Core][Patch v2] arch-mips: Restructure mips64 and add mips64r2

[Zubair Lutfullah Kakakhel]

Hi,

On 09/20/2016 03:51 PM, Mark Hatle wrote:

On 9/20/16 9:07 AM, Zubair Lutfullah Kakakhel wrote:

Hi,

On 09/20/2016 02:08 PM, Mark Hatle wrote:

On 9/20/16 5:33 AM, Zubair Lutfullah Kakakhel wrote:

The current file structure felt slightly unsuitable for adding
MIPS64r2. So I restructured it slightly and added MIPS64r2
support

Signed-off-by: Zubair Lutfullah Kakakhel 

---
V1 -> V2
Fixed a subtle bug in the include files for tune-mips64.inc which
resulted in a build failure for multi-lib configuration.


(Sorry, I didn't see V1.)

Can you explain why you moved the items out of arch-mips.inc?

Generally we want the arch-*.inc file to set a base set of components that the
optimized tunes can use.  It most case we define all of the core architecture
'features' and basic tunes in the arch files, and then add specific processor
optimizations in the arch-*.inc files.


I struggled a bit with drawing the line about where the basic tunes were and 
where
the rest of them go.

The previous structure was like so.

include/mips/arch-mips.inc had the following tunes : "mips mips64-n32 mips64 
mipsel
mips64el-n32 mips64el mips-nf mips64-nf-n32 mips64-nf mipsel-nf mips64el-nf-n32 
mips64el-nf"


Most other architectures are divided into a 32-bit and a 64-bit base tune.. so
it ends up something like:

mips/arch-mips.inc:
define: mips mipsel mips-nf mipsel-nf

mips/arch-mips64.inc:
include mips/arch-mips.inc

define: mips64-n32 mips64 mips64el-n32 mips64el mips64-nf-n32 mips64-nf
mips64el-nf-n32 mips64el-nf

tune-mips32r2.inc:
include mips/arch-mips.inc

define: (mips32r2 extensions)

tune-mips64r2.inc:
include mips/arch-mips64.inc

define: (mips64r2 extensions)


but if I remember right, there was a problem.  The 64-bit people wanted to use
the 32r2 version.  So if the include becomes:

include tune-mips32r2.inc (which includes arch-mips.inc)
include mips/arch-mips64.inc (which includes arch-mips.inc)

and now you run into the same thing being included two -- which you are not
supposed to do in OE..  So I believe this is why they were merged into a single
'arch-mips'.



Which is a mix of 32/64 bit.

Then
include/tune-mips32.inc defined "mips32 mips32el mips32-nf mips32el-nf"
include/tune-mips32r2.inc defined "mips32r2 mips32r2el mips32r2-nf 
mips32r2el-nf"

include/tune-mips64.inc just had a require include/tune-mips32r2.inc which
includes the base which basically has the actual mips64 tunes.

With this restructure patch.

include/mips/arch-mips.inc defines no tunes.


The arch should define a basic set of tunes that work on all mips architectures
(within reason)


include/tune-mips32.inc defines mips and mips32
include/tune-mips32r2.inc defines mips32r2
include/tune-mips64.inc defines mips64
include/tune-mips64r2.inc defines mips64r2

I could leave the existing layout as is and only add 64r2 as a separate patch.
But as I was poking around here, I tried to improve things a bit.

Any recommendation regarding which way would be preferred?


As long as the tunes remain, I'm fine.. but changing which files the base ones
are in can break BSPs developed elsewhere.  This is the biggest concern I have.


I agree restructure can potentially break existing work out there.
I'll send v3 which only adds 64r2 support and doesn't restructure anything.

Thanks
ZubairLK





Also I see 'mips64*-o32' defined.  I did not realize this was a valid
configuration.  In the past o32 could only be compiled with mips/mips32*
instructions.

+TUNE_FEATURES_tune-mips64-nf-n32 = "n32 bigendian"
+BASE_LIB_tune-mips64-nf-n32 = "lib32"
+MIPSPKGSFX_VARIANT_tune-mips64-nf-n32 = "${TUNE_ARCH}"
+PACKAGE_EXTRA_ARCHS_tune-mips64-nf-n32 = "mips64-nf-n32"

+TUNE_FEATURES_tune-mips64el-nf-o32 = "o32"
+BASE_LIB_tune-mips64el-nf-o32 = "lib32"
+MIPSPKGSFX_VARIANT_tune-mips64el-nf-o32 = "${TUNE_ARCH}"
+PACKAGE_EXTRA_ARCHS_tune-mips64el-nf-o32 = "mips64el-nf-o32"

Also o32 and n32 are currently defined to use the same lib directory.  This is
incorrect.  Per long time conventions, o32 belongs in 'lib', and n32 belongs in
'lib32'.  (n64 in lib64)

So at a minimum the directory name of o32 needs to be fixed.


Thanks for pointing this out. I'll fix this in v3.

Regards,
ZubairLK




---
 meta/conf/machine/include/mips/arch-mips.inc | 60 
 meta/conf/machine/include/tune-mips32.inc| 22 +++-
 meta/conf/machine/include/tune-mips64.inc| 78 ++
 meta/conf/machine/include/tune-mips64r2.inc  | 84 
 4 files changed, 183 insertions(+), 61 deletions(-)
 create mode 100644 meta/conf/machine/include/tune-mips64r2.inc

diff --git a/meta/conf/machine/include/mips/arch-mips.inc 
b/meta/conf/machine/include/mips/arch-mips.inc
index d3e83d1..6be84be 100644
--- a/meta/conf/machine/include/mips/arch-mips.inc
+++ b/meta/conf/machine/include/mips/arch-mips.inc
@@ -42,64 +42,4 @@ MIPSPKGSFX_ABI = "${@bb.utils.contains('TUNE_FEATURES', 'n32', 
'-n32', '', d)}"
 TUNE_ARCH = 

[OE-core] [PATCH 0/3] linux-yocto: consolidated pull request

[Bruce Ashfield]

Hi all,

Here is the latest update of content for the 4.8 kernel, it contains:

 - 4.8 -rc7
 - yaffs2 fixes from Kevin Hao
 - aufs is available
 - configuration warning fixes
 - preempt-rt

I've also included a fixup of the 4.1.32 and configuration warning fixes
for that tree.

Full disclosure: there are changes floating around for 4.1, 4.4, 4.8 for
both the core tree, the hardware reference boards and for the kernel
meta data.

I smoke tested what I could, and boot tested 4.8 and 4.1 to make sure they
were sane. But there are a lot of moving parts here, so the autobuilder will
be the final say if I managed to keep everything straight (while getting it
all done in less than a day).

Cheers,

Bruce

The following changes since commit 49a7839e602eac2c43415d9c8f17ad8315fd1da5:

  build-appliance-image: Create image in correct location (2016-09-19 08:58:10 
+0100)

are available in the git repository at:

  git://git.pokylinux.org/poky-contrib zedd/kernel
  http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=zedd/kernel

Bruce Ashfield (3):
  linux-yocto/4.1: 4.1.32 content and configuration warning fixes
  linux-yocto/4.8: integrate 4.8-rc7
  linux-yocto/4.8: introduce preempt-rt

 meta/recipes-kernel/linux/linux-yocto-rt_4.1.bb   |  4 ++--
 meta/recipes-kernel/linux/linux-yocto-rt_4.8.bb   |  6 +++---
 meta/recipes-kernel/linux/linux-yocto-tiny_4.1.bb |  4 ++--
 meta/recipes-kernel/linux/linux-yocto-tiny_4.8.bb |  6 +++---
 meta/recipes-kernel/linux/linux-yocto_4.1.bb  | 18 +-
 meta/recipes-kernel/linux/linux-yocto_4.8.bb  | 20 ++--
 6 files changed, 29 insertions(+), 29 deletions(-)

-- 
2.5.0

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

Re: [OE-core] [PATCH 1/1] rpm: make install with --nosignature and --nodigest work

[Burton, Ross]

On 20 September 2016 at 09:15, Hongxu Jia  wrote:

> -Upstream-Status: Submitted [Sent email to rpm-de...@rpm5.org]
> +Upstream-Status: Rejected [Sent email to rpm-de...@rpm5.org]
> +http://rpm5.org/community/rpm-devel/5655.html
>

Considering upstream has explicitly rejected this patch, why should we
accept it?

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

[OE-core] [PATCH] populate_sdk_base: fix support for changing SDKMACHINE settings

[Joshua Lock]

Include SDKMACHINE in the tasks stamp information and the name of
the sstate-inputdirs so that changing SDKMACHINE doesn't result in
valid output of the task being deleted when SDKMACHINE is changed.

Without this patch changing SDKMACHINE and building an SDK resulted
in toolchain installers for other  SDKMACHINE's being deleted from
the deploy directoy.

[YOCTO #10275]

Signed-off-by: Joshua Lock 
---
 meta/classes/populate_sdk_base.bbclass | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/meta/classes/populate_sdk_base.bbclass 
b/meta/classes/populate_sdk_base.bbclass
index 6fe0b37..fc4ee8d 100644
--- a/meta/classes/populate_sdk_base.bbclass
+++ b/meta/classes/populate_sdk_base.bbclass
@@ -26,7 +26,7 @@ SDK_DIR = "${WORKDIR}/sdk"
 SDK_OUTPUT = "${SDK_DIR}/image"
 SDK_DEPLOY = "${DEPLOY_DIR}/sdk"
 
-SDKDEPLOYDIR = "${WORKDIR}/deploy-${PN}-populate-sdk"
+SDKDEPLOYDIR = "${WORKDIR}/${SDKMACHINE}-deploy-${PN}-populate-sdk"
 
 B_task-populate-sdk = "${SDK_DIR}"
 
@@ -125,7 +125,7 @@ SSTATE_SKIP_CREATION_task-populate-sdk = '1'
 do_populate_sdk[cleandirs] = "${SDKDEPLOYDIR}"
 do_populate_sdk[sstate-inputdirs] = "${SDKDEPLOYDIR}"
 do_populate_sdk[sstate-outputdirs] = "${SDK_DEPLOY}"
-do_populate_sdk[stamp-extra-info] = "${MACHINE}"
+do_populate_sdk[stamp-extra-info] = "${MACHINE} ${SDKMACHINE}"
 
 fakeroot create_sdk_files() {
cp ${COREBASE}/scripts/relocate_sdk.py ${SDK_OUTPUT}/${SDKPATH}/
-- 
2.7.4

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

Re: [OE-core] [OE-Core][Patch v2] arch-mips: Restructure mips64 and add mips64r2

[Mark Hatle]

On 9/20/16 9:07 AM, Zubair Lutfullah Kakakhel wrote:
> Hi,
> 
> On 09/20/2016 02:08 PM, Mark Hatle wrote:
>> On 9/20/16 5:33 AM, Zubair Lutfullah Kakakhel wrote:
>>> The current file structure felt slightly unsuitable for adding
>>> MIPS64r2. So I restructured it slightly and added MIPS64r2
>>> support
>>>
>>> Signed-off-by: Zubair Lutfullah Kakakhel 
>>>
>>> ---
>>> V1 -> V2
>>> Fixed a subtle bug in the include files for tune-mips64.inc which
>>> resulted in a build failure for multi-lib configuration.
>>
>> (Sorry, I didn't see V1.)
>>
>> Can you explain why you moved the items out of arch-mips.inc?
>>
>> Generally we want the arch-*.inc file to set a base set of components that 
>> the
>> optimized tunes can use.  It most case we define all of the core architecture
>> 'features' and basic tunes in the arch files, and then add specific processor
>> optimizations in the arch-*.inc files.
> 
> I struggled a bit with drawing the line about where the basic tunes were and 
> where
> the rest of them go.
> 
> The previous structure was like so.
> 
> include/mips/arch-mips.inc had the following tunes : "mips mips64-n32 mips64 
> mipsel
> mips64el-n32 mips64el mips-nf mips64-nf-n32 mips64-nf mipsel-nf 
> mips64el-nf-n32 mips64el-nf"

Most other architectures are divided into a 32-bit and a 64-bit base tune.. so
it ends up something like:

mips/arch-mips.inc:
define: mips mipsel mips-nf mipsel-nf

mips/arch-mips64.inc:
include mips/arch-mips.inc

define: mips64-n32 mips64 mips64el-n32 mips64el mips64-nf-n32 mips64-nf
mips64el-nf-n32 mips64el-nf

tune-mips32r2.inc:
include mips/arch-mips.inc

define: (mips32r2 extensions)

tune-mips64r2.inc:
include mips/arch-mips64.inc

define: (mips64r2 extensions)


but if I remember right, there was a problem.  The 64-bit people wanted to use
the 32r2 version.  So if the include becomes:

include tune-mips32r2.inc (which includes arch-mips.inc)
include mips/arch-mips64.inc (which includes arch-mips.inc)

and now you run into the same thing being included two -- which you are not
supposed to do in OE..  So I believe this is why they were merged into a single
'arch-mips'.

> 
> Which is a mix of 32/64 bit.
> 
> Then
> include/tune-mips32.inc defined "mips32 mips32el mips32-nf mips32el-nf"
> include/tune-mips32r2.inc defined "mips32r2 mips32r2el mips32r2-nf 
> mips32r2el-nf"
> 
> include/tune-mips64.inc just had a require include/tune-mips32r2.inc which
> includes the base which basically has the actual mips64 tunes.
> 
> With this restructure patch.
> 
> include/mips/arch-mips.inc defines no tunes.

The arch should define a basic set of tunes that work on all mips architectures
(within reason)

> include/tune-mips32.inc defines mips and mips32
> include/tune-mips32r2.inc defines mips32r2
> include/tune-mips64.inc defines mips64
> include/tune-mips64r2.inc defines mips64r2
> 
> I could leave the existing layout as is and only add 64r2 as a separate patch.
> But as I was poking around here, I tried to improve things a bit.
> 
> Any recommendation regarding which way would be preferred?

As long as the tunes remain, I'm fine.. but changing which files the base ones
are in can break BSPs developed elsewhere.  This is the biggest concern I have.

>>
>> Also I see 'mips64*-o32' defined.  I did not realize this was a valid
>> configuration.  In the past o32 could only be compiled with mips/mips32*
>> instructions.
>>
>> +TUNE_FEATURES_tune-mips64-nf-n32 = "n32 bigendian"
>> +BASE_LIB_tune-mips64-nf-n32 = "lib32"
>> +MIPSPKGSFX_VARIANT_tune-mips64-nf-n32 = "${TUNE_ARCH}"
>> +PACKAGE_EXTRA_ARCHS_tune-mips64-nf-n32 = "mips64-nf-n32"
>>
>> +TUNE_FEATURES_tune-mips64el-nf-o32 = "o32"
>> +BASE_LIB_tune-mips64el-nf-o32 = "lib32"
>> +MIPSPKGSFX_VARIANT_tune-mips64el-nf-o32 = "${TUNE_ARCH}"
>> +PACKAGE_EXTRA_ARCHS_tune-mips64el-nf-o32 = "mips64el-nf-o32"
>>
>> Also o32 and n32 are currently defined to use the same lib directory.  This 
>> is
>> incorrect.  Per long time conventions, o32 belongs in 'lib', and n32 belongs 
>> in
>> 'lib32'.  (n64 in lib64)
>>
>> So at a minimum the directory name of o32 needs to be fixed.
> 
> Thanks for pointing this out. I'll fix this in v3.
> 
> Regards,
> ZubairLK
> 
>>
>>> ---
>>>  meta/conf/machine/include/mips/arch-mips.inc | 60 
>>>  meta/conf/machine/include/tune-mips32.inc| 22 +++-
>>>  meta/conf/machine/include/tune-mips64.inc| 78 
>>> ++
>>>  meta/conf/machine/include/tune-mips64r2.inc  | 84 
>>> 
>>>  4 files changed, 183 insertions(+), 61 deletions(-)
>>>  create mode 100644 meta/conf/machine/include/tune-mips64r2.inc
>>>
>>> diff --git a/meta/conf/machine/include/mips/arch-mips.inc 
>>> b/meta/conf/machine/include/mips/arch-mips.inc
>>> index d3e83d1..6be84be 100644
>>> --- a/meta/conf/machine/include/mips/arch-mips.inc
>>> +++ b/meta/conf/machine/include/mips/arch-mips.inc
>>> @@ -42,64 +42,4 @@ MIPSPKGSFX_ABI = 

Re: [OE-core] [PATCH v2] libunwind: add aarch64 support

[Randy MacLeod]

On 2016-09-20 07:57 AM, Fathi Boudra wrote:

Hi,

On 20 September 2016 at 05:12, ChenQi > wrote:

On 09/26/2014 05:59 PM, Fathi Boudra wrote:


* pass --enable-debug-frame on aarch64 architecture



Hi Fathi,

I'm now dealing with a problem related to libunwind support on aarch64.
Could you please tell me why '--enable-debug-frame' is needed for aarch64?


libunwind needs to be configured with --enable-debug-frame to prevent a
linkage error.
Note: --enable-debug-frame is automatically selected on ARM32, not on ARM64.



Thanks.
We dropped the configuration flag and don't see any linking/linkage
problems yet. Can you be more specific about the problems encountered?

Our goal is to make tcmalloc from gperftools work on ARM64.

../Randy


Best Regards,
Chen Qi


Cheers,
Fathi





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

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

Re: [OE-core] [OE-Core][Patch v2] arch-mips: Restructure mips64 and add mips64r2

[Zubair Lutfullah Kakakhel]

Hi,

On 09/20/2016 02:08 PM, Mark Hatle wrote:

On 9/20/16 5:33 AM, Zubair Lutfullah Kakakhel wrote:

The current file structure felt slightly unsuitable for adding
MIPS64r2. So I restructured it slightly and added MIPS64r2
support

Signed-off-by: Zubair Lutfullah Kakakhel 

---
V1 -> V2
Fixed a subtle bug in the include files for tune-mips64.inc which
resulted in a build failure for multi-lib configuration.


(Sorry, I didn't see V1.)

Can you explain why you moved the items out of arch-mips.inc?

Generally we want the arch-*.inc file to set a base set of components that the
optimized tunes can use.  It most case we define all of the core architecture
'features' and basic tunes in the arch files, and then add specific processor
optimizations in the arch-*.inc files.


I struggled a bit with drawing the line about where the basic tunes were and 
where
the rest of them go.

The previous structure was like so.

include/mips/arch-mips.inc had the following tunes : "mips mips64-n32 mips64 
mipsel
mips64el-n32 mips64el mips-nf mips64-nf-n32 mips64-nf mipsel-nf mips64el-nf-n32 
mips64el-nf"

Which is a mix of 32/64 bit.

Then
include/tune-mips32.inc defined "mips32 mips32el mips32-nf mips32el-nf"
include/tune-mips32r2.inc defined "mips32r2 mips32r2el mips32r2-nf 
mips32r2el-nf"

include/tune-mips64.inc just had a require include/tune-mips32r2.inc which
includes the base which basically has the actual mips64 tunes.

With this restructure patch.

include/mips/arch-mips.inc defines no tunes.
include/tune-mips32.inc defines mips and mips32
include/tune-mips32r2.inc defines mips32r2
include/tune-mips64.inc defines mips64
include/tune-mips64r2.inc defines mips64r2

I could leave the existing layout as is and only add 64r2 as a separate patch.
But as I was poking around here, I tried to improve things a bit.

Any recommendation regarding which way would be preferred?



Also I see 'mips64*-o32' defined.  I did not realize this was a valid
configuration.  In the past o32 could only be compiled with mips/mips32*
instructions.

+TUNE_FEATURES_tune-mips64-nf-n32 = "n32 bigendian"
+BASE_LIB_tune-mips64-nf-n32 = "lib32"
+MIPSPKGSFX_VARIANT_tune-mips64-nf-n32 = "${TUNE_ARCH}"
+PACKAGE_EXTRA_ARCHS_tune-mips64-nf-n32 = "mips64-nf-n32"

+TUNE_FEATURES_tune-mips64el-nf-o32 = "o32"
+BASE_LIB_tune-mips64el-nf-o32 = "lib32"
+MIPSPKGSFX_VARIANT_tune-mips64el-nf-o32 = "${TUNE_ARCH}"
+PACKAGE_EXTRA_ARCHS_tune-mips64el-nf-o32 = "mips64el-nf-o32"

Also o32 and n32 are currently defined to use the same lib directory.  This is
incorrect.  Per long time conventions, o32 belongs in 'lib', and n32 belongs in
'lib32'.  (n64 in lib64)

So at a minimum the directory name of o32 needs to be fixed.


Thanks for pointing this out. I'll fix this in v3.

Regards,
ZubairLK




---
 meta/conf/machine/include/mips/arch-mips.inc | 60 
 meta/conf/machine/include/tune-mips32.inc| 22 +++-
 meta/conf/machine/include/tune-mips64.inc| 78 ++
 meta/conf/machine/include/tune-mips64r2.inc  | 84 
 4 files changed, 183 insertions(+), 61 deletions(-)
 create mode 100644 meta/conf/machine/include/tune-mips64r2.inc

diff --git a/meta/conf/machine/include/mips/arch-mips.inc 
b/meta/conf/machine/include/mips/arch-mips.inc
index d3e83d1..6be84be 100644
--- a/meta/conf/machine/include/mips/arch-mips.inc
+++ b/meta/conf/machine/include/mips/arch-mips.inc
@@ -42,64 +42,4 @@ MIPSPKGSFX_ABI = "${@bb.utils.contains('TUNE_FEATURES', 'n32', 
'-n32', '', d)}"
 TUNE_ARCH = "mips${MIPSPKGSFX_BYTE}${MIPSPKGSFX_ENDIAN}"
 TUNE_PKGARCH = 
"${MIPSPKGSFX_VARIANT_tune-${DEFAULTTUNE}}${MIPSPKGSFX_FPU}${MIPSPKGSFX_ABI}"

-# Base tunes
-AVAILTUNES += "mips mips64-n32 mips64 mipsel mips64el-n32 mips64el mips-nf 
mips64-nf-n32 mips64-nf mipsel-nf mips64el-nf-n32 mips64el-nf"
-TUNE_FEATURES_tune-mips = "o32 bigendian fpu-hard"
-BASE_LIB_tune-mips = "lib"
-MIPSPKGSFX_VARIANT_tune-mips = "${TUNE_ARCH}"
-PACKAGE_EXTRA_ARCHS_tune-mips = "mips"

-TUNE_FEATURES_tune-mips64-n32 = "n32 bigendian fpu-hard"
-BASE_LIB_tune-mips64-n32 = "lib32"
-MIPSPKGSFX_VARIANT_tune-mips64-n32 = "${TUNE_ARCH}"
-PACKAGE_EXTRA_ARCHS_tune-mips64-n32 = "mips64-n32"
-
-TUNE_FEATURES_tune-mips64 = "n64 bigendian fpu-hard"
-BASE_LIB_tune-mips64 = "lib64"
-MIPSPKGSFX_VARIANT_tune-mips64 = "${TUNE_ARCH}"
-PACKAGE_EXTRA_ARCHS_tune-mips64 = "mips64"
-
-TUNE_FEATURES_tune-mipsel = "o32 fpu-hard"
-BASE_LIB_tune-mipsel = "lib"
-MIPSPKGSFX_VARIANT_tune-mipsel = "${TUNE_ARCH}"
-PACKAGE_EXTRA_ARCHS_tune-mipsel = "mipsel"
-
-TUNE_FEATURES_tune-mips64el-n32 = "n32 fpu-hard"
-BASE_LIB_tune-mips64el-n32 = "lib32"
-MIPSPKGSFX_VARIANT_tune-mips64el-n32 = "${TUNE_ARCH}"
-PACKAGE_EXTRA_ARCHS_tune-mips64el-n32 = "mips64el-n32"
-
-TUNE_FEATURES_tune-mips64el = "n64 fpu-hard"
-BASE_LIB_tune-mips64el = "lib64"
-MIPSPKGSFX_VARIANT_tune-mips64el = "${TUNE_ARCH}"
-PACKAGE_EXTRA_ARCHS_tune-mips64el = "mips64el"
-
-TUNE_FEATURES_tune-mips-nf 

Re: [OE-core] [PATCH 1/1] gcc-sanitizers: Fix libtool library files

[Burton, Ross]

On 20 September 2016 at 10:19, Yuanjie Huang 
wrote:

> Upstream-Status: Inappropriate [embedded specific]
> (LOCAL REV; NOT UPSTREAM) -- sent to oe-core on 2016-09-20
>

You don't need upstream-status tags in commit messages, only patches that
the recipe is applying.

Also please remove your internal tracking data from the commit message.

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

Re: [OE-core] [OE-Core][Patch v2] arch-mips: Restructure mips64 and add mips64r2

[Mark Hatle]

On 9/20/16 5:33 AM, Zubair Lutfullah Kakakhel wrote:
> The current file structure felt slightly unsuitable for adding
> MIPS64r2. So I restructured it slightly and added MIPS64r2
> support
> 
> Signed-off-by: Zubair Lutfullah Kakakhel 
> 
> ---
> V1 -> V2
> Fixed a subtle bug in the include files for tune-mips64.inc which
> resulted in a build failure for multi-lib configuration.

(Sorry, I didn't see V1.)

Can you explain why you moved the items out of arch-mips.inc?

Generally we want the arch-*.inc file to set a base set of components that the
optimized tunes can use.  It most case we define all of the core architecture
'features' and basic tunes in the arch files, and then add specific processor
optimizations in the arch-*.inc files.

Also I see 'mips64*-o32' defined.  I did not realize this was a valid
configuration.  In the past o32 could only be compiled with mips/mips32*
instructions.

+TUNE_FEATURES_tune-mips64-nf-n32 = "n32 bigendian"
+BASE_LIB_tune-mips64-nf-n32 = "lib32"
+MIPSPKGSFX_VARIANT_tune-mips64-nf-n32 = "${TUNE_ARCH}"
+PACKAGE_EXTRA_ARCHS_tune-mips64-nf-n32 = "mips64-nf-n32"

+TUNE_FEATURES_tune-mips64el-nf-o32 = "o32"
+BASE_LIB_tune-mips64el-nf-o32 = "lib32"
+MIPSPKGSFX_VARIANT_tune-mips64el-nf-o32 = "${TUNE_ARCH}"
+PACKAGE_EXTRA_ARCHS_tune-mips64el-nf-o32 = "mips64el-nf-o32"

Also o32 and n32 are currently defined to use the same lib directory.  This is
incorrect.  Per long time conventions, o32 belongs in 'lib', and n32 belongs in
'lib32'.  (n64 in lib64)

So at a minimum the directory name of o32 needs to be fixed.

> ---
>  meta/conf/machine/include/mips/arch-mips.inc | 60 
>  meta/conf/machine/include/tune-mips32.inc| 22 +++-
>  meta/conf/machine/include/tune-mips64.inc| 78 ++
>  meta/conf/machine/include/tune-mips64r2.inc  | 84 
> 
>  4 files changed, 183 insertions(+), 61 deletions(-)
>  create mode 100644 meta/conf/machine/include/tune-mips64r2.inc
> 
> diff --git a/meta/conf/machine/include/mips/arch-mips.inc 
> b/meta/conf/machine/include/mips/arch-mips.inc
> index d3e83d1..6be84be 100644
> --- a/meta/conf/machine/include/mips/arch-mips.inc
> +++ b/meta/conf/machine/include/mips/arch-mips.inc
> @@ -42,64 +42,4 @@ MIPSPKGSFX_ABI = "${@bb.utils.contains('TUNE_FEATURES', 
> 'n32', '-n32', '', d)}"
>  TUNE_ARCH = "mips${MIPSPKGSFX_BYTE}${MIPSPKGSFX_ENDIAN}"
>  TUNE_PKGARCH = 
> "${MIPSPKGSFX_VARIANT_tune-${DEFAULTTUNE}}${MIPSPKGSFX_FPU}${MIPSPKGSFX_ABI}"
>  
> -# Base tunes
> -AVAILTUNES += "mips mips64-n32 mips64 mipsel mips64el-n32 mips64el mips-nf 
> mips64-nf-n32 mips64-nf mipsel-nf mips64el-nf-n32 mips64el-nf"
> -TUNE_FEATURES_tune-mips = "o32 bigendian fpu-hard"
> -BASE_LIB_tune-mips = "lib"
> -MIPSPKGSFX_VARIANT_tune-mips = "${TUNE_ARCH}"
> -PACKAGE_EXTRA_ARCHS_tune-mips = "mips"
>  
> -TUNE_FEATURES_tune-mips64-n32 = "n32 bigendian fpu-hard"
> -BASE_LIB_tune-mips64-n32 = "lib32"
> -MIPSPKGSFX_VARIANT_tune-mips64-n32 = "${TUNE_ARCH}"
> -PACKAGE_EXTRA_ARCHS_tune-mips64-n32 = "mips64-n32"
> -
> -TUNE_FEATURES_tune-mips64 = "n64 bigendian fpu-hard"
> -BASE_LIB_tune-mips64 = "lib64"
> -MIPSPKGSFX_VARIANT_tune-mips64 = "${TUNE_ARCH}"
> -PACKAGE_EXTRA_ARCHS_tune-mips64 = "mips64"
> -
> -TUNE_FEATURES_tune-mipsel = "o32 fpu-hard"
> -BASE_LIB_tune-mipsel = "lib"
> -MIPSPKGSFX_VARIANT_tune-mipsel = "${TUNE_ARCH}"
> -PACKAGE_EXTRA_ARCHS_tune-mipsel = "mipsel"
> -
> -TUNE_FEATURES_tune-mips64el-n32 = "n32 fpu-hard"
> -BASE_LIB_tune-mips64el-n32 = "lib32"
> -MIPSPKGSFX_VARIANT_tune-mips64el-n32 = "${TUNE_ARCH}"
> -PACKAGE_EXTRA_ARCHS_tune-mips64el-n32 = "mips64el-n32"
> -
> -TUNE_FEATURES_tune-mips64el = "n64 fpu-hard"
> -BASE_LIB_tune-mips64el = "lib64"
> -MIPSPKGSFX_VARIANT_tune-mips64el = "${TUNE_ARCH}"
> -PACKAGE_EXTRA_ARCHS_tune-mips64el = "mips64el"
> -
> -TUNE_FEATURES_tune-mips-nf = "o32 bigendian"
> -BASE_LIB_tune-mips-nf = "lib"
> -MIPSPKGSFX_VARIANT_tune-mips-nf = "${TUNE_ARCH}"
> -PACKAGE_EXTRA_ARCHS_tune-mips-nf = "mips-nf"
> -
> -TUNE_FEATURES_tune-mips64-nf-n32 = "n32 bigendian"
> -BASE_LIB_tune-mips64-nf-n32 = "lib32"
> -MIPSPKGSFX_VARIANT_tune-mips64-nf-n32 = "${TUNE_ARCH}"
> -PACKAGE_EXTRA_ARCHS_tune-mips64-nf-n32 = "mips64-nf-n32"
> -
> -TUNE_FEATURES_tune-mips64-nf = "n64 bigendian"
> -BASE_LIB_tune-mips64-nf = "lib64"
> -MIPSPKGSFX_VARIANT_tune-mips64-nf = "${TUNE_ARCH}"
> -PACKAGE_EXTRA_ARCHS_tune-mips64-nf = "mips64-nf"
> -
> -TUNE_FEATURES_tune-mipsel-nf = "o32"
> -BASE_LIB_tune-mipsel-nf = "lib"
> -MIPSPKGSFX_VARIANT_tune-mipsel-nf = "${TUNE_ARCH}"
> -PACKAGE_EXTRA_ARCHS_tune-mipsel-nf = "mipsel-nf"
> -
> -TUNE_FEATURES_tune-mips64el-nf-n32 = "n32"
> -BASE_LIB_tune-mips64el-nf-n32 = "lib32"
> -MIPSPKGSFX_VARIANT_tune-mips64el-nf-n32 = "${TUNE_ARCH}"
> -PACKAGE_EXTRA_ARCHS_tune-mips64el-nf-n32 = "mips64el-nf-n32"
> -
> -TUNE_FEATURES_tune-mips64el-nf = "n64"
> -BASE_LIB_tune-mips64el-nf = "lib64"
> -MIPSPKGSFX_VARIANT_tune-mips64el-nf = 

[OE-core] [wic][PATCH] directdisk*.wks: add serial console support

[Ed Bartosh]

Added serial console to kernel command line to to make it
easier to boot wic images on devices without display.

Tested on MinnowBoard MAX.

Signed-off-by: Ed Bartosh 
---
 scripts/lib/wic/canned-wks/directdisk-gpt.wks  | 2 +-
 scripts/lib/wic/canned-wks/directdisk-multi-rootfs.wks | 2 +-
 scripts/lib/wic/canned-wks/directdisk.wks  | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/scripts/lib/wic/canned-wks/directdisk-gpt.wks 
b/scripts/lib/wic/canned-wks/directdisk-gpt.wks
index ea01cf3..8d7d8de 100644
--- a/scripts/lib/wic/canned-wks/directdisk-gpt.wks
+++ b/scripts/lib/wic/canned-wks/directdisk-gpt.wks
@@ -6,5 +6,5 @@
 part /boot --source bootimg-pcbios --ondisk sda --label boot --active --align 
1024
 part / --source rootfs --ondisk sda --fstype=ext4 --label platform --align 
1024 --use-uuid
 
-bootloader  --ptable gpt --timeout=0  --append="rootwait rootfstype=ext4 
video=vesafb vga=0x318 console=tty0"
+bootloader  --ptable gpt --timeout=0  --append="rootwait rootfstype=ext4 
video=vesafb vga=0x318 console=tty0 console=ttyS0,115200n8"
 
diff --git a/scripts/lib/wic/canned-wks/directdisk-multi-rootfs.wks 
b/scripts/lib/wic/canned-wks/directdisk-multi-rootfs.wks
index 8a81f8f..f61d941 100644
--- a/scripts/lib/wic/canned-wks/directdisk-multi-rootfs.wks
+++ b/scripts/lib/wic/canned-wks/directdisk-multi-rootfs.wks
@@ -19,5 +19,5 @@ part /boot --source bootimg-pcbios --ondisk sda --label boot 
--active --align 10
 part / --source rootfs --rootfs-dir=rootfs1 --ondisk sda --fstype=ext4 --label 
platform --align 1024
 part /rescue --source rootfs --rootfs-dir=rootfs2 --ondisk sda --fstype=ext4 
--label secondary --align 1024
 
-bootloader  --timeout=0  --append="rootwait rootfstype=ext4 video=vesafb 
vga=0x318 console=tty0"
+bootloader  --timeout=0  --append="rootwait rootfstype=ext4 video=vesafb 
vga=0x318 console=tty0 console=ttyS0,115200n8"
 
diff --git a/scripts/lib/wic/canned-wks/directdisk.wks 
b/scripts/lib/wic/canned-wks/directdisk.wks
index 6db74a7..8c8e06b 100644
--- a/scripts/lib/wic/canned-wks/directdisk.wks
+++ b/scripts/lib/wic/canned-wks/directdisk.wks
@@ -4,5 +4,5 @@
 
 include common.wks.inc
 
-bootloader  --timeout=0  --append="rootwait rootfstype=ext4 video=vesafb 
vga=0x318 console=tty0"
+bootloader  --timeout=0  --append="rootwait rootfstype=ext4 video=vesafb 
vga=0x318 console=tty0 console=ttyS0,115200n8"
 
-- 
2.1.4

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

Re: [OE-core] [PATCH v2] libunwind: add aarch64 support

[Fathi Boudra]

Hi,

On 20 September 2016 at 05:12, ChenQi  wrote:
> On 09/26/2014 05:59 PM, Fathi Boudra wrote:
>>
>> * pass --enable-debug-frame on aarch64 architecture
>
>
> Hi Fathi,
>
> I'm now dealing with a problem related to libunwind support on aarch64.
> Could you please tell me why '--enable-debug-frame' is needed for aarch64?

libunwind needs to be configured with --enable-debug-frame to prevent a
linkage error.
Note: --enable-debug-frame is automatically selected on ARM32, not on ARM64.

> Best Regards,
> Chen Qi

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

[OE-core] [OE-Core][Patch v2] arch-mips: Restructure mips64 and add mips64r2

[Zubair Lutfullah Kakakhel]

The current file structure felt slightly unsuitable for adding
MIPS64r2. So I restructured it slightly and added MIPS64r2
support

Signed-off-by: Zubair Lutfullah Kakakhel 

---
V1 -> V2
Fixed a subtle bug in the include files for tune-mips64.inc which
resulted in a build failure for multi-lib configuration.
---
 meta/conf/machine/include/mips/arch-mips.inc | 60 
 meta/conf/machine/include/tune-mips32.inc| 22 +++-
 meta/conf/machine/include/tune-mips64.inc| 78 ++
 meta/conf/machine/include/tune-mips64r2.inc  | 84 
 4 files changed, 183 insertions(+), 61 deletions(-)
 create mode 100644 meta/conf/machine/include/tune-mips64r2.inc

diff --git a/meta/conf/machine/include/mips/arch-mips.inc 
b/meta/conf/machine/include/mips/arch-mips.inc
index d3e83d1..6be84be 100644
--- a/meta/conf/machine/include/mips/arch-mips.inc
+++ b/meta/conf/machine/include/mips/arch-mips.inc
@@ -42,64 +42,4 @@ MIPSPKGSFX_ABI = "${@bb.utils.contains('TUNE_FEATURES', 
'n32', '-n32', '', d)}"
 TUNE_ARCH = "mips${MIPSPKGSFX_BYTE}${MIPSPKGSFX_ENDIAN}"
 TUNE_PKGARCH = 
"${MIPSPKGSFX_VARIANT_tune-${DEFAULTTUNE}}${MIPSPKGSFX_FPU}${MIPSPKGSFX_ABI}"
 
-# Base tunes
-AVAILTUNES += "mips mips64-n32 mips64 mipsel mips64el-n32 mips64el mips-nf 
mips64-nf-n32 mips64-nf mipsel-nf mips64el-nf-n32 mips64el-nf"
-TUNE_FEATURES_tune-mips = "o32 bigendian fpu-hard"
-BASE_LIB_tune-mips = "lib"
-MIPSPKGSFX_VARIANT_tune-mips = "${TUNE_ARCH}"
-PACKAGE_EXTRA_ARCHS_tune-mips = "mips"
 
-TUNE_FEATURES_tune-mips64-n32 = "n32 bigendian fpu-hard"
-BASE_LIB_tune-mips64-n32 = "lib32"
-MIPSPKGSFX_VARIANT_tune-mips64-n32 = "${TUNE_ARCH}"
-PACKAGE_EXTRA_ARCHS_tune-mips64-n32 = "mips64-n32"
-
-TUNE_FEATURES_tune-mips64 = "n64 bigendian fpu-hard"
-BASE_LIB_tune-mips64 = "lib64"
-MIPSPKGSFX_VARIANT_tune-mips64 = "${TUNE_ARCH}"
-PACKAGE_EXTRA_ARCHS_tune-mips64 = "mips64"
-
-TUNE_FEATURES_tune-mipsel = "o32 fpu-hard"
-BASE_LIB_tune-mipsel = "lib"
-MIPSPKGSFX_VARIANT_tune-mipsel = "${TUNE_ARCH}"
-PACKAGE_EXTRA_ARCHS_tune-mipsel = "mipsel"
-
-TUNE_FEATURES_tune-mips64el-n32 = "n32 fpu-hard"
-BASE_LIB_tune-mips64el-n32 = "lib32"
-MIPSPKGSFX_VARIANT_tune-mips64el-n32 = "${TUNE_ARCH}"
-PACKAGE_EXTRA_ARCHS_tune-mips64el-n32 = "mips64el-n32"
-
-TUNE_FEATURES_tune-mips64el = "n64 fpu-hard"
-BASE_LIB_tune-mips64el = "lib64"
-MIPSPKGSFX_VARIANT_tune-mips64el = "${TUNE_ARCH}"
-PACKAGE_EXTRA_ARCHS_tune-mips64el = "mips64el"
-
-TUNE_FEATURES_tune-mips-nf = "o32 bigendian"
-BASE_LIB_tune-mips-nf = "lib"
-MIPSPKGSFX_VARIANT_tune-mips-nf = "${TUNE_ARCH}"
-PACKAGE_EXTRA_ARCHS_tune-mips-nf = "mips-nf"
-
-TUNE_FEATURES_tune-mips64-nf-n32 = "n32 bigendian"
-BASE_LIB_tune-mips64-nf-n32 = "lib32"
-MIPSPKGSFX_VARIANT_tune-mips64-nf-n32 = "${TUNE_ARCH}"
-PACKAGE_EXTRA_ARCHS_tune-mips64-nf-n32 = "mips64-nf-n32"
-
-TUNE_FEATURES_tune-mips64-nf = "n64 bigendian"
-BASE_LIB_tune-mips64-nf = "lib64"
-MIPSPKGSFX_VARIANT_tune-mips64-nf = "${TUNE_ARCH}"
-PACKAGE_EXTRA_ARCHS_tune-mips64-nf = "mips64-nf"
-
-TUNE_FEATURES_tune-mipsel-nf = "o32"
-BASE_LIB_tune-mipsel-nf = "lib"
-MIPSPKGSFX_VARIANT_tune-mipsel-nf = "${TUNE_ARCH}"
-PACKAGE_EXTRA_ARCHS_tune-mipsel-nf = "mipsel-nf"
-
-TUNE_FEATURES_tune-mips64el-nf-n32 = "n32"
-BASE_LIB_tune-mips64el-nf-n32 = "lib32"
-MIPSPKGSFX_VARIANT_tune-mips64el-nf-n32 = "${TUNE_ARCH}"
-PACKAGE_EXTRA_ARCHS_tune-mips64el-nf-n32 = "mips64el-nf-n32"
-
-TUNE_FEATURES_tune-mips64el-nf = "n64"
-BASE_LIB_tune-mips64el-nf = "lib64"
-MIPSPKGSFX_VARIANT_tune-mips64el-nf = "${TUNE_ARCH}"
-PACKAGE_EXTRA_ARCHS_tune-mips64el-nf = "mips64el-nf"
diff --git a/meta/conf/machine/include/tune-mips32.inc 
b/meta/conf/machine/include/tune-mips32.inc
index ce0445f..4c3d93f 100644
--- a/meta/conf/machine/include/tune-mips32.inc
+++ b/meta/conf/machine/include/tune-mips32.inc
@@ -6,7 +6,27 @@ TUNEVALID[mips32] = "Enable mips32 specific processor 
optimizations"
 TUNECONFLICTS[mips32] = "n64 n32"
 TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'mips32', ' 
-march=mips32', '', d)}"
 
-AVAILTUNES += "mips32 mips32el mips32-nf mips32el-nf"
+AVAILTUNES += "mips mipsel mips-nf mipsel-nf mips32 mips32el mips32-nf 
mips32el-nf"
+
+TUNE_FEATURES_tune-mips = "o32 bigendian fpu-hard"
+BASE_LIB_tune-mips = "lib"
+MIPSPKGSFX_VARIANT_tune-mips = "${TUNE_ARCH}"
+PACKAGE_EXTRA_ARCHS_tune-mips = "mips"
+
+TUNE_FEATURES_tune-mipsel = "o32 fpu-hard"
+BASE_LIB_tune-mipsel = "lib"
+MIPSPKGSFX_VARIANT_tune-mipsel = "${TUNE_ARCH}"
+PACKAGE_EXTRA_ARCHS_tune-mipsel = "mipsel"
+
+TUNE_FEATURES_tune-mips-nf = "o32 bigendian"
+BASE_LIB_tune-mips-nf = "lib"
+MIPSPKGSFX_VARIANT_tune-mips-nf = "${TUNE_ARCH}"
+PACKAGE_EXTRA_ARCHS_tune-mips-nf = "mips-nf"
+
+TUNE_FEATURES_tune-mipsel-nf = "o32"
+BASE_LIB_tune-mipsel-nf = "lib"
+MIPSPKGSFX_VARIANT_tune-mipsel-nf = "${TUNE_ARCH}"
+PACKAGE_EXTRA_ARCHS_tune-mipsel-nf = "mipsel-nf"
 
 TUNE_FEATURES_tune-mips32 = "${TUNE_FEATURES_tune-mips} mips32"
 

[OE-core] [PATCH 1/1] asciidoc: set CLEANBROKEN to fix rebuild

[Robert Yang]

The make clean removes doc/a2x.1 and doc/asciidoc.1, then it would cause
build failures since in the second build:
Fixing CONF_DIR in asciidoc.py
Fixing CONF_DIR in a2x.py
python a2x.py -f manpage doc/a2x.1.txt
a2x: ERROR: "xmllint" --nonet --noout --valid 
"/path/to/asciidoc-native/8.6.9-r0/asciidoc-8.6.9/doc/a2x.1.xml" returned 
non-zero exit status 4
make: *** [doc/a2x.1] Error 1

The xmllint failed because "--nonext" is used:
I/O error : Attempt to load network entity 
http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd
/buildarea/lyang1/test_arm/tmp/work/x86_64-linux/asciidoc-native/8.6.9-r0/asciidoc-8.6.9/doc/a2x.1.xml:2:
 warning: failed to load external entity 
"http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd;

Avoid running make clean will fix the problem.

Signed-off-by: Robert Yang 
---
 meta/recipes-extended/asciidoc/asciidoc_8.6.9.bb | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/meta/recipes-extended/asciidoc/asciidoc_8.6.9.bb 
b/meta/recipes-extended/asciidoc/asciidoc_8.6.9.bb
index 2091eec..1cd1454 100644
--- a/meta/recipes-extended/asciidoc/asciidoc_8.6.9.bb
+++ b/meta/recipes-extended/asciidoc/asciidoc_8.6.9.bb
@@ -20,3 +20,5 @@ export DESTDIR = "${D}"
 DEPENDS_class-native = "docbook-xml-dtd4-native"
 RDEPENDS_${PN} += "python" 
 BBCLASSEXTEND = "native"
+
+CLEANBROKEN = "1"
-- 
2.9.0

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

[OE-core] [PATCH 0/1] asciidoc: set CLEANBROKEN to fix rebuild

[Robert Yang]

The following changes since commit 5ac0604fdc7d5b783011c43d476210b427b5dae0:

  build-appliance-image: Create image in correct location (2016-09-19 08:58:04 
+0100)

are available in the git repository at:

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

Robert Yang (1):
  asciidoc: set CLEANBROKEN to fix rebuild

 meta/recipes-extended/asciidoc/asciidoc_8.6.9.bb | 2 ++
 1 file changed, 2 insertions(+)

-- 
2.9.0

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

Re: [OE-core] [OE-Core][Patch] arch-mips: Restructure mips64 and add mips64r2

[Zubair Lutfullah Kakakhel]

Hi,

On 09/20/2016 03:33 AM, Robert Yang wrote:

Hi,

It seems that this one causes build failures on qemumips64 + multilib:

config:
http://autobuilder.yocto.io:8010/builders/nightly-multilib/builds/64/steps/CreateAutoConf_5/logs/stdio

error:
http://autobuilder.yocto.io:8010/builders/nightly-multilib/builds/64/steps/BuildImages_5/logs/stdio

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:

Toolchain tunings invalid:
Tuning 'mips32r2' has no defined features, and cannot be used.


Thank-you. I've noticed a subtle error in the include file sequence marked below



// Robert

On 09/19/2016 07:14 PM, Zubair Lutfullah Kakakhel wrote:

The current file structure felt slightly unsuitable for adding
MIPS64r2. So I restructured it slightly and added MIPS64r2
support

Signed-off-by: Zubair Lutfullah Kakakhel 
---
 meta/conf/machine/include/mips/arch-mips.inc | 60 
 meta/conf/machine/include/tune-mips32.inc| 22 +++-
 meta/conf/machine/include/tune-mips64.inc| 80 +-
 meta/conf/machine/include/tune-mips64r2.inc  | 84 
 4 files changed, 184 insertions(+), 62 deletions(-)

...

diff --git a/meta/conf/machine/include/tune-mips64.inc 
b/meta/conf/machine/include/tune-mips64.inc
index 9be0e0f..e0c9d2c 100644
--- a/meta/conf/machine/include/tune-mips64.inc
+++ b/meta/conf/machine/include/tune-mips64.inc
@@ -1,3 +1,81 @@
 DEFAULTTUNE ?= "mips64"

-require conf/machine/include/tune-mips32r2.inc
+require conf/machine/include/mips/arch-mips.inc


Here. Even though this is mips64.inc. It builds up using
mips32r2.inc to include all previous tune configurations
in mips32r2

Regards,
ZubairLK


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

[OE-core] [PATCH 1/1] gcc-sanitizers: Fix libtool library files

[Yuanjie Huang]

From: Yuanjie Huang 

Since libtool sysroot is not set when compiling sanitizers, the libtool
does no prefix the dependency path correctly. Fix it, so that programs
can link to sanitizer libraries without error.

This patch changes the depenedency_libs line in libasan.la and
libusan.la from
dependency_libs=' -lpthread -ldl '/usr/lib'/libstdc++.la 
'/usr/lib'/libstdc++.la'
to
dependency_libs=' -lpthread -ldl =/usr/lib/libstdc++.la 
=/usr/lib/libstdc++.la'

Upstream-Status: Inappropriate [embedded specific]
(LOCAL REV; NOT UPSTREAM) -- sent to oe-core on 2016-09-20

Signed-off-by: Yuanjie Huang 
---
 meta/recipes-devtools/gcc/gcc-sanitizers.inc | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/meta/recipes-devtools/gcc/gcc-sanitizers.inc 
b/meta/recipes-devtools/gcc/gcc-sanitizers.inc
index c987ccb..5fe5eaf 100644
--- a/meta/recipes-devtools/gcc/gcc-sanitizers.inc
+++ b/meta/recipes-devtools/gcc/gcc-sanitizers.inc
@@ -50,6 +50,8 @@ do_install () {
 rmdir --ignore-fail-on-non-empty -p ${D}${infodir}
 fi
 chown -R root:root ${D}
+# Fix broken libtool with stdc++, as sysroot is not set.
+find ${D} -name \*.la -exec sed -i 
"/^dependency_libs=/s@'/usr/lib'@=/usr/lib@g" {} \;
 }
 
 INHIBIT_DEFAULT_DEPS = "1"
-- 
1.9.1

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

Re: [OE-core] [PATCH 0/1] rpm: make install with --nosignature and --nodigest work

[Hongxu Jia]

BTW, as Robert suggested, I tested rpm upgrade (rpm -F),
the fix also works well

Preprae two version hello with bad signature

1. Install hello with version 1.0-r1.0

root@localhost:~# rpm -ivh --nodigest --nosignature 
hello-1.0-r1.0.corei7_64.rpm

Preparing... ### [100%]
   1:hello ### [100%]

root@localhost:~# rpm -F --verbose hello-1.0-r2.0.corei7_64.rpm
error: hello-1.0-r2.0.corei7_64.rpm: Header V4 DSA signature: BAD, key 
ID 8a0274fa


2. Upgrade hello with version 1.0-r2.0

root@localhost:~# rpm -F --verbose --nodigest --nosignature 
hello-1.0-r2.0.corei7_64.rpm

Preparing packages for installation...
hello-1.0-r2.0.corei7_64

root@localhost:~# rpm -q hello
hello-1.0-r2.0.corei7_64

//Hongxu

On 09/20/2016 04:15 PM, Hongxu Jia wrote:

Boot a target environment with rpm:

1). With option '--nodigest --nosignature', installing package
with bad signature is successful
==
root@localhost:~# rpm -ivh hello-bogus.rpm
error: hello-bogus.rpm: Header V4 DSA signature: BAD, key ID 09753bca

==

2). Without option '--nodigest --nosignature', installing package
with bad signature failed
==
root@localhost:~# rpm -ivh --nodigest --nosignature  hello-bogus.rpm
Preparing...### [100%]
1:hello  ### [100%]
==

BTW: the package with bad signature hello-bogus.rpm in
https://bugzilla.yoctoproject.org/show_bug.cgi?id=10308

//Hongxu

The following changes since commit 49a7839e602eac2c43415d9c8f17ad8315fd1da5:

   build-appliance-image: Create image in correct location (2016-09-19 08:58:10 
+0100)

are available in the git repository at:

   git://git.openembedded.org/openembedded-core-contrib hongxu/fix-rpm
   
http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=hongxu/fix-rpm

Hongxu Jia (1):
   rpm: make install with --nosignature and --nodigest work

  ...0001-system.h-query.c-support-nosignature.patch | 75 --
  1 file changed, 71 insertions(+), 4 deletions(-)



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

[OE-core] [PATCH 0/1] rpm: make install with --nosignature and --nodigest work

[Hongxu Jia]

Boot a target environment with rpm:

1). With option '--nodigest --nosignature', installing package
with bad signature is successful
== 
root@localhost:~# rpm -ivh hello-bogus.rpm
error: hello-bogus.rpm: Header V4 DSA signature: BAD, key ID 09753bca

==

2). Without option '--nodigest --nosignature', installing package
with bad signature failed
==
root@localhost:~# rpm -ivh --nodigest --nosignature  hello-bogus.rpm
Preparing...### [100%]
   1:hello  ### [100%]
==

BTW: the package with bad signature hello-bogus.rpm in
https://bugzilla.yoctoproject.org/show_bug.cgi?id=10308

//Hongxu

The following changes since commit 49a7839e602eac2c43415d9c8f17ad8315fd1da5:

  build-appliance-image: Create image in correct location (2016-09-19 08:58:10 
+0100)

are available in the git repository at:

  git://git.openembedded.org/openembedded-core-contrib hongxu/fix-rpm
  
http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=hongxu/fix-rpm

Hongxu Jia (1):
  rpm: make install with --nosignature and --nodigest work

 ...0001-system.h-query.c-support-nosignature.patch | 75 --
 1 file changed, 71 insertions(+), 4 deletions(-)

-- 
2.8.1

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

[OE-core] [PATCH 1/1] rpm: make install with --nosignature and --nodigest work

[Hongxu Jia]

It fixed the following issue:
1). With option '--nodigest --nosignature', installing package
with bad signature failed
==
root@localhost:~# rpm -ivh --nodigest --nosignature  hello-bogus.rpm
error: hello-bogus.rpm: Header V4 DSA signature: BAD, key ID 09753bc
==

2). Without option '--nodigest --nosignature', installing package
with bad signature is successful
==
root@localhost:~# rpm -ivh hello-bogus.rpm
Preparing...### [100%]
   1:hello  ### [100%]
root@localhost:~# rpm -q hello
hello-1.0-r1.1.x86_64
==

[YOCTO #10308]

Signed-off-by: Hongxu Jia 
---
 ...0001-system.h-query.c-support-nosignature.patch | 75 --
 1 file changed, 71 insertions(+), 4 deletions(-)

diff --git 
a/meta/recipes-devtools/rpm/rpm/0001-system.h-query.c-support-nosignature.patch 
b/meta/recipes-devtools/rpm/rpm/0001-system.h-query.c-support-nosignature.patch
index 77dc5b6..d8636c4 100644
--- 
a/meta/recipes-devtools/rpm/rpm/0001-system.h-query.c-support-nosignature.patch
+++ 
b/meta/recipes-devtools/rpm/rpm/0001-system.h-query.c-support-nosignature.patch
@@ -8,13 +8,29 @@ Subject: [PATCH] system.h/query.c: support nosignature
   otherwise, when use --nosignature would read database and verify
   signature, this is not expected.
 
-Upstream-Status: Submitted [Sent email to rpm-de...@rpm5.org]
+Upstream-Status: Rejected [Sent email to rpm-de...@rpm5.org]
+http://rpm5.org/community/rpm-devel/5655.html
 
 Signed-off-by: Robert Yang 
+
+lib/rpminstall.c: support nosignature
+* !QVA_ISSET -> QVA_ISSET
+Reversing QVA_ISSET:
+- The macro QVA_ISSET(qva->qva_flags, SIGNATURE) invoking in
+  lib/rpminstall.c means qva->qva_flags has bitmap VERIFY_SIGNATURE.
+  And the bitmap assigning in lib/poptQV.c means rpm cli have option
+  --nosignature. (It is weird that SIGNATURE in QVA_ISSET means
+  --nosignature)
+
+  The upstream said he will remove all the SUPPORT_NOSIGNATURES code.
+  See upstream reply http://rpm5.org/community/rpm-devel/5655.html
+
+Signed-off-by: Hongxu Jia 
 ---
- lib/query.c | 6 +++---
- system.h| 4 ++--
- 2 files changed, 5 insertions(+), 5 deletions(-)
+ lib/query.c  |  6 +++---
+ lib/rpminstall.c | 12 ++--
+ system.h |  4 ++--
+ 3 files changed, 11 insertions(+), 11 deletions(-)
 
 diff --git a/lib/query.c b/lib/query.c
 index 50a7453..b761d76 100644
@@ -43,6 +59,56 @@ index 50a7453..b761d76 100644
VSF_SET(vsflags, NOHDRCHK);
  }
  VSF_CLR(vsflags, NEEDPAYLOAD);/* XXX needed? */
+diff --git a/lib/rpminstall.c b/lib/rpminstall.c
+index af6a51b..2a23343 100644
+--- a/lib/rpminstall.c
 b/lib/rpminstall.c
+@@ -566,19 +566,19 @@ int rpmcliInstall(rpmts ts, QVA_t ia, const char ** argv)
+   vsflags = (rpmVSFlags) rpmExpandNumeric("%{?_vsflags_install}");
+ vsflags = (rpmVSFlags) 0; /* XXX FIXME: ignore default disablers. */
+ #if defined(SUPPORT_NOSIGNATURES)
+-if (!QVA_ISSET(ia->qva_flags, DIGEST)) {
++if (QVA_ISSET(ia->qva_flags, DIGEST)) {
+   VSF_SET(vsflags, NOSHA1HEADER);
+   VSF_SET(vsflags, NOMD5HEADER);
+   VSF_SET(vsflags, NOSHA1);
+   VSF_SET(vsflags, NOMD5);
+ }
+-if (!QVA_ISSET(ia->qva_flags, SIGNATURE)) {
++if (QVA_ISSET(ia->qva_flags, SIGNATURE)) {
+   VSF_SET(vsflags, NODSAHEADER);
+   VSF_SET(vsflags, NORSAHEADER);
+   VSF_SET(vsflags, NODSA);
+   VSF_SET(vsflags, NORSA);
+ }
+-if (!QVA_ISSET(ia->qva_flags, HDRCHK)) {
++if (QVA_ISSET(ia->qva_flags, HDRCHK)) {
+   VSF_SET(vsflags, NOHDRCHK);
+ }
+ VSF_SET(vsflags, NEEDPAYLOAD);
+@@ -784,19 +784,19 @@ int rpmErase(rpmts ts, QVA_t ia, const char ** argv)
+ vsflags = (rpmVSFlags) rpmExpandNumeric("%{?_vsflags_erase}");
+ vsflags = (rpmVSFlags) 0; /* XXX FIXME: ignore default disablers. */
+ #if defined(SUPPORT_NOSIGNATURES)
+-if (!QVA_ISSET(ia->qva_flags, DIGEST)) {
++if (QVA_ISSET(ia->qva_flags, DIGEST)) {
+   VSF_SET(vsflags, NOSHA1HEADER);
+   VSF_SET(vsflags, NOMD5HEADER);
+   VSF_SET(vsflags, NOSHA1);
+   VSF_SET(vsflags, NOMD5);
+ }
+-if (!QVA_ISSET(ia->qva_flags, SIGNATURE)) {
++if (QVA_ISSET(ia->qva_flags, SIGNATURE)) {
+   VSF_SET(vsflags, NODSAHEADER);
+   VSF_SET(vsflags, NORSAHEADER);
+   VSF_SET(vsflags, NODSA);
+   VSF_SET(vsflags, NORSA);
+ }
+-if (!QVA_ISSET(ia->qva_flags, HDRCHK)) {
++if (QVA_ISSET(ia->qva_flags, HDRCHK)) {
+   VSF_SET(vsflags, NOHDRCHK);
+ }
+ VSF_CLR(vsflags, NEEDPAYLOAD);/* XXX needed? */
 diff --git a/system.h b/system.h
 index 2ff8906..ad4619a 100644
 --- a/system.h
@@ -61,3 +127,4 @@ index 2ff8906..ad4619a 100644
   * Permit ar(1) payloads. Disabled while rpmio/iosm.c is under development.
 -- 
 2.9.0
+
-- 
2.8.1

-- 
___
Openembedded-core 

[OE-core] [PATCH] oeqa/selftest/lic-checksum: don't report the expected failure to errors.yp

[Ross Burton]

This test has a bitbake invocation that is expected to fail, so inhibit
report-error running.

Signed-off-by: Ross Burton 
---
 meta/lib/oeqa/selftest/lic-checksum.py | 1 +
 1 file changed, 1 insertion(+)

diff --git a/meta/lib/oeqa/selftest/lic-checksum.py 
b/meta/lib/oeqa/selftest/lic-checksum.py
index df44c97..2e81373 100644
--- a/meta/lib/oeqa/selftest/lic-checksum.py
+++ b/meta/lib/oeqa/selftest/lic-checksum.py
@@ -29,6 +29,7 @@ SRC_URI = "file://%s;md5=d41d8cd98f00b204e9800998ecf8427e"
 with open(lic_path, "w") as f:
 f.write("data")
 
+self.write_config("INHERIT_remove = \"report-error\"")
 result = bitbake(bitbake_cmd, ignore_status=True)
 if error_msg not in result.output:
 raise AssertionError(result.output)
-- 
2.8.1

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

Re: [OE-core] [PATCH] default-distrovars.inc: remove libidn from LGPLv2_WHITELIST_GPL-3.0

[Huang, Jie (Jackie)]

Got it, thanks!

Thanks,
Jackie

From: Burton, Ross [mailto:ross.bur...@intel.com]
Sent: Tuesday, September 20, 2016 3:54 PM
To: Huang, Jie (Jackie)
Cc: openembedded-core@lists.openembedded.org
Subject: Re: [OE-core] [PATCH] default-distrovars.inc: remove libidn from 
LGPLv2_WHITELIST_GPL-3.0


On 20 September 2016 at 01:50, Huang, Jie (Jackie) 
> wrote:
Ping.

It's queued locally now, should be in master shortly.

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

Re: [OE-core] [PATCH] default-distrovars.inc: remove libidn from LGPLv2_WHITELIST_GPL-3.0

[Burton, Ross]

On 20 September 2016 at 01:50, Huang, Jie (Jackie) <
jackie.hu...@windriver.com> wrote:

> Ping.
>

It's queued locally now, should be in master shortly.

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

Re: [OE-core] [oe-core] [PATCH] [krogoth] gobject-introspection.bbclass: disable introspection for -native and -nativesdk recipes

[Zeeshan Ali]

Hi,

Could we please cherry-pick this? Otherwise some native recipes fail
to build if gobject-introspection is available on host.

On Mon, Sep 12, 2016 at 4:00 PM, Zeeshan Ali  wrote:
> From: Alexander Kanavin 
>
> It is not necessary for those targets, adds to the build time, and pulls
> in the unneeded qemu-native dependency.
>
> (From OE-Core rev: be18364edd5cd2c664f68120063a1e147563faab)
>
> Signed-off-by: Alexander Kanavin 
> Signed-off-by: Ross Burton 
> Signed-off-by: Richard Purdie 
> ---
>  meta/classes/gobject-introspection.bbclass | 14 --
>  1 file changed, 12 insertions(+), 2 deletions(-)
>
> diff --git a/meta/classes/gobject-introspection.bbclass 
> b/meta/classes/gobject-introspection.bbclass
> index 2d73e40..cc7ca5a 100644
> --- a/meta/classes/gobject-introspection.bbclass
> +++ b/meta/classes/gobject-introspection.bbclass
> @@ -3,13 +3,23 @@
>  # This sets up autoconf-based recipes to build introspection data (or not),
>  # depending on distro and machine features (see gobject-introspection-data 
> class).
>  inherit gobject-introspection-data
> -EXTRA_OECONF_prepend = "${@bb.utils.contains('GI_DATA_ENABLED', 'True', 
> '--enable-introspection', '--disable-introspection', d)} "
> +EXTRA_OECONF_prepend_class-target = "${@bb.utils.contains('GI_DATA_ENABLED', 
> 'True', '--enable-introspection', '--disable-introspection', d)} "
> +
> +# When building native recipes, disable introspection, as it is not 
> necessary,
> +# pulls in additional dependencies, and makes build times longer
> +EXTRA_OECONF_prepend_class-native = "--disable-introspection "
> +EXTRA_OECONF_prepend_class-nativesdk = "--disable-introspection "
>
>  UNKNOWN_CONFIGURE_WHITELIST_append = " --enable-introspection 
> --disable-introspection"
>
>  # Generating introspection data depends on a combination of native and target
>  # introspection tools, and qemu to run the target tools.
> -DEPENDS_append = " gobject-introspection gobject-introspection-native 
> qemu-native"
> +DEPENDS_append_class-target = " gobject-introspection 
> gobject-introspection-native qemu-native"
> +
> +# Even though introspection is disabled on -native, gobject-introspection 
> package is still
> +# needed for m4 macros.
> +DEPENDS_append_class-native = " gobject-introspection-native"
> +DEPENDS_append_class-nativesdk = " gobject-introspection-native"
>
>  # This is necessary for python scripts to succeed - distutils fails if these
>  # are not set
> --
> 2.7.4
>



-- 
Regards,

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