Re: [OE-core] Patchwork not picking changes from the ML

[Gary Thomas]

On 2017-02-24 17:46, Burton, Ross wrote:


On 24 February 2017 at 16:27, Patrick Ohly > wrote:

Let me clarify that my original proposal was to reply only to the
original author. That was meant to keep noise down on the list. However,
perhaps it should also go to the list?

Then others can help check that Patchwork works, as the original author
might not be aware that a response is missing. It also tells everyone
the relevant link in Patchwork.


As long as patchworks ignores the email it sends, that's not a terrible idea.


I'd be happy either way, as long as I (as the poster) get some
sort of feedback that the patch has been received and queued.

Thanks for improving this system :-)

--

Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

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

Re: [OE-core] Yocto Bug#10456 discuss

[dengke]

OK, thanks, I will send patch to revert it in Morty.

Dengke
在 02/24/2017 10:24 PM, Bruce Ashfield 写道:

On 2017-02-24 5:33 AM, Dengke Du wrote:

Hi Jussi and bruce

Yocto Bug#10456: X can not launch on qemumips64

I find the kernel 4.4 is ok, and on the latest 4.9 is ok, but on kernel
4.8 is failed.

This is because this commit in linux-yocto-4.8:

~~

commit d03516df837587368fc6e75591f6329c072b9eb5
Author: Matthew Leach 
Date:   Tue Jun 21 16:19:49 2016 +0100

tty: serial: 8250: add CON_CONSDEV to flags

When using the 8250 as a boot console and the main console 
results in

messages being printed twice.  The console framework will only
unregister boot consoles if a new console is registered with the
CON_CONSDEV flag set.

Set this flag for the univ8250 console to prevent 
double-registration.


Signed-off-by: Matthew Leach 
Signed-off-by: Greg Kroah-Hartman 

diff --git a/drivers/tty/serial/8250/8250_core.c
b/drivers/tty/serial/8250/8250_core.c
index fa823a5..dcf43f6 100644
--- a/drivers/tty/serial/8250/8250_core.c
+++ b/drivers/tty/serial/8250/8250_core.c
@@ -675,7 +675,7 @@ static struct console univ8250_console = {
.device = uart_console_device,
.setup  = univ8250_console_setup,
.match  = univ8250_console_match,
-   .flags  = CON_PRINTBUFFER | CON_ANYTIME,
+   .flags  = CON_PRINTBUFFER | CON_ANYTIME | CON_CONSDEV,
.index  = -1,
.data   = _reg,
 };

~~

The 4.9 has been reverted it, so backport that reverted patch can fix
this bug, but I don't know why this related to qemumips64?


Looks like the console is interfering with X claiming a VT for
startup.

But I wouldn't worry about the root cause all that much, if you've
bisected it, and it has been reverted already in newer kernels .. that
should be enough evidence for anyone.

Bruce



Thanks

Dengke






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

Re: [OE-core] [PATCH] wic: Prevent duplicate entries on fstab

[Burton, Ross]

On 23 February 2017 at 18:13, Fabio Berton 
wrote:
>
> Add function to read fstab and return all mount points. This function
> is useful to _update_fstab doesn't duplicate entries in /etc/fstab.


The AB just failed all over with this error message:

| Traceback (most recent call last):
|   File
"/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-x86/build/scripts/wic",
line 327, in 
| sys.exit(main(sys.argv[1:]))
|   File
"/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-x86/build/scripts/wic",
line 322, in main
| return hlp.invoke_subcommand(args, parser, hlp.wic_help_usage,
subcommands)
|   File
"/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-x86/build/scripts/lib/wic/help.py",
line 95, in invoke_subcommand
| subcommands.get(args[0], subcommand_error)[0](args[1:], usage)
|   File
"/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-x86/build/scripts/wic",
line 255, in wic_create_subcommand
| native_sysroot, options)
|   File
"/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-x86/build/scripts/lib/wic/engine.py",
line 199, in wic_create
| plugin.do_create()
|   File
"/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-x86/build/scripts/lib/wic/plugins/imager/direct.py",
line 93, in do_create
| self.create()
|   File
"/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-x86/build/scripts/lib/wic/plugins/imager/direct.py",
line 176, in create
| fstab_path = self._write_fstab(self.rootfs_dir.get("ROOTFS_DIR"))
|   File
"/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-x86/build/scripts/lib/wic/plugins/imager/direct.py",
line 134, in _write_fstab
| if self._update_fstab(fstab_lines, self.parts):
|   File
"/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-x86/build/scripts/lib/wic/plugins/imager/direct.py",
line 156, in _update_fstab
| opts, "0", "0"]) + "\n"
| TypeError: sequence item 2: expected str instance, NoneType found

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

[OE-core] [PATCH 1/1] oelib/buildhistory.py: Add unittest for buildhistory_analysis

[Humberto Ibarra]

The buildhistory_analysis module (in which buildhistory-diff is
based) was lacking unittest for its functions. Created selftest
module for this and a few testcases to cover basic cases.

[YOCTO #10727]

Signed-off-by: Humberto Ibarra 
---
 meta/lib/oeqa/selftest/oelib/buildhistory.py | 88 
 1 file changed, 88 insertions(+)
 create mode 100644 meta/lib/oeqa/selftest/oelib/buildhistory.py

diff --git a/meta/lib/oeqa/selftest/oelib/buildhistory.py 
b/meta/lib/oeqa/selftest/oelib/buildhistory.py
new file mode 100644
index 000..8d1fa93
--- /dev/null
+++ b/meta/lib/oeqa/selftest/oelib/buildhistory.py
@@ -0,0 +1,88 @@
+import os
+import unittest
+from git import Repo
+from oeqa.utils.commands import get_bb_var
+from oe.buildhistory_analysis import blob_to_dict, compare_dict_blobs
+
+class TestBlobParsing(unittest.TestCase):
+
+def setUp(self):
+import time
+tmp_repo = "bhrepo_%s" % time.strftime("%Y%m%d%H%M%S")
+self.repo_path = os.path.join(get_bb_var('TOPDIR'), tmp_repo)
+os.mkdir(self.repo_path)
+
+self.repo = Repo.init(self.repo_path)
+self.test_file = "test"
+self.var_map = {}
+
+def tearDown(self):
+import shutil
+shutil.rmtree(self.repo_path)
+
+def commit_vars(self, to_add={}, to_remove = [], msg="A commit message"):
+if len(to_add) == 0 and len(to_remove) == 0:
+return
+
+for k in to_remove:
+self.var_map.pop(x,None)
+for k in to_add:
+self.var_map[k] = to_add[k]
+
+with open(os.path.join(self.repo_path, self.test_file), 'w') as 
repo_file:
+for k in self.var_map:
+repo_file.write("%s = %s\n" % (k, self.var_map[k]))
+
+self.repo.git.add("--all")
+self.repo.git.commit(message=msg)
+
+def test_blob_to_dict(self):
+"""
+Test convertion of git blobs to dictionary
+"""
+valuesmap = { "foo" : "1", "bar" : "2" }
+self.commit_vars(to_add = valuesmap)
+
+blob = self.repo.head.commit.tree.blobs[0]
+self.assertEqual(valuesmap, blob_to_dict(blob),
+"commit was not translated correctly to dictionary")
+
+def test_compare_dict_blobs(self):
+"""
+Test comparisson of dictionaries extracted from git blobs
+"""
+changesmap = { "foo-2" : ("2", "8"), "bar" : ("","4"), "bar-2" : 
("","5")}
+
+self.commit_vars(to_add = { "foo" : "1", "foo-2" : "2", "foo-3" : "3" 
})
+blob1 = self.repo.heads.master.commit.tree.blobs[0]
+
+self.commit_vars(to_add = { "foo-2" : "8", "bar" : "4", "bar-2" : "5" 
})
+blob2 = self.repo.heads.master.commit.tree.blobs[0]
+
+change_records = compare_dict_blobs(os.path.join(self.repo_path, 
self.test_file),
+blob1, blob2, False, False)
+
+var_changes = { x.fieldname : (x.oldvalue, x.newvalue) for x in 
change_records}
+self.assertEqual(changesmap, var_changes, "Changes not reported 
correctly")
+
+def test_compare_dict_blobs_default(self):
+"""
+Test default values for comparisson of git blob dictionaries
+"""
+defaultmap = { x : ("default", "1")  for x in ["PKG", "PKGE", "PKGV", 
"PKGR"]}
+
+self.commit_vars(to_add = { "foo" : "1" })
+blob1 = self.repo.heads.master.commit.tree.blobs[0]
+
+self.commit_vars(to_add = { "PKG" : "1", "PKGE" : "1", "PKGV" : "1", 
"PKGR" : "1" })
+blob2 = self.repo.heads.master.commit.tree.blobs[0]
+
+change_records = compare_dict_blobs(os.path.join(self.repo_path, 
self.test_file),
+blob1, blob2, False, False)
+
+var_changes = {}
+for x in change_records:
+oldvalue = "default" if ("default" in x.oldvalue) else x.oldvalue
+var_changes[x.fieldname] = (oldvalue, x.newvalue)
+
+self.assertEqual(defaultmap, var_changes, "Defaults not set properly")
-- 
2.7.4

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

Re: [OE-core] [PATCH] Revert "flex: upgrade to 2.6.2"

[Burton, Ross]

On 24 February 2017 at 20:54, Martin Jansa  wrote:

> and I was pinging Ross about it few days ago as well, hopefully it will be
> included before pyro is branched.
>

It's in the current MUT, don't worry! :)

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

Re: [OE-core] [PATCH] Revert "flex: upgrade to 2.6.2"

[Martin Jansa]

This was already sent to ML 2 weeks ago:
http://lists.openembedded.org/pipermail/openembedded-core/2017-February/132584.html

discussed few times since it was upgraded

and I was pinging Ross about it few days ago as well, hopefully it will be
included before pyro is branched.

On Fri, Feb 24, 2017 at 9:51 PM, Mark Hatle 
wrote:

> This reverts commit 3632abd01abb8dfff230e18f828af705da488f97.
>
> The commit upgraded flex and changed the way it was constructed.  There
> is a problem with either the upgrade or changes in construction mechanism
> resulting in problems similar to:
>
> ../cil/src/cil_lexer.lo: In function `cil_lexer_setup':
> cil_lexer.c:(.text+0x1737): undefined reference to `yy_scan_buffer'
> ../cil/src/cil_lexer.lo: In function `cil_lexer_destroy':
> cil_lexer.c:(.text+0x1773): undefined reference to `yylex_destroy'
>
> Effectively the yy_scan_buffer and yylex_destroy (in this example) were
> defined in a header, but were not defined in the resulting generated code.
>
> The snippet above was from libsepol-native from the meta-selinux layer.
> The build was performed on a Fedora 24 system.
>
> Reverting that commit resolves the problem.
>
> Signed-off-by: Mark Hatle 
> ---
>  ...oid-c-comments-in-c-code-fails-with-gcc-6.patch |  64 ++
>  .../recipes-devtools/flex/flex/CVE-2016-6354.patch |  59 ++
>  meta/recipes-devtools/flex/flex/crosscompile.patch | 214
> -
>  .../flex/flex/do_not_create_pdf_doc.patch  |  17 ++
>  .../flex/{flex_2.6.2.bb => flex_2.6.0.bb}  |  11 +-
>  5 files changed, 146 insertions(+), 219 deletions(-)
>  create mode 100644 meta/recipes-devtools/flex/
> flex/0002-avoid-c-comments-in-c-code-fails-with-gcc-6.patch
>  create mode 100644 meta/recipes-devtools/flex/flex/CVE-2016-6354.patch
>  delete mode 100644 meta/recipes-devtools/flex/flex/crosscompile.patch
>  create mode 100644 meta/recipes-devtools/flex/flex/do_not_create_pdf_doc.
> patch
>  rename meta/recipes-devtools/flex/{flex_2.6.2.bb => flex_2.6.0.bb} (84%)
>
> diff --git 
> a/meta/recipes-devtools/flex/flex/0002-avoid-c-comments-in-c-code-fails-with-gcc-6.patch
> b/meta/recipes-devtools/flex/flex/0002-avoid-c-comments-in-
> c-code-fails-with-gcc-6.patch
> new file mode 100644
> index 00..438ca5f527
> --- /dev/null
> +++ b/meta/recipes-devtools/flex/flex/0002-avoid-c-comments-in-
> c-code-fails-with-gcc-6.patch
> @@ -0,0 +1,64 @@
> +From 7072befe1397af4eb01c3ff7edf99f0cd5076089 Mon Sep 17 00:00:00 2001
> +From: =?UTF-8?q?Andreas=20M=C3=BCller?= 
> +Date: Tue, 30 Aug 2016 14:25:32 +0200
> +Subject: [PATCH] avoid c++ comments in c-code - fails with gcc-6
> +MIME-Version: 1.0
> +Content-Type: text/plain; charset=UTF-8
> +Content-Transfer-Encoding: 8bit
> +
> +fixes:
> +
> +| error: C++ style comments are not allowed in ISO C90
> +| num_to_alloc = 1; // After all that talk, this was set to 1 anyways...
> +
> +Upstream-Status: Pending
> +
> +Signed-off-by: Andreas Müller 
> +---
> + src/flex.skl | 2 +-
> + src/scan.c   | 2 +-
> + src/skel.c   | 2 +-
> + 3 files changed, 3 insertions(+), 3 deletions(-)
> +
> +diff --git a/src/flex.skl b/src/flex.skl
> +index 73a0b9e..ed71627 100644
> +--- a/src/flex.skl
>  b/src/flex.skl
> +@@ -2350,7 +2350,7 @@ void yyFlexLexer::yyensure_buffer_stack(void)
> +* scanner will even need a stack. We use 2 instead of 1
> to avoid an
> +* immediate realloc on the next call.
> +  */
> +-  num_to_alloc = 1; // After all that talk, this was set to
> 1 anyways...
> ++  num_to_alloc = 1; /* After all that talk, this was set to
> 1 anyways... */
> +   YY_G(yy_buffer_stack) = (struct yy_buffer_state**)yyalloc
> +
>  (num_to_alloc * sizeof(struct yy_buffer_state*)
> +
>  M4_YY_CALL_LAST_ARG);
> +diff --git a/src/scan.c b/src/scan.c
> +index b55df2d..f1dce75 100644
> +--- a/src/scan.c
>  b/src/scan.c
> +@@ -4672,7 +4672,7 @@ static void yyensure_buffer_stack (void)
> +* scanner will even need a stack. We use 2 instead of 1
> to avoid an
> +* immediate realloc on the next call.
> +  */
> +-  num_to_alloc = 1; // After all that talk, this was set to
> 1 anyways...
> ++  num_to_alloc = 1; /* After all that talk, this was set to
> 1 anyways...*/
> +   (yy_buffer_stack) = (struct yy_buffer_state**)yyalloc
> +
>  (num_to_alloc * sizeof(struct yy_buffer_state*)
> +   );
> +diff --git a/src/skel.c b/src/skel.c
> +index ef657d3..26cc889 100644
> +--- a/src/skel.c
>  b/src/skel.c
> +@@ -2561,7 +2561,7 @@ const char *skel[] = {
> +   "* scanner will even need a stack. We use 2 instead of 1
> to avoid an",
> +   "* immediate realloc on the next call.",
> +   " */",
> +-  "   num_to_alloc = 1; 

Re: [OE-core] [PATCH] deprecated.bbclass: Add a PNDEPRECATED variable for recipes

[Martin Jansa]

OK, should I update all currently PNBLACKLISTed recipes to add " - the
recipe will be removed on 2017-09-01 unless the issue is fixed" in the
PNBLACKLIST value, so that we can delete all blacklisted recipes before 2.4
release?

On Fri, Feb 24, 2017 at 9:39 PM, Philip Balister 
wrote:

> On 02/24/2017 01:16 AM, Martin Jansa wrote:
> >> If nobody speaks up within some
> > amount of time the maintainer considers reasonable (I'm thinking a Yocto
> > release
> > cycle) then it's fair game to remove the recipe in question.
> >
> > Maybe this is different case with at least some PNBLACKLIST entries we
> > currently have, but
> > I don't remove PNBLACKLISTed recipes, because as we discussed it's always
> > easier to unblacklist
> > recipe from e.g. DISTRO config if the issue doesn't affect you for
> whatever
> > reason and causes
> > less churn in the metadata when it gets unblacklisted.
> >
> > And many PNBLACKLISTed recipes are also abandonware.
> >
>
> I think we need to use a different "flag" for recipes that need
> updating, and have maintained upstreams from recipes that have upstreams
> that are abandoned.
>
> So blacklist broken recipes with good upstreams and deprecate recipes
> with dead upstreams.
>
> Philip
>
>
>
> > So my question is, if we will remove PNDEPRECATed recipes after one
> cycle,
> > should we start
> > removing PNBLACKLISTed recipes as well (maybe after 2 cycles?). In both
> > cases it might backfire
> > when someone will fail to find recipe for his favorite abandonware and
> will
> > try to add completely
> > new recipe for it, or we see someone restoring these recipes (e.g. in own
> > layers instead of fixing
> > the PNBLACKLIST/PNDEPRECATED reasons in original layer).
> >
> > On Fri, Feb 24, 2017 at 5:55 AM, Khem Raj  wrote:
> >
> >>
> >> On Thu, Feb 23, 2017 at 8:00 PM Joe MacDonald  >
> >> wrote:
> >>
> >>> Based on the blacklist behaviour, recipes can be tagged as deprecated.
> >>> Such recipes will produce a warning message when included in a build
> but
> >>> unlike blacklisted recipes, the build will continue.
> >>
> >>
> >> Perhaps this should also be documented in manuals
> >>
> >>>
> >>>
> >>> Signed-off-by: Joe MacDonald 
> >>> ---
> >>>
> >>> I threw this together a long time ago and never got around to sending
> it
> >>> out for
> >>> consideration, but after the excitement last week and this, I got
> >>> thinking about
> >>> it again and thought it might be useful.  My specific use-case for
> this is
> >>> recipes I see in meta-networking that I know are largely abandonware
> but
> >>> that I
> >>> don't want to completely throw out without giving some kind of heads
> up.
> >>> Obviously this is purely informational, there's no mechanism set up for
> >>> purging
> >>> deprecated recipes, that's intended to be a maintainer activity, but
> the
> >>> idea
> >>> would be that the maintainer would flag a recipe as deprecated
> (probably
> >>> when
> >>> it's become more trouble than it seems to be worth) and thereafter
> users
> >>> would
> >>> have fair warning that this thing is on notice.  If nobody speaks up
> >>> within some
> >>> amount of time the maintainer considers reasonable (I'm thinking a
> Yocto
> >>> release
> >>> cycle) then it's fair game to remove the recipe in question.
> >>>
> >>>  meta/classes/deprecated.bbclass| 16 
> >>>  meta/conf/distro/defaultsetup.conf |  3 ++-
> >>>  2 files changed, 18 insertions(+), 1 deletion(-)
> >>>  create mode 100644 meta/classes/deprecated.bbclass
> >>>
> >>> diff --git a/meta/classes/deprecated.bbclass
> b/meta/classes/deprecated.
> >>> bbclass
> >>> new file mode 100644
> >>> index 000..3dcdadb
> >>> --- /dev/null
> >>> +++ b/meta/classes/deprecated.bbclass
> >>> @@ -0,0 +1,16 @@
> >>> +# To use the deprecated recipe check, a distribution should
> >>> +# include this class in the INHERIT_DISTRO
> >>> +#
> >>> +# Features:
> >>> +#
> >>> +# * To add a package to the deprecated list, set:
> >>> +#   PNDEPRECATED[pn] = "message"
> >>> +#
> >>> +
> >>> +addtask check_deprecated before do_fetch
> >>> +python do_check_deprecated () {
> >>> +deprecated = d.getVarFlag('PNDEPRECATED', d.getVar('PN', True),
> >>> False)
> >>> +
> >>> +if deprecated:
> >>> +bb.warn("Recipe is deprecated: ", (deprecated))
> >>> +}
> >>> diff --git a/meta/conf/distro/defaultsetup.conf b/meta/conf/distro/
> >>> defaultsetup.conf
> >>> index ca2f917..16ece3a 100644
> >>> --- a/meta/conf/distro/defaultsetup.conf
> >>> +++ b/meta/conf/distro/defaultsetup.conf
> >>> @@ -20,5 +20,6 @@ CACHE = "${TMPDIR}/cache/${TCMODE}-${TCLIBC}${@['',
> >>> '/' + str(d.getVar('MACHINE'
> >>>  USER_CLASSES ?= ""
> >>>  PACKAGE_CLASSES ?= "package_ipk"
> >>>  INHERIT_BLACKLIST = "blacklist"
> >>> +INHERIT_DEPRECATED = "deprecated"
> >>>  INHERIT_DISTRO ?= "debian devshell sstate license remove-libtool"
> >>> -INHERIT += "${PACKAGE_CLASSES} 

[OE-core] [PATCH] Revert "flex: upgrade to 2.6.2"

[Mark Hatle]

This reverts commit 3632abd01abb8dfff230e18f828af705da488f97.

The commit upgraded flex and changed the way it was constructed.  There
is a problem with either the upgrade or changes in construction mechanism
resulting in problems similar to:

../cil/src/cil_lexer.lo: In function `cil_lexer_setup':
cil_lexer.c:(.text+0x1737): undefined reference to `yy_scan_buffer'
../cil/src/cil_lexer.lo: In function `cil_lexer_destroy':
cil_lexer.c:(.text+0x1773): undefined reference to `yylex_destroy'

Effectively the yy_scan_buffer and yylex_destroy (in this example) were
defined in a header, but were not defined in the resulting generated code.

The snippet above was from libsepol-native from the meta-selinux layer.
The build was performed on a Fedora 24 system.

Reverting that commit resolves the problem.

Signed-off-by: Mark Hatle 
---
 ...oid-c-comments-in-c-code-fails-with-gcc-6.patch |  64 ++
 .../recipes-devtools/flex/flex/CVE-2016-6354.patch |  59 ++
 meta/recipes-devtools/flex/flex/crosscompile.patch | 214 -
 .../flex/flex/do_not_create_pdf_doc.patch  |  17 ++
 .../flex/{flex_2.6.2.bb => flex_2.6.0.bb}  |  11 +-
 5 files changed, 146 insertions(+), 219 deletions(-)
 create mode 100644 
meta/recipes-devtools/flex/flex/0002-avoid-c-comments-in-c-code-fails-with-gcc-6.patch
 create mode 100644 meta/recipes-devtools/flex/flex/CVE-2016-6354.patch
 delete mode 100644 meta/recipes-devtools/flex/flex/crosscompile.patch
 create mode 100644 meta/recipes-devtools/flex/flex/do_not_create_pdf_doc.patch
 rename meta/recipes-devtools/flex/{flex_2.6.2.bb => flex_2.6.0.bb} (84%)

diff --git 
a/meta/recipes-devtools/flex/flex/0002-avoid-c-comments-in-c-code-fails-with-gcc-6.patch
 
b/meta/recipes-devtools/flex/flex/0002-avoid-c-comments-in-c-code-fails-with-gcc-6.patch
new file mode 100644
index 00..438ca5f527
--- /dev/null
+++ 
b/meta/recipes-devtools/flex/flex/0002-avoid-c-comments-in-c-code-fails-with-gcc-6.patch
@@ -0,0 +1,64 @@
+From 7072befe1397af4eb01c3ff7edf99f0cd5076089 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Andreas=20M=C3=BCller?= 
+Date: Tue, 30 Aug 2016 14:25:32 +0200
+Subject: [PATCH] avoid c++ comments in c-code - fails with gcc-6
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+fixes:
+
+| error: C++ style comments are not allowed in ISO C90
+| num_to_alloc = 1; // After all that talk, this was set to 1 anyways...
+
+Upstream-Status: Pending
+
+Signed-off-by: Andreas Müller 
+---
+ src/flex.skl | 2 +-
+ src/scan.c   | 2 +-
+ src/skel.c   | 2 +-
+ 3 files changed, 3 insertions(+), 3 deletions(-)
+
+diff --git a/src/flex.skl b/src/flex.skl
+index 73a0b9e..ed71627 100644
+--- a/src/flex.skl
 b/src/flex.skl
+@@ -2350,7 +2350,7 @@ void yyFlexLexer::yyensure_buffer_stack(void)
+* scanner will even need a stack. We use 2 instead of 1 to 
avoid an
+* immediate realloc on the next call.
+  */
+-  num_to_alloc = 1; // After all that talk, this was set to 1 
anyways...
++  num_to_alloc = 1; /* After all that talk, this was set to 1 
anyways... */
+   YY_G(yy_buffer_stack) = (struct yy_buffer_state**)yyalloc
+   (num_to_alloc * 
sizeof(struct yy_buffer_state*)
+   
M4_YY_CALL_LAST_ARG);
+diff --git a/src/scan.c b/src/scan.c
+index b55df2d..f1dce75 100644
+--- a/src/scan.c
 b/src/scan.c
+@@ -4672,7 +4672,7 @@ static void yyensure_buffer_stack (void)
+* scanner will even need a stack. We use 2 instead of 1 to 
avoid an
+* immediate realloc on the next call.
+  */
+-  num_to_alloc = 1; // After all that talk, this was set to 1 
anyways...
++  num_to_alloc = 1; /* After all that talk, this was set to 1 
anyways...*/
+   (yy_buffer_stack) = (struct yy_buffer_state**)yyalloc
+   (num_to_alloc * 
sizeof(struct yy_buffer_state*)
+   );
+diff --git a/src/skel.c b/src/skel.c
+index ef657d3..26cc889 100644
+--- a/src/skel.c
 b/src/skel.c
+@@ -2561,7 +2561,7 @@ const char *skel[] = {
+   "* scanner will even need a stack. We use 2 instead of 1 to 
avoid an",
+   "* immediate realloc on the next call.",
+   " */",
+-  "   num_to_alloc = 1; // After all that talk, this was set to 1 
anyways...",
++  "   num_to_alloc = 1; /* After all that talk, this was set to 1 
anyways... */",
+   "   YY_G(yy_buffer_stack) = (struct yy_buffer_state**)yyalloc",
+   "   (num_to_alloc * 
sizeof(struct yy_buffer_state*)",
+   "

Re: [OE-core] [PATCH] ell: Initial recipe for Embedded Linux Library

[Burton, Ross]

On 24 February 2017 at 18:42, Ankit Navik  wrote:

> Add generic recipe for ELL.
>

This doesn't answer the question of "why?".

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

Re: [OE-core] [PATCH] deprecated.bbclass: Add a PNDEPRECATED variable for recipes

[Philip Balister]

On 02/24/2017 01:16 AM, Martin Jansa wrote:
>> If nobody speaks up within some
> amount of time the maintainer considers reasonable (I'm thinking a Yocto
> release
> cycle) then it's fair game to remove the recipe in question.
> 
> Maybe this is different case with at least some PNBLACKLIST entries we
> currently have, but
> I don't remove PNBLACKLISTed recipes, because as we discussed it's always
> easier to unblacklist
> recipe from e.g. DISTRO config if the issue doesn't affect you for whatever
> reason and causes
> less churn in the metadata when it gets unblacklisted.
> 
> And many PNBLACKLISTed recipes are also abandonware.
> 

I think we need to use a different "flag" for recipes that need
updating, and have maintained upstreams from recipes that have upstreams
that are abandoned.

So blacklist broken recipes with good upstreams and deprecate recipes
with dead upstreams.

Philip



> So my question is, if we will remove PNDEPRECATed recipes after one cycle,
> should we start
> removing PNBLACKLISTed recipes as well (maybe after 2 cycles?). In both
> cases it might backfire
> when someone will fail to find recipe for his favorite abandonware and will
> try to add completely
> new recipe for it, or we see someone restoring these recipes (e.g. in own
> layers instead of fixing
> the PNBLACKLIST/PNDEPRECATED reasons in original layer).
> 
> On Fri, Feb 24, 2017 at 5:55 AM, Khem Raj  wrote:
> 
>>
>> On Thu, Feb 23, 2017 at 8:00 PM Joe MacDonald 
>> wrote:
>>
>>> Based on the blacklist behaviour, recipes can be tagged as deprecated.
>>> Such recipes will produce a warning message when included in a build but
>>> unlike blacklisted recipes, the build will continue.
>>
>>
>> Perhaps this should also be documented in manuals
>>
>>>
>>>
>>> Signed-off-by: Joe MacDonald 
>>> ---
>>>
>>> I threw this together a long time ago and never got around to sending it
>>> out for
>>> consideration, but after the excitement last week and this, I got
>>> thinking about
>>> it again and thought it might be useful.  My specific use-case for this is
>>> recipes I see in meta-networking that I know are largely abandonware but
>>> that I
>>> don't want to completely throw out without giving some kind of heads up.
>>> Obviously this is purely informational, there's no mechanism set up for
>>> purging
>>> deprecated recipes, that's intended to be a maintainer activity, but the
>>> idea
>>> would be that the maintainer would flag a recipe as deprecated (probably
>>> when
>>> it's become more trouble than it seems to be worth) and thereafter users
>>> would
>>> have fair warning that this thing is on notice.  If nobody speaks up
>>> within some
>>> amount of time the maintainer considers reasonable (I'm thinking a Yocto
>>> release
>>> cycle) then it's fair game to remove the recipe in question.
>>>
>>>  meta/classes/deprecated.bbclass| 16 
>>>  meta/conf/distro/defaultsetup.conf |  3 ++-
>>>  2 files changed, 18 insertions(+), 1 deletion(-)
>>>  create mode 100644 meta/classes/deprecated.bbclass
>>>
>>> diff --git a/meta/classes/deprecated.bbclass b/meta/classes/deprecated.
>>> bbclass
>>> new file mode 100644
>>> index 000..3dcdadb
>>> --- /dev/null
>>> +++ b/meta/classes/deprecated.bbclass
>>> @@ -0,0 +1,16 @@
>>> +# To use the deprecated recipe check, a distribution should
>>> +# include this class in the INHERIT_DISTRO
>>> +#
>>> +# Features:
>>> +#
>>> +# * To add a package to the deprecated list, set:
>>> +#   PNDEPRECATED[pn] = "message"
>>> +#
>>> +
>>> +addtask check_deprecated before do_fetch
>>> +python do_check_deprecated () {
>>> +deprecated = d.getVarFlag('PNDEPRECATED', d.getVar('PN', True),
>>> False)
>>> +
>>> +if deprecated:
>>> +bb.warn("Recipe is deprecated: ", (deprecated))
>>> +}
>>> diff --git a/meta/conf/distro/defaultsetup.conf b/meta/conf/distro/
>>> defaultsetup.conf
>>> index ca2f917..16ece3a 100644
>>> --- a/meta/conf/distro/defaultsetup.conf
>>> +++ b/meta/conf/distro/defaultsetup.conf
>>> @@ -20,5 +20,6 @@ CACHE = "${TMPDIR}/cache/${TCMODE}-${TCLIBC}${@['',
>>> '/' + str(d.getVar('MACHINE'
>>>  USER_CLASSES ?= ""
>>>  PACKAGE_CLASSES ?= "package_ipk"
>>>  INHERIT_BLACKLIST = "blacklist"
>>> +INHERIT_DEPRECATED = "deprecated"
>>>  INHERIT_DISTRO ?= "debian devshell sstate license remove-libtool"
>>> -INHERIT += "${PACKAGE_CLASSES} ${USER_CLASSES} ${INHERIT_DISTRO}
>>> ${INHERIT_BLACKLIST}"
>>> +INHERIT += "${PACKAGE_CLASSES} ${USER_CLASSES} ${INHERIT_DISTRO}
>>> ${INHERIT_BLACKLIST} ${INHERIT_DEPRECATED}"
>>> --
>>> 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
>> 

[OE-core] [PATCH] ell: Initial recipe for Embedded Linux Library

[Ankit Navik]

Add generic recipe for ELL.

Signed-off-by: Ankit Navik 
---
 meta/recipes-core/ell/ell_git.bb | 17 +
 1 file changed, 17 insertions(+)
 create mode 100644 meta/recipes-core/ell/ell_git.bb

diff --git a/meta/recipes-core/ell/ell_git.bb b/meta/recipes-core/ell/ell_git.bb
new file mode 100644
index 000..d259f52
--- /dev/null
+++ b/meta/recipes-core/ell/ell_git.bb
@@ -0,0 +1,17 @@
+SUMMARY  = "Embedded Linux Library"
+DESCRIPTION = "ELL is a DBUS library which provides DBUS bindings."
+LICENSE  = "LGPLv2.1"
+LIC_FILES_CHKSUM = "file://COPYING;md5=fb504b67c50331fc78734fed90fb0e09"
+SECTION = "libs"
+
+inherit autotools pkgconfig
+
+S = "${WORKDIR}/git"
+SRCREV = "399099946abaeb2f3718a0667cc11436a7c0be14"
+SRC_URI = "git://git.kernel.org/pub/scm/libs/ell/ell.git"
+
+do_configure_prepend () {
+mkdir ${S}/build-aux
+}
+
+DEPENDS = "dbus"
-- 
1.9.1

-- 
___
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: Make sanity check opt-out and provide easy opt-out

[Cal Sullivan]

On 02/23/2017 04:13 PM, Cal Sullivan wrote:

On 02/23/2017 03:27 PM, Cal Sullivan wrote:



On 02/23/2017 03:07 PM, Burton, Ross wrote:


On 23 February 2017 at 22:32, California Sullivan 
> wrote:


The only change from V1 to V2 is the updated commit message,
changing
AUTOINC to AUTOREV and adding the blurb about impacting outside
recipes.

I also agree with Richard in that this is a significant
functionality change
and should not be backported.


I failed to say that I suspected this patch was to blame for SDK 
generation failing on the autobuilder earlier. Can you try 
generating a eSDK (bitbake core-image-minimal -c populate_sdk_ext) 
 with this patch?


Ross
Will do. Any specific configuration I should use, or should it fail 
in most/all situations?


Thanks,
Cal




[clsulliv@clsulliv build]$ bitbake core-image-minimal -c populate_sdk_ext
WARNING: Host distribution "fedora-23" has not been validated with 
this version of the build system; you may possibly experience 
unexpected failures. It is recommended that you use a tested distribution.
Loading cache: 100% 
|##| 
Time: 0:00:00

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

Build Configuration:
BB_VERSION= "1.33.1"
BUILD_SYS = "x86_64-linux"
NATIVELSBSTRING   = "universal"
TARGET_SYS= "x86_64-poky-linux"
MACHINE   = "intel-corei7-64"
DISTRO= "poky"
DISTRO_VERSION= "2.2+snapshot-20170223"
TUNE_FEATURES = "m64 corei7"
TARGET_FPU= ""
meta
meta-poky
meta-yocto-bsp= 
"clsulliv/sanity:53c2449017a3312a2e65720a23ef654924eef0b4"

meta-intel= "master:5153dad2fa695bbb579c03ff795ef649269e8420"

Initialising tasks: 100% 
|#| 
Time: 0:00:06

NOTE: Executing SetScene Tasks
NOTE: Executing RunQueue Tasks
NOTE: Tasks Summary: Attempted 3362 tasks of which 2752 didn't need to 
be rerun and all succeeded.


Summary: There was 1 WARNING message shown.


I'll rerun the build with no meta-intel and qemux86 overnight.

p.s., upgrading my fedora system now :)

---
Cal



Same results with qemux86.

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

Re: [OE-core] [PATCH] ell: Initial recipe for Embedded Linux Library

[Burton, Ross]

On 24 February 2017 at 16:00, Ankit Navik  wrote:

>  meta/recipes-core/ell/ell.inc| 10 ++
>  meta/recipes-core/ell/ell_git.bb |  9 +
>

Unless you have other recipes using the .inc file, then just merge these
into a single .bb.


> +DEPENDS  = "dbus"
> +RDEPENDS_${PN} += "dbus"
>

Why the RDEPENDS?  Any linking will add libdbus as required.


> +do_configure_prepend () {
> +${S}/bootstrap
> +}
>

This just does a mkdir and then calls autoreconf which we do straight away
afterwards, so is mostly a waste of time.  If we need to create the
directory before autoreconf then just do the mkdir in _prepend.

However currently this isn't used by anything in oe-core, so what's the
rationale for adding it to oe-core instead of another layer?

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

Re: [OE-core] Patchwork not picking changes from the ML

[Jose Lamego]

On 02/24/2017 10:27 AM, Patrick Ohly wrote:
> On Fri, 2017-02-24 at 15:33 +0100, Gary Thomas wrote:
>> On 2017-02-24 15:21, Patrick Ohly wrote:
>>> On Wed, 2017-02-22 at 15:56 -0600, Jose Lamego wrote:

 On 02/22/2017 02:55 PM, Michael Halstead wrote:
> I've seen several issues with hooks. I was working on them yesterday and
> will continue today.
>
> These are currently managed by hand but we are moving them into
> configuration management which should help keep them working consistently.

 Michael: one syntax error in patchwork code was pulled into production
 yesterday. This is the cause for missing patches. The error is fixed in
 the Yocto repo now, please perform a server code update ASAP.

 Martin: I will look at the UI issue you are describing and file a bug if
 needed.
>>>
>>> Would it perhaps make sense to reply to the original author with an
>>> email confirming that his patch is now in Patchwork? It should include a
>>> link to the patch series, too.
>>>
>>> This could have several advantages:
>>>   * submitters not aware of Patchwork or whether their target
>>> currently uses it learn about it and then can follow the
>>> progress of their patch
>>>   * everyone gets a confirmation that the submission made it through
>>> the various mail servers and Patchwork itself
>>>
>>> It still relies on the original submitter to watch out for breakages in
>>> the processes, but I guess that can't be avoided with an asynchronous,
>>> mail-based process.
>>>
>>
>> I would love to see this added to the process - +1 :-)
> 
> Let me clarify that my original proposal was to reply only to the
> original author. That was meant to keep noise down on the list. However,
> perhaps it should also go to the list?
> 
> Then others can help check that Patchwork works, as the original author
> might not be aware that a response is missing. It also tells everyone
> the relevant link in Patchwork.
> 
There is a filed request to enable email notifications in patchwork:
https://bugzilla.yoctoproject.org/show_bug.cgi?id=7684

this notifications will let users (both submitter and CC'ed-users) know
through an email about any patch status change (including "New"). Users
will be able to opt-out of such notifications.

However, this do not covers the case when submitter is not registered as
a Patchwork user. So, there might be a one-time-only email notification
to this kind of submitter, as Patrick suggests.

If I don't get any objections for this, I'll file a request in bugzilla
next week.

-- 
Jose Lamego | OTC Embedded Platforms & Tools | GDC



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

Re: [OE-core] Patchwork not picking changes from the ML

[Burton, Ross]

On 24 February 2017 at 16:27, Patrick Ohly  wrote:

> Let me clarify that my original proposal was to reply only to the
> original author. That was meant to keep noise down on the list. However,
> perhaps it should also go to the list?
>
> Then others can help check that Patchwork works, as the original author
> might not be aware that a response is missing. It also tells everyone
> the relevant link in Patchwork.
>

As long as patchworks ignores the email it sends, that's not a terrible
idea.

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

Re: [OE-core] Patchwork not picking changes from the ML

[Patrick Ohly]

On Fri, 2017-02-24 at 15:33 +0100, Gary Thomas wrote:
> On 2017-02-24 15:21, Patrick Ohly wrote:
> > On Wed, 2017-02-22 at 15:56 -0600, Jose Lamego wrote:
> >>
> >> On 02/22/2017 02:55 PM, Michael Halstead wrote:
> >>> I've seen several issues with hooks. I was working on them yesterday and
> >>> will continue today.
> >>>
> >>> These are currently managed by hand but we are moving them into
> >>> configuration management which should help keep them working consistently.
> >>
> >> Michael: one syntax error in patchwork code was pulled into production
> >> yesterday. This is the cause for missing patches. The error is fixed in
> >> the Yocto repo now, please perform a server code update ASAP.
> >>
> >> Martin: I will look at the UI issue you are describing and file a bug if
> >> needed.
> >
> > Would it perhaps make sense to reply to the original author with an
> > email confirming that his patch is now in Patchwork? It should include a
> > link to the patch series, too.
> >
> > This could have several advantages:
> >   * submitters not aware of Patchwork or whether their target
> > currently uses it learn about it and then can follow the
> > progress of their patch
> >   * everyone gets a confirmation that the submission made it through
> > the various mail servers and Patchwork itself
> >
> > It still relies on the original submitter to watch out for breakages in
> > the processes, but I guess that can't be avoided with an asynchronous,
> > mail-based process.
> >
> 
> I would love to see this added to the process - +1 :-)

Let me clarify that my original proposal was to reply only to the
original author. That was meant to keep noise down on the list. However,
perhaps it should also go to the list?

Then others can help check that Patchwork works, as the original author
might not be aware that a response is missing. It also tells everyone
the relevant link in Patchwork.

-- 
Best Regards, Patrick Ohly

The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.



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

[OE-core] [PATCH v3] oeqa/sdk/cases:Adds validation for SDK compatibility tests

[Francisco Pedraza]

Added validation for SDK compatibility tests with eSDK.
buildcvs, buildiptables, gcc, perl, python and buildgalculator based on target 
manifest file.Running with: $ bitbake  -c testsdkext
[YOCTO #9090]

Signed-off-by: Francisco Pedraza 
---
 meta/lib/oeqa/sdk/cases/buildcvs.py| 5 -
 meta/lib/oeqa/sdk/cases/buildgalculator.py | 4 +++-
 meta/lib/oeqa/sdk/cases/buildiptables.py   | 5 -
 meta/lib/oeqa/sdk/cases/gcc.py | 5 -
 meta/lib/oeqa/sdk/cases/perl.py| 5 -
 meta/lib/oeqa/sdk/cases/python.py  | 5 -
 6 files changed, 23 insertions(+), 6 deletions(-)

diff --git a/meta/lib/oeqa/sdk/cases/buildcvs.py 
b/meta/lib/oeqa/sdk/cases/buildcvs.py
index 8cbbca1..5665beb 100644
--- a/meta/lib/oeqa/sdk/cases/buildcvs.py
+++ b/meta/lib/oeqa/sdk/cases/buildcvs.py
@@ -15,7 +15,10 @@ class BuildCvsTest(OESDKTestCase):
 self.project.download_archive()
 
 machine = self.td.get("MACHINE")
-if not self.tc.hasHostPackage("packagegroup-cross-canadian-%s" % 
machine):
+if not (self.tc.hasTargetPackage("packagegroup-cross-canadian-%s" % 
machine) or
+self.tc.hasTargetPackage("gcc-runtime") or
+self.tc.hasTargetPackage("libgcc") or
+self.tc.hasTargetPackage("gcc-sanitizers")):
 raise unittest.SkipTest("SDK doesn't contain a cross-canadian 
toolchain")
 
 def test_cvs(self):
diff --git a/meta/lib/oeqa/sdk/cases/buildgalculator.py 
b/meta/lib/oeqa/sdk/cases/buildgalculator.py
index 42e8ddb..f309ddf 100644
--- a/meta/lib/oeqa/sdk/cases/buildgalculator.py
+++ b/meta/lib/oeqa/sdk/cases/buildgalculator.py
@@ -9,7 +9,9 @@ class GalculatorTest(OESDKTestCase):
 @classmethod
 def setUpClass(self):
 if not (self.tc.hasTargetPackage("gtk+3") or\
-self.tc.hasTargetPackage("libgtk-3.0")):
+self.tc.hasTargetPackage("libgtk-3.0") or
+self.tc.hasTargetPackage("gtk") or
+self.tc.hasTargetPackage("matchbox-config-gtk")):
 raise unittest.SkipTest("GalculatorTest class: SDK don't support 
gtk+3")
 
 def test_galculator(self):
diff --git a/meta/lib/oeqa/sdk/cases/buildiptables.py 
b/meta/lib/oeqa/sdk/cases/buildiptables.py
index 0bd00d1..d7a0e6a 100644
--- a/meta/lib/oeqa/sdk/cases/buildiptables.py
+++ b/meta/lib/oeqa/sdk/cases/buildiptables.py
@@ -17,7 +17,10 @@ class BuildIptablesTest(OESDKTestCase):
 
 machine = self.td.get("MACHINE")
 
-if not self.tc.hasHostPackage("packagegroup-cross-canadian-%s" % 
machine):
+if not (self.tc.hasTargetPackage("packagegroup-cross-canadian-%s" % 
machine) or
+self.tc.hasTargetPackage("gcc-runtime") or
+self.tc.hasTargetPackage("libgcc") or
+self.tc.hasTargetPackage("gcc-sanitizers")):
 raise unittest.SkipTest("SDK doesn't contain a cross-canadian 
toolchain")
 
 def test_iptables(self):
diff --git a/meta/lib/oeqa/sdk/cases/gcc.py b/meta/lib/oeqa/sdk/cases/gcc.py
index 74ad2a2..5404b74 100644
--- a/meta/lib/oeqa/sdk/cases/gcc.py
+++ b/meta/lib/oeqa/sdk/cases/gcc.py
@@ -18,7 +18,10 @@ class GccCompileTest(OESDKTestCase):
 
 def setUp(self):
 machine = self.td.get("MACHINE")
-if not self.tc.hasHostPackage("packagegroup-cross-canadian-%s" % 
machine):
+if not (self.tc.hasTargetPackage("packagegroup-cross-canadian-%s" % 
machine) or
+self.tc.hasTargetPackage("gcc-runtime") or
+self.tc.hasTargetPackage("libgcc") or
+self.tc.hasTargetPackage("gcc-sanitizers")):
 raise unittest.SkipTest("GccCompileTest class: SDK doesn't contain 
a cross-canadian toolchain")
 
 def test_gcc_compile(self):
diff --git a/meta/lib/oeqa/sdk/cases/perl.py b/meta/lib/oeqa/sdk/cases/perl.py
index e1bded2..8be9b74 100644
--- a/meta/lib/oeqa/sdk/cases/perl.py
+++ b/meta/lib/oeqa/sdk/cases/perl.py
@@ -8,7 +8,10 @@ from oeqa.sdk.case import OESDKTestCase
 class PerlTest(OESDKTestCase):
 @classmethod
 def setUpClass(self):
-if not self.tc.hasHostPackage("nativesdk-perl"):
+if not (self.tc.hasHostPackage("nativesdk-perl") or
+self.tc.hasHostPackage("perl-native") or
+self.tc.hasHostPackage("libperl5") or
+self.tc.hasHostPackage("perl")):
 raise unittest.SkipTest("No perl package in the SDK")
 
 for f in ['test.pl']:
diff --git a/meta/lib/oeqa/sdk/cases/python.py 
b/meta/lib/oeqa/sdk/cases/python.py
index 94a296f..1628787 100644
--- a/meta/lib/oeqa/sdk/cases/python.py
+++ b/meta/lib/oeqa/sdk/cases/python.py
@@ -8,7 +8,10 @@ from oeqa.sdk.case import OESDKTestCase
 class PythonTest(OESDKTestCase):
 @classmethod
 def setUpClass(self):
-if not self.tc.hasHostPackage("nativesdk-python"):
+if not (self.tc.hasHostPackage("nativesdk-python") or
+

[OE-core] [PATCH 2/2] gstreamer: update to 1.10.4

[Maxin B. John]

bug-fix release:
 *) Various fixes for crashes, assertions, deadlocks and memory leaks on
fuzzed input files and in other situations (CVE-2017-5847, CVE-2017-5848)
 *) gst-libav was updated to ffmpeg 3.2.4, fixing a couple of CVEs

Signed-off-by: Maxin B. John 
---
 .../{gstreamer1.0-libav_1.10.3.bb => gstreamer1.0-libav_1.10.4.bb}  | 4 ++--
 .../{gstreamer1.0-omx_1.10.3.bb => gstreamer1.0-omx_1.10.4.bb}  | 5 +++--
 ...1.0-plugins-bad_1.10.3.bb => gstreamer1.0-plugins-bad_1.10.4.bb} | 4 ++--
 ...0-plugins-base_1.10.3.bb => gstreamer1.0-plugins-base_1.10.4.bb} | 4 ++--
 ...0-plugins-good_1.10.3.bb => gstreamer1.0-plugins-good_1.10.4.bb} | 4 ++--
 ...0-plugins-ugly_1.10.3.bb => gstreamer1.0-plugins-ugly_1.10.4.bb} | 4 ++--
 .../recipes-multimedia/gstreamer/gstreamer1.0-rtsp-server_1.10.3.bb | 6 --
 .../recipes-multimedia/gstreamer/gstreamer1.0-rtsp-server_1.10.4.bb | 6 ++
 meta/recipes-multimedia/gstreamer/gstreamer1.0-vaapi_1.10.3.bb  | 5 -
 meta/recipes-multimedia/gstreamer/gstreamer1.0-vaapi_1.10.4.bb  | 5 +
 .../gstreamer/{gstreamer1.0_1.10.3.bb => gstreamer1.0_1.10.4.bb}| 4 ++--
 11 files changed, 26 insertions(+), 25 deletions(-)
 rename meta/recipes-multimedia/gstreamer/{gstreamer1.0-libav_1.10.3.bb => 
gstreamer1.0-libav_1.10.4.bb} (87%)
 rename meta/recipes-multimedia/gstreamer/{gstreamer1.0-omx_1.10.3.bb => 
gstreamer1.0-omx_1.10.4.bb} (68%)
 rename meta/recipes-multimedia/gstreamer/{gstreamer1.0-plugins-bad_1.10.3.bb 
=> gstreamer1.0-plugins-bad_1.10.4.bb} (90%)
 rename meta/recipes-multimedia/gstreamer/{gstreamer1.0-plugins-base_1.10.3.bb 
=> gstreamer1.0-plugins-base_1.10.4.bb} (86%)
 rename meta/recipes-multimedia/gstreamer/{gstreamer1.0-plugins-good_1.10.3.bb 
=> gstreamer1.0-plugins-good_1.10.4.bb} (84%)
 rename meta/recipes-multimedia/gstreamer/{gstreamer1.0-plugins-ugly_1.10.3.bb 
=> gstreamer1.0-plugins-ugly_1.10.4.bb} (76%)
 delete mode 100644 
meta/recipes-multimedia/gstreamer/gstreamer1.0-rtsp-server_1.10.3.bb
 create mode 100644 
meta/recipes-multimedia/gstreamer/gstreamer1.0-rtsp-server_1.10.4.bb
 delete mode 100644 
meta/recipes-multimedia/gstreamer/gstreamer1.0-vaapi_1.10.3.bb
 create mode 100644 
meta/recipes-multimedia/gstreamer/gstreamer1.0-vaapi_1.10.4.bb
 rename meta/recipes-multimedia/gstreamer/{gstreamer1.0_1.10.3.bb => 
gstreamer1.0_1.10.4.bb} (72%)

diff --git a/meta/recipes-multimedia/gstreamer/gstreamer1.0-libav_1.10.3.bb 
b/meta/recipes-multimedia/gstreamer/gstreamer1.0-libav_1.10.4.bb
similarity index 87%
rename from meta/recipes-multimedia/gstreamer/gstreamer1.0-libav_1.10.3.bb
rename to meta/recipes-multimedia/gstreamer/gstreamer1.0-libav_1.10.4.bb
index 39afbeb..59d81db 100644
--- a/meta/recipes-multimedia/gstreamer/gstreamer1.0-libav_1.10.3.bb
+++ b/meta/recipes-multimedia/gstreamer/gstreamer1.0-libav_1.10.4.bb
@@ -14,7 +14,7 @@ SRC_URI = " \
 file://workaround-to-build-gst-libav-for-i586-with-gcc.patch \
 file://mips64_cpu_detection.patch \
 "
-SRC_URI[md5sum] = "ce1ea598f07c8bf728a33c7da39ec308"
-SRC_URI[sha256sum] = 
"9a6bc165b1862b18b98d9f1755c43806e4839a80f69ec7ea9a2dab61b65752a9"
+SRC_URI[md5sum] = "e2bdd9fde6ca3ff7efffb93df121f4fd"
+SRC_URI[sha256sum] = 
"6ca0feca75e3d48315e07f20ec37cf6260ed1e9dde58df355febd5016246268b"
 
 S = "${WORKDIR}/gst-libav-${PV}"
diff --git a/meta/recipes-multimedia/gstreamer/gstreamer1.0-omx_1.10.3.bb 
b/meta/recipes-multimedia/gstreamer/gstreamer1.0-omx_1.10.4.bb
similarity index 68%
rename from meta/recipes-multimedia/gstreamer/gstreamer1.0-omx_1.10.3.bb
rename to meta/recipes-multimedia/gstreamer/gstreamer1.0-omx_1.10.4.bb
index 7d06a56..dfeefa5 100644
--- a/meta/recipes-multimedia/gstreamer/gstreamer1.0-omx_1.10.3.bb
+++ b/meta/recipes-multimedia/gstreamer/gstreamer1.0-omx_1.10.4.bb
@@ -4,7 +4,8 @@ LIC_FILES_CHKSUM = 
"file://COPYING;md5=4fbd65380cdd255951079008b364516c \
 
file://omx/gstomx.h;beginline=1;endline=21;md5=5c8e1fca32704488e76d2ba9ddfa935f"
 
 SRC_URI = "http://gstreamer.freedesktop.org/src/gst-omx/gst-omx-${PV}.tar.xz;
-SRC_URI[md5sum] = "1eead212796151d6ac08e091bacbd190"
-SRC_URI[sha256sum] = 
"dd88451e175df7a6b6f619eff0f43a6078054ec7068787b19faf89af94cdb6e1"
+
+SRC_URI[md5sum] = "cedb230f1c47d0cf4b575d70dff66ff2"
+SRC_URI[sha256sum] = 
"45072925cf262f0fd528fab78f0de52734e46a5a88aa802fae51c67c09c81aa2"
 
 S = "${WORKDIR}/gst-omx-${PV}"
diff --git 
a/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad_1.10.3.bb 
b/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad_1.10.4.bb
similarity index 90%
rename from meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad_1.10.3.bb
rename to meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad_1.10.4.bb
index 5bb1543..0bb4053 100644
--- a/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad_1.10.3.bb
+++ b/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad_1.10.4.bb
@@ -19,8 +19,8 @@ SRC_URI = " \
 

[OE-core] [PATCH 1/2] iproute2: upgrade to 4.10.0

[Maxin B. John]

4.9.0 -> 4.10.0

added the following patch to fix build with musl libc
 1) 0001-libc-compat.h-add-musl-workaround.patch

Signed-off-by: Maxin B. John 
---
 .../0001-libc-compat.h-add-musl-workaround.patch   |  41 +++
 .../iproute2/iproute2/iproute2-4.9.0-musl.patch| 131 -
 .../{iproute2_4.9.0.bb => iproute2_4.10.0.bb}  |   6 +-
 3 files changed, 44 insertions(+), 134 deletions(-)
 create mode 100644 
meta/recipes-connectivity/iproute2/iproute2/0001-libc-compat.h-add-musl-workaround.patch
 delete mode 100644 
meta/recipes-connectivity/iproute2/iproute2/iproute2-4.9.0-musl.patch
 rename meta/recipes-connectivity/iproute2/{iproute2_4.9.0.bb => 
iproute2_4.10.0.bb} (59%)

diff --git 
a/meta/recipes-connectivity/iproute2/iproute2/0001-libc-compat.h-add-musl-workaround.patch
 
b/meta/recipes-connectivity/iproute2/iproute2/0001-libc-compat.h-add-musl-workaround.patch
new file mode 100644
index 000..3d324c9
--- /dev/null
+++ 
b/meta/recipes-connectivity/iproute2/iproute2/0001-libc-compat.h-add-musl-workaround.patch
@@ -0,0 +1,41 @@
+From b7d96340c55afb7023ded0041107c63dbd886196 Mon Sep 17 00:00:00 2001
+From: Baruch Siach 
+Date: Thu, 22 Dec 2016 15:26:30 +0200
+Subject: [PATCH] libc-compat.h: add musl workaround
+
+The libc-compat.h kernel header uses glibc specific macros (__GLIBC__ and
+__USE_MISC) to solve conflicts with libc provided headers. This patch makes
+libc-compat.h work for musl libc as well.
+
+Upstream-Status: Pending
+
+Taken From:
+https://git.buildroot.net/buildroot/tree/package/iproute2/0001-Add-the-musl-workaround-to-the-libc-compat.h-copy.patch
+
+Signed-off-by: Baruch Siach 
+Signed-off-by: Maxin B. John 
+---
+ include/linux/libc-compat.h | 4 +++-
+ 1 file changed, 3 insertions(+), 1 deletion(-)
+
+diff --git a/include/linux/libc-compat.h b/include/linux/libc-compat.h
+index f38571d..30f0b67 100644
+--- a/include/linux/libc-compat.h
 b/include/linux/libc-compat.h
+@@ -49,10 +49,12 @@
+ #define _LIBC_COMPAT_H
+ 
+ /* We have included glibc headers... */
+-#if defined(__GLIBC__)
++#if 1
++#define __USE_MISC
+ 
+ /* Coordinate with glibc net/if.h header. */
+ #if defined(_NET_IF_H) && defined(__USE_MISC)
++#define __UAPI_DEF_IF_NET_DEVICE_FLAGS_LOWER_UP_DORMANT_ECHO 0
+ 
+ /* GLIBC headers included first so don't define anything
+  * that would already be defined. */
+-- 
+2.4.0
+
diff --git 
a/meta/recipes-connectivity/iproute2/iproute2/iproute2-4.9.0-musl.patch 
b/meta/recipes-connectivity/iproute2/iproute2/iproute2-4.9.0-musl.patch
deleted file mode 100644
index 737a90c..000
--- a/meta/recipes-connectivity/iproute2/iproute2/iproute2-4.9.0-musl.patch
+++ /dev/null
@@ -1,131 +0,0 @@
-Subject: [PATCH] Avoid in6_addr redefinition
-
-Due to both  and  being included, the 
-in6_addr is being redefined: once from the C library headers and once
-from the kernel headers. This causes some build failures with for 
-example the musl C library.
-
-In order to fix this, use just the C library header .
-Original patch taken from
-http://git.alpinelinux.org/cgit/aports/tree/main/iproute2/musl-fixes.patch.
-
-(Refreshed the patch for 4.9 release)
-
-Upstream-Status: Pending
-
-Signed-off-by: Thomas Petazzoni 
-Signed-off-by: Maxin B. John 
-Signed-off-by: Zheng Ruoqin 

- include/libiptc/ipt_kernel_headers.h | 1 -
- include/linux/if_bridge.h| 1 -
- include/linux/if_tunnel.h| 2 --
- include/linux/netfilter.h| 2 --
- include/linux/netfilter_ipv4/ip_tables.h | 1 -
- include/linux/xfrm.h | 1 -
- include/utils.h  | 1 +
- ip/ip6tunnel.c   | 1 -
- 8 files changed, 1 insertion(+), 9 deletions(-)
-
-diff --git a/include/libiptc/ipt_kernel_headers.h 
b/include/libiptc/ipt_kernel_headers.h
-index a5963e9..42f8610 100644
 a/include/libiptc/ipt_kernel_headers.h
-+++ b/include/libiptc/ipt_kernel_headers.h
-@@ -6,7 +6,6 @@
- #include 
- 
- #include 
--#include 
- #include 
- #include 
- #include 
-diff --git a/include/linux/if_bridge.h b/include/linux/if_bridge.h
-index b7393dd..a7028ab 100644
 a/include/linux/if_bridge.h
-+++ b/include/linux/if_bridge.h
-@@ -15,7 +15,6 @@
- 
- #include 
- #include 
--#include 
- 
- #define SYSFS_BRIDGE_ATTR "bridge"
- #define SYSFS_BRIDGE_FDB  "brforward"
-diff --git a/include/linux/if_tunnel.h b/include/linux/if_tunnel.h
-index 4f975f5..2680646 100644
 a/include/linux/if_tunnel.h
-+++ b/include/linux/if_tunnel.h
-@@ -2,9 +2,7 @@
- #define _IF_TUNNEL_H_
- 
- #include 
--#include 
- #include 
--#include 
- #include 
- 
- 
-diff --git a/include/linux/netfilter.h b/include/linux/netfilter.h
-index b71b4c9..3e4e6ae 100644
 a/include/linux/netfilter.h
-+++ b/include/linux/netfilter.h
-@@ -4,8 +4,6 @@
- #include 
- 
- #include 

[OE-core] [PATCH] systemtap: update to 3.1

[Alexander Kanavin]

Removed patches are in upstream.

Rebase monitor-option.patch and no-msgfmt-check.patch

Add support for python 3 probes
(this necessitates the 
0001-Do-not-let-configure-write-a-python-location-into-th.patch
and the Add 0001-Install-python-modules-to-correct-library-dir.patch to
install python modules to correct destination).

Add perl to RDEPENDS to fix a QA warning about one of the installed files.

Signed-off-by: Alexander Kanavin 
---
 ...configure-write-a-python-location-into-th.patch | 25 +
 ...all-python-modules-to-correct-library-dir.patch | 36 +++
 .../systemtap/systemtap/fix-monitor-linking.patch  | 41 --
 .../systemtap/systemtap/monitor-option.patch   | 26 ++
 .../systemtap/systemtap/no-msgfmt-check.patch  | 22 ++--
 .../systemtap/obsolete_automake_macros.patch   | 15 
 meta/recipes-kernel/systemtap/systemtap_git.bb |  9 ++---
 meta/recipes-kernel/systemtap/systemtap_git.inc|  8 ++---
 8 files changed, 109 insertions(+), 73 deletions(-)
 create mode 100644 
meta/recipes-kernel/systemtap/systemtap/0001-Do-not-let-configure-write-a-python-location-into-th.patch
 create mode 100644 
meta/recipes-kernel/systemtap/systemtap/0001-Install-python-modules-to-correct-library-dir.patch
 delete mode 100644 
meta/recipes-kernel/systemtap/systemtap/fix-monitor-linking.patch
 delete mode 100644 
meta/recipes-kernel/systemtap/systemtap/obsolete_automake_macros.patch

diff --git 
a/meta/recipes-kernel/systemtap/systemtap/0001-Do-not-let-configure-write-a-python-location-into-th.patch
 
b/meta/recipes-kernel/systemtap/systemtap/0001-Do-not-let-configure-write-a-python-location-into-th.patch
new file mode 100644
index 000..742b1187fc3
--- /dev/null
+++ 
b/meta/recipes-kernel/systemtap/systemtap/0001-Do-not-let-configure-write-a-python-location-into-th.patch
@@ -0,0 +1,25 @@
+From ab29615ed6c2e779b472903564dc683dc1015de7 Mon Sep 17 00:00:00 2001
+From: Alexander Kanavin 
+Date: Wed, 22 Feb 2017 13:37:33 +0200
+Subject: [PATCH] Do not let configure write a python location into the dtrace
+ binary
+
+Upstream-Status: Inappropriate [oe-core specific]
+Signed-off-by: Alexander Kanavin 
+---
+ dtrace.in | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/dtrace.in b/dtrace.in
+index 5e1cf8079..a24229cbc 100644
+--- a/dtrace.in
 b/dtrace.in
+@@ -1,4 +1,4 @@
+-#!@preferred_python@
++#!/usr/bin/python3
+ # vim: et sta sts=4 sw=4 ts=8
+ 
+ # This handles the systemtap equivalent of
+-- 
+2.11.0
+
diff --git 
a/meta/recipes-kernel/systemtap/systemtap/0001-Install-python-modules-to-correct-library-dir.patch
 
b/meta/recipes-kernel/systemtap/systemtap/0001-Install-python-modules-to-correct-library-dir.patch
new file mode 100644
index 000..528864cc939
--- /dev/null
+++ 
b/meta/recipes-kernel/systemtap/systemtap/0001-Install-python-modules-to-correct-library-dir.patch
@@ -0,0 +1,36 @@
+From 2ada22f05460223924efe54080cb4419e2b4c276 Mon Sep 17 00:00:00 2001
+From: Alexander Kanavin 
+Date: Fri, 24 Feb 2017 17:53:02 +0200
+Subject: [PATCH] Install python modules to correct library dir.
+
+Upstream-Status: Inappropriate [oe-core specific]
+Signed-off-by: Alexander Kanavin 
+---
+ python/Makefile.am | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/python/Makefile.am b/python/Makefile.am
+index a254480f9..efe9f3c01 100644
+--- a/python/Makefile.am
 b/python/Makefile.am
+@@ -47,7 +47,7 @@ install-exec-local:
+ if HAVE_PYTHON2_PROBES
+   (cd $(srcdir); CFLAGS="$(AM_CPPFLAGS)" $(PYTHON) setup.py build \
+  --build-base $(shell readlink -f $(builddir))/py2build \
+-   install --prefix $(DESTDIR)$(prefix) \
++   install --prefix $(DESTDIR)$(prefix) 
--install-lib=$(DESTDIR)${pythondir} \
+--single-version-externally-managed \
+--record $(shell readlink -f $(builddir))/py2build/install_files.txt \
+  --verbose)
+@@ -55,7 +55,7 @@ endif
+ if HAVE_PYTHON3_PROBES
+   (cd $(srcdir); CFLAGS="$(AM_CPPFLAGS)" $(PYTHON3) setup.py build \
+  --build-base $(shell readlink -f $(builddir))/py3build \
+-   install --prefix $(DESTDIR)$(prefix) \
++   install --prefix $(DESTDIR)$(prefix) 
--install-lib=$(DESTDIR)${python3dir} \
+--single-version-externally-managed \
+--record $(shell readlink -f $(builddir))/py3build/install_files.txt \
+  --verbose)
+-- 
+2.11.0
+
diff --git a/meta/recipes-kernel/systemtap/systemtap/fix-monitor-linking.patch 
b/meta/recipes-kernel/systemtap/systemtap/fix-monitor-linking.patch
deleted file mode 100644
index 2bf0742a1df..000
--- a/meta/recipes-kernel/systemtap/systemtap/fix-monitor-linking.patch
+++ /dev/null
@@ -1,41 +0,0 @@
-Upstream-Status: Submitted
-Signed-off-by: Ross Burton 
-
-From 

Re: [OE-core] [PATCH 24/24] systemtap: update to 3.1

[Alexander Kanavin]

On 02/24/2017 04:22 PM, Burton, Ross wrote:

Add support for python 3 probes


ERROR: QA Issue: lib64-systemtap: Files/directories were installed but
not shipped in any package:
  /usr/lib/python3.5/site-packages/HelperSDT-0.1.0-py3.5.egg-info

/usr/lib/python3.5/site-packages/HelperSDT-0.1.0-py3.5.egg-info/dependency_links.txt
  /usr/lib/python3.5/site-packages/HelperSDT-0.1.0-py3.5.egg-info/PKG-INFO

/usr/lib/python3.5/site-packages/HelperSDT-0.1.0-py3.5.egg-info/top_level.txt

/usr/lib/python3.5/site-packages/HelperSDT-0.1.0-py3.5.egg-info/SOURCES.txt
  /usr/lib/python3.5/site-packages/HelperSDT/__init__.py

/usr/lib/python3.5/site-packages/HelperSDT/_HelperSDT.cpython-35m-x86_64-linux-gnu.so

  /usr/lib/python3.5/site-packages/HelperSDT/__main__.py
  /usr/lib/python3.5/site-packages/HelperSDT/__pycache__

/usr/lib/python3.5/site-packages/HelperSDT/__pycache__/__init__.cpython-35.pyc

/usr/lib/python3.5/site-packages/HelperSDT/__pycache__/__main__.cpython-35.pyc


Just sent an updated patch that should fix this.

Alex

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

[OE-core] [PATCH] ell: Initial recipe for Embedded Linux Library

[Ankit Navik]

Based on the ofono recipe, add ell.inc for generic recipe components
and use it from ell_git.bb.

Signed-off-by: Ankit Navik 
---
 meta/recipes-core/ell/ell.inc| 10 ++
 meta/recipes-core/ell/ell_git.bb |  9 +
 2 files changed, 19 insertions(+)
 create mode 100644 meta/recipes-core/ell/ell.inc
 create mode 100644 meta/recipes-core/ell/ell_git.bb

diff --git a/meta/recipes-core/ell/ell.inc b/meta/recipes-core/ell/ell.inc
new file mode 100644
index 000..b5e185e
--- /dev/null
+++ b/meta/recipes-core/ell/ell.inc
@@ -0,0 +1,10 @@
+SUMMARY  = "Embedded Linux Library"
+DESCRIPTION = "ELL is a DBUS library which provides DBUS bindings."
+LICENSE  = "LGPLv2.1"
+LIC_FILES_CHKSUM = "file://COPYING;md5=fb504b67c50331fc78734fed90fb0e09"
+SECTION = "libs"
+
+inherit autotools pkgconfig
+
+DEPENDS  = "dbus"
+RDEPENDS_${PN} += "dbus"
diff --git a/meta/recipes-core/ell/ell_git.bb b/meta/recipes-core/ell/ell_git.bb
new file mode 100644
index 000..fd438be
--- /dev/null
+++ b/meta/recipes-core/ell/ell_git.bb
@@ -0,0 +1,9 @@
+require ell.inc
+
+S = "${WORKDIR}/git"
+SRCREV = "399099946abaeb2f3718a0667cc11436a7c0be14"
+SRC_URI = "git://git.kernel.org/pub/scm/libs/ell/ell.git"
+
+do_configure_prepend () {
+${S}/bootstrap
+}
-- 
1.9.1

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

[OE-core] [PATCH] python3-pip: RDEPEND on python3-html.

[Ismo Puustinen]

Without this pip3 fails with "ImportError: No module named 'html'"

Signed-off-by: Ismo Puustinen 
---
 meta/recipes-devtools/python/python3-pip_9.0.1.bb | 1 +
 1 file changed, 1 insertion(+)

diff --git a/meta/recipes-devtools/python/python3-pip_9.0.1.bb 
b/meta/recipes-devtools/python/python3-pip_9.0.1.bb
index 85328dc..b6dbb6e 100644
--- a/meta/recipes-devtools/python/python3-pip_9.0.1.bb
+++ b/meta/recipes-devtools/python/python3-pip_9.0.1.bb
@@ -40,6 +40,7 @@ RDEPENDS_${PN} = "\
   python3-compile \
   python3-io \
   python3-enum \
+  python3-html \
   python3-json \
   python3-netserver \
   python3-setuptools \
-- 
2.9.3

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

[OE-core] [PATCH v2] deprecated.bbclass: Add a PNDEPRECATED variable for recipes

[Joe MacDonald]

Based on the blacklist behaviour, recipes can be tagged as deprecated.
Such recipes will produce a warning message when included in a build but
unlike blacklisted recipes, the build will continue.

Signed-off-by: Joe MacDonald 
---
 documentation/ref-manual/ref-classes.xml   | 28 
 documentation/ref-manual/ref-variables.xml | 28 
 meta/classes/deprecated.bbclass| 16 
 meta/conf/distro/defaultsetup.conf |  3 ++-
 4 files changed, 74 insertions(+), 1 deletion(-)
 create mode 100644 meta/classes/deprecated.bbclass

diff --git a/documentation/ref-manual/ref-classes.xml 
b/documentation/ref-manual/ref-classes.xml
index f7b1126..6088b44 100644
--- a/documentation/ref-manual/ref-classes.xml
+++ b/documentation/ref-manual/ref-classes.xml
@@ -632,6 +632,34 @@
 
 
 
+
+deprecated.bbclass
+
+
+The deprecated class identifies recipes
+that for one reason or another are being considered for removal
+from their current layer. It may be due to persistent, known
+issues with the package, that there are newer, more feature-rich
+alternatives available in the same layer or that the recipe is
+no longer needed.  The recipe should provide a reason for the
+depercation and a suggestion to consumers of the recipe as to how
+to proceed.
+To use this class, inherit the class globally and set
+PNDEPRECATED
+for each recipe you intend to deprecate.
+Specify the PN
+value as a variable flag (varflag) and provide a reason, which is
+reported, if the package is requested to be built as the value.
+For example, if you want to deprecate a recipe called "exoticware",
+you add the following to your local.conf
+or distribution configuration:
+
+ INHERIT += "deprecated"
+ PNDEPRECATED[exoticware] = "'exoticware' is considered obsolete and has 
been replaced by 'standardware'.  'exoticware' may not appear in future 
releases."
+
+
+
+
 
 devshell.bbclass
 
diff --git a/documentation/ref-manual/ref-variables.xml 
b/documentation/ref-manual/ref-variables.xml
index f79cdd2..629d167 100644
--- a/documentation/ref-manual/ref-variables.xml
+++ b/documentation/ref-manual/ref-variables.xml
@@ -9920,6 +9920,34 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = 
"${INC_PR}.3"
 
 
 
+PNDEPRECATED
+
+PNDEPRECATED[doc] = "Lists recipes that may be removed in a 
future release or have more actively maintained alternatives."
+
+
+
+
+Lists recipes that may be removed in a future release or
+have more actively maintained alternatives.
+This variable works in conjunction with the
+deprecated
+class, which the recipe must inherit globally.
+
+
+
+To identify a recipe as deprecated, inherit the class
+globally and use the variable in your
+local.conf file.
+Here is an example that will show a warning when
+myrecipe is included in a project:
+
+ INHERIT += "deprecated"
+ PNDEPRECATED[myrecipe] = "Recipe is no longer actively maintained, you 
should consider using 'mynewrecipe' as an alternative."
+
+
+
+
+
 POPULATE_SDK_POST_HOST_COMMAND
 
 POPULATE_SDK_POST_HOST_COMMAND[doc] = "Specifies a list of 
functions to call once the OpenEmbedded build system has created host part of 
the SDK."
diff --git a/meta/classes/deprecated.bbclass b/meta/classes/deprecated.bbclass
new file mode 100644
index 000..3dcdadb
--- /dev/null
+++ b/meta/classes/deprecated.bbclass
@@ -0,0 +1,16 @@
+# To use the deprecated recipe check, a distribution should
+# include this class in the INHERIT_DISTRO
+#
+# Features:
+#
+# * To add a package to the deprecated list, set:
+#   PNDEPRECATED[pn] = "message"
+#
+
+addtask check_deprecated before do_fetch
+python do_check_deprecated () {
+deprecated = d.getVarFlag('PNDEPRECATED', d.getVar('PN', True), False)
+
+if deprecated:
+bb.warn("Recipe is deprecated: ", (deprecated))
+}
diff --git a/meta/conf/distro/defaultsetup.conf 
b/meta/conf/distro/defaultsetup.conf
index ca2f917..16ece3a 100644
--- a/meta/conf/distro/defaultsetup.conf
+++ b/meta/conf/distro/defaultsetup.conf
@@ -20,5 +20,6 @@ CACHE = "${TMPDIR}/cache/${TCMODE}-${TCLIBC}${@['', '/' + 
str(d.getVar('MACHINE'
 USER_CLASSES ?= ""
 PACKAGE_CLASSES ?= "package_ipk"
 INHERIT_BLACKLIST = "blacklist"
+INHERIT_DEPRECATED = "deprecated"
 INHERIT_DISTRO ?= "debian devshell sstate license remove-libtool"
-INHERIT += "${PACKAGE_CLASSES} 

[OE-core] [PATCH v2] oeqa/sdk/cases:Adds validation for SDK compatibility tests

[Francisco Pedraza]

Added validation for SDK compatibility tests with eSDK.
buildcvs, buildiptables, gcc, perl, python and buildgalculator based on target 
manifest file.
Running with: $ bitbake  -c testsdkext
[YOCTO #9090]

Signed-off-by: Francisco Pedraza 
---
 meta/lib/oeqa/sdk/cases/buildcvs.py| 8 
 meta/lib/oeqa/sdk/cases/buildgalculator.py | 4 +++-
 meta/lib/oeqa/sdk/cases/buildiptables.py   | 8 
 meta/lib/oeqa/sdk/cases/gcc.py | 6 --
 4 files changed, 15 insertions(+), 11 deletions(-)

diff --git a/meta/lib/oeqa/sdk/cases/buildcvs.py 
b/meta/lib/oeqa/sdk/cases/buildcvs.py
index 1ffd8cb..4b6a79d 100644
--- a/meta/lib/oeqa/sdk/cases/buildcvs.py
+++ b/meta/lib/oeqa/sdk/cases/buildcvs.py
@@ -15,10 +15,10 @@ class BuildCvsTest(OESDKTestCase):
 self.project.download_archive()
 
 machine = self.td.get("MACHINE")
-if not (self.tc.hasHostPackage("packagegroup-cross-canadian-%s" % 
machine) or 
-self.tc.hasHostPackage("gcc-runtime") or
-self.tc.hasHostPackage("libgcc") or
-self.tc.hasHostPackage("gcc-sanitizers")):
+if not (self.tc.hasTargetPackage("packagegroup-cross-canadian-%s" % 
machine) or 
+self.tc.hasTargetPackage("gcc-runtime") or
+self.tc.hasTargetPackage("libgcc") or
+self.tc.hasTargetPackage("gcc-sanitizers")):
 raise unittest.SkipTest("SDK doesn't contain a cross-canadian 
toolchain")
 
 def test_cvs(self):
diff --git a/meta/lib/oeqa/sdk/cases/buildgalculator.py 
b/meta/lib/oeqa/sdk/cases/buildgalculator.py
index 42e8ddb..76874ad 100644
--- a/meta/lib/oeqa/sdk/cases/buildgalculator.py
+++ b/meta/lib/oeqa/sdk/cases/buildgalculator.py
@@ -9,7 +9,9 @@ class GalculatorTest(OESDKTestCase):
 @classmethod
 def setUpClass(self):
 if not (self.tc.hasTargetPackage("gtk+3") or\
-self.tc.hasTargetPackage("libgtk-3.0")):
+self.tc.hasTargetPackage("libgtk-3.0") or
+self.tc.hasTargetPackage("gtk+") or
+self.tc.hasTargetPackage("matchbox-config-gtk")):
 raise unittest.SkipTest("GalculatorTest class: SDK don't support 
gtk+3")
 
 def test_galculator(self):
diff --git a/meta/lib/oeqa/sdk/cases/buildiptables.py 
b/meta/lib/oeqa/sdk/cases/buildiptables.py
index 621fb55..d7a0e6a 100644
--- a/meta/lib/oeqa/sdk/cases/buildiptables.py
+++ b/meta/lib/oeqa/sdk/cases/buildiptables.py
@@ -17,10 +17,10 @@ class BuildIptablesTest(OESDKTestCase):
 
 machine = self.td.get("MACHINE")
 
-if not (self.tc.hasHostPackage("packagegroup-cross-canadian-%s" % 
machine) or
-self.tc.hasHostPackage("gcc-runtime") or
-self.tc.hasHostPackage("libgcc") or
-self.tc.hasHostPackage("gcc-sanitizers")):
+if not (self.tc.hasTargetPackage("packagegroup-cross-canadian-%s" % 
machine) or
+self.tc.hasTargetPackage("gcc-runtime") or
+self.tc.hasTargetPackage("libgcc") or
+self.tc.hasTargetPackage("gcc-sanitizers")):
 raise unittest.SkipTest("SDK doesn't contain a cross-canadian 
toolchain")
 
 def test_iptables(self):
diff --git a/meta/lib/oeqa/sdk/cases/gcc.py b/meta/lib/oeqa/sdk/cases/gcc.py
index d869247..a183cfc 100644
--- a/meta/lib/oeqa/sdk/cases/gcc.py
+++ b/meta/lib/oeqa/sdk/cases/gcc.py
@@ -18,8 +18,10 @@ class GccCompileTest(OESDKTestCase):
 
 def setUp(self):
 machine = self.td.get("MACHINE")
-if not (self.tc.hasHostPackage("packagegroup-cross-canadian-%s" % 
machine) or
-self.tc.hasHostPackage("gcc-runtime")):
+if not (self.tc.hasTargetPackage("packagegroup-cross-canadian-%s" % 
machine) or
+self.tc.hasTargetPackage("gcc-runtime") or
+self.tc.hasTargetPackage("libgcc") or 
+self.tc.hasTargetPackage("gcc-sanitizers")):
 raise unittest.SkipTest("GccCompileTest class: SDK doesn't contain 
a cross-canadian toolchain")
 
 def test_gcc_compile(self):
-- 
1.8.3.1

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

Re: [OE-core] Patchwork not picking changes from the ML

[Gary Thomas]

On 2017-02-24 15:21, Patrick Ohly wrote:

On Wed, 2017-02-22 at 15:56 -0600, Jose Lamego wrote:


On 02/22/2017 02:55 PM, Michael Halstead wrote:

I've seen several issues with hooks. I was working on them yesterday and
will continue today.

These are currently managed by hand but we are moving them into
configuration management which should help keep them working consistently.


Michael: one syntax error in patchwork code was pulled into production
yesterday. This is the cause for missing patches. The error is fixed in
the Yocto repo now, please perform a server code update ASAP.

Martin: I will look at the UI issue you are describing and file a bug if
needed.


Would it perhaps make sense to reply to the original author with an
email confirming that his patch is now in Patchwork? It should include a
link to the patch series, too.

This could have several advantages:
  * submitters not aware of Patchwork or whether their target
currently uses it learn about it and then can follow the
progress of their patch
  * everyone gets a confirmation that the submission made it through
the various mail servers and Patchwork itself

It still relies on the original submitter to watch out for breakages in
the processes, but I guess that can't be avoided with an asynchronous,
mail-based process.



I would love to see this added to the process - +1 :-)

--

Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

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

Re: [OE-core] Yocto Bug#10456 discuss

[Bruce Ashfield]

On 2017-02-24 5:33 AM, Dengke Du wrote:

Hi Jussi and bruce

Yocto Bug#10456: X can not launch on qemumips64

I find the kernel 4.4 is ok, and on the latest 4.9 is ok, but on kernel
4.8 is failed.

This is because this commit in linux-yocto-4.8:

~~

commit d03516df837587368fc6e75591f6329c072b9eb5
Author: Matthew Leach 
Date:   Tue Jun 21 16:19:49 2016 +0100

tty: serial: 8250: add CON_CONSDEV to flags

When using the 8250 as a boot console and the main console results in
messages being printed twice.  The console framework will only
unregister boot consoles if a new console is registered with the
CON_CONSDEV flag set.

Set this flag for the univ8250 console to prevent double-registration.

Signed-off-by: Matthew Leach 
Signed-off-by: Greg Kroah-Hartman 

diff --git a/drivers/tty/serial/8250/8250_core.c
b/drivers/tty/serial/8250/8250_core.c
index fa823a5..dcf43f6 100644
--- a/drivers/tty/serial/8250/8250_core.c
+++ b/drivers/tty/serial/8250/8250_core.c
@@ -675,7 +675,7 @@ static struct console univ8250_console = {
.device = uart_console_device,
.setup  = univ8250_console_setup,
.match  = univ8250_console_match,
-   .flags  = CON_PRINTBUFFER | CON_ANYTIME,
+   .flags  = CON_PRINTBUFFER | CON_ANYTIME | CON_CONSDEV,
.index  = -1,
.data   = _reg,
 };

~~

The 4.9 has been reverted it, so backport that reverted patch can fix
this bug, but I don't know why this related to qemumips64?


Looks like the console is interfering with X claiming a VT for
startup.

But I wouldn't worry about the root cause all that much, if you've
bisected it, and it has been reverted already in newer kernels .. that
should be enough evidence for anyone.

Bruce



Thanks

Dengke



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

Re: [OE-core] [PATCH 24/24] systemtap: update to 3.1

[Burton, Ross]

On 22 February 2017 at 14:51, Alexander Kanavin <
alexander.kana...@linux.intel.com> wrote:
>
> Add support for python 3 probes

ERROR: QA Issue: lib64-systemtap: Files/directories were installed but not
shipped in any package:
  /usr/lib/python3.5/site-packages/HelperSDT-0.1.0-py3.5.egg-info

/usr/lib/python3.5/site-packages/HelperSDT-0.1.0-py3.5.egg-info/dependency_links.txt
  /usr/lib/python3.5/site-packages/HelperSDT-0.1.0-py3.5.egg-info/PKG-INFO

/usr/lib/python3.5/site-packages/HelperSDT-0.1.0-py3.5.egg-info/top_level.txt

/usr/lib/python3.5/site-packages/HelperSDT-0.1.0-py3.5.egg-info/SOURCES.txt
  /usr/lib/python3.5/site-packages/HelperSDT/__init__.py
  /usr/lib/python3.5/site-packages/HelperSDT/_
HelperSDT.cpython-35m-x86_64-linux-gnu.so
  /usr/lib/python3.5/site-packages/HelperSDT/__main__.py
  /usr/lib/python3.5/site-packages/HelperSDT/__pycache__

/usr/lib/python3.5/site-packages/HelperSDT/__pycache__/__init__.cpython-35.pyc

/usr/lib/python3.5/site-packages/HelperSDT/__pycache__/__main__.cpython-35.pyc

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

Re: [OE-core] Patchwork not picking changes from the ML

[Patrick Ohly]

On Wed, 2017-02-22 at 15:56 -0600, Jose Lamego wrote:
> 
> On 02/22/2017 02:55 PM, Michael Halstead wrote:
> > I've seen several issues with hooks. I was working on them yesterday and
> > will continue today.
> > 
> > These are currently managed by hand but we are moving them into
> > configuration management which should help keep them working consistently.
> 
> Michael: one syntax error in patchwork code was pulled into production
> yesterday. This is the cause for missing patches. The error is fixed in
> the Yocto repo now, please perform a server code update ASAP.
> 
> Martin: I will look at the UI issue you are describing and file a bug if
> needed.

Would it perhaps make sense to reply to the original author with an
email confirming that his patch is now in Patchwork? It should include a
link to the patch series, too.

This could have several advantages:
  * submitters not aware of Patchwork or whether their target
currently uses it learn about it and then can follow the
progress of their patch
  * everyone gets a confirmation that the submission made it through
the various mail servers and Patchwork itself

It still relies on the original submitter to watch out for breakages in
the processes, but I guess that can't be avoided with an asynchronous,
mail-based process.

-- 
Best Regards, Patrick Ohly

The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.



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

[OE-core] [PATCHv2] tar: CVE-2016-6321

[Sona Sarmadi]

Skip members whose names contain "..".

Reference:
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-6321

Upstream patch:
http://git.savannah.gnu.org/cgit/tar.git/commit/?id=7340f67b9860ea0531c1450e5aa261c50f671

Signed-off-by: Sona Sarmadi 
---
 meta/recipes-extended/tar/tar/CVE-2016-6321.patch | 66 +++
 meta/recipes-extended/tar/tar_1.29.bb |  1 +
 2 files changed, 67 insertions(+)
 create mode 100644 meta/recipes-extended/tar/tar/CVE-2016-6321.patch

diff --git a/meta/recipes-extended/tar/tar/CVE-2016-6321.patch 
b/meta/recipes-extended/tar/tar/CVE-2016-6321.patch
new file mode 100644
index 000..6d35bcc
--- /dev/null
+++ b/meta/recipes-extended/tar/tar/CVE-2016-6321.patch
@@ -0,0 +1,66 @@
+From 7340f67b9860ea0531c1450e5aa261c50f67165d Mon Sep 17 00:00:00 2001
+From: Paul Eggert 
+Date: Sat, 29 Oct 2016 21:04:40 -0700
+Subject: [PATCH] When extracting, skip ".." members
+
+* NEWS: Document this.
+* src/extract.c (extract_archive): Skip members whose names
+contain "..".
+
+CVE: CVE-2016-6321
+Upstream-Status: Backport
+
+Cherry picked from commit: 7340f67 When extracting, skip ".." members
+
+Signed-off-by: Sona Sarmadi 
+---
+ NEWS  | 8 +++-
+ src/extract.c | 8 
+ 2 files changed, 15 insertions(+), 1 deletion(-)
+
+diff --git a/NEWS b/NEWS
+index 501164a..fc97cfc 100644
+--- a/NEWS
 b/NEWS
+@@ -1,6 +1,12 @@
+-GNU tar NEWS - User visible changes. 2016-05-16
++GNU tar NEWS - User visible changes. 2016-10-29
+ Please send GNU tar bug reports to 
+ 
++* Member names containing '..' components are now skipped when extracting.
++
++This fixes tar's behavior to match its documentation, and is a bit
++safer when extracting untrusted archives over old files (an unsafe
++practice that the tar manual has long recommended against).
++
+ 
+ version 1.29 - Sergey Poznyakoff, 2016-05-16
+ 
+diff --git a/src/extract.c b/src/extract.c
+index f982433..7904148 100644
+--- a/src/extract.c
 b/src/extract.c
+@@ -1629,12 +1629,20 @@ extract_archive (void)
+ {
+   char typeflag;
+   tar_extractor_t fun;
++  bool skip_dotdot_name;
+ 
+   fatal_exit_hook = extract_finish;
+ 
+   set_next_block_after (current_header);
+ 
++  skip_dotdot_name = (!absolute_names_option
++&& contains_dot_dot (current_stat_info.orig_file_name));
++  if (skip_dotdot_name)
++ERROR ((0, 0, _("%s: Member name contains '..'"),
++  quotearg_colon (current_stat_info.orig_file_name)));
++
+   if (!current_stat_info.file_name[0]
++  || skip_dotdot_name
+   || (interactive_option
+ && !confirm ("extract", current_stat_info.file_name)))
+ {
+-- 
+1.9.1
+
diff --git a/meta/recipes-extended/tar/tar_1.29.bb 
b/meta/recipes-extended/tar/tar_1.29.bb
index efce57d..f22d9c9 100644
--- a/meta/recipes-extended/tar/tar_1.29.bb
+++ b/meta/recipes-extended/tar/tar_1.29.bb
@@ -8,6 +8,7 @@ LIC_FILES_CHKSUM = 
"file://COPYING;md5=d32239bcb673463ab874e80d47fae504"
 
 SRC_URI += "file://remove-gets.patch \
 file://musl_dirent.patch \
+file://CVE-2016-6321.patch \
"
 SRC_URI[md5sum] = "955cd533955acb1804b83fd70218da51"
 SRC_URI[sha256sum] = 
"236b11190c0a3a6885bdb8d61424f2b36a5872869aa3f7f695dea4b4843ae2f2"
-- 
1.9.1

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

[OE-core] [PATCH] guile: fix a bashism

[liu . ming50]

From: Ming Liu 

A following flaw was detected by verify-bashisms script:
..
meta/recipes-devtools/guile/guile_2.0.13.bb
possible bashism in guile_cross_config line 94 ($'...' should be "$(printf 
'...')"):

   echo '#!'`which ${BUILD_SYS}-guile`$' \\\n--no-auto-compile -e main 
-s\n!#\n(define %guile-build-info '\'\( \
   > ${B}/guile-config.cross
..

Fixed by removing $'...' from echo command, using a printf instead.

Signed-off-by: Ming Liu 
---
 meta/recipes-devtools/guile/guile_2.0.13.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-devtools/guile/guile_2.0.13.bb 
b/meta/recipes-devtools/guile/guile_2.0.13.bb
index c29e752..bb73dcf 100644
--- a/meta/recipes-devtools/guile/guile_2.0.13.bb
+++ b/meta/recipes-devtools/guile/guile_2.0.13.bb
@@ -90,7 +90,7 @@ guile_cross_config() {
then
# Create guile-config returning target values instead of native 
values
install -d ${SYSROOT_DESTDIR}${STAGING_BINDIR_CROSS}
-   echo '#!'`which ${BUILD_SYS}-guile`$' \\\n--no-auto-compile -e 
main -s\n!#\n(define %guile-build-info '\'\( \
+   printf '#!%s \\\n--no-auto-compile -e main -s\n!#\n(define 
%%guile-build-info %s(\n' $(which ${BUILD_SYS}-guile) "'" \
> ${B}/guile-config.cross
sed -n -e 's:^[ \t]*{[ \t]*":  (:' \
-e 's:",[ \t]*": . ":' \
-- 
1.9.1

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

[OE-core] Yocto Bug#10456 discuss

[Dengke Du]

Hi Jussi and bruce

Yocto Bug#10456: X can not launch on qemumips64

I find the kernel 4.4 is ok, and on the latest 4.9 is ok, but on kernel 
4.8 is failed.


This is because this commit in linux-yocto-4.8:

~~

commit d03516df837587368fc6e75591f6329c072b9eb5
Author: Matthew Leach 
Date:   Tue Jun 21 16:19:49 2016 +0100

tty: serial: 8250: add CON_CONSDEV to flags

When using the 8250 as a boot console and the main console results in
messages being printed twice.  The console framework will only
unregister boot consoles if a new console is registered with the
CON_CONSDEV flag set.

Set this flag for the univ8250 console to prevent double-registration.

Signed-off-by: Matthew Leach 
Signed-off-by: Greg Kroah-Hartman 

diff --git a/drivers/tty/serial/8250/8250_core.c 
b/drivers/tty/serial/8250/8250_core.c

index fa823a5..dcf43f6 100644
--- a/drivers/tty/serial/8250/8250_core.c
+++ b/drivers/tty/serial/8250/8250_core.c
@@ -675,7 +675,7 @@ static struct console univ8250_console = {
.device = uart_console_device,
.setup  = univ8250_console_setup,
.match  = univ8250_console_match,
-   .flags  = CON_PRINTBUFFER | CON_ANYTIME,
+   .flags  = CON_PRINTBUFFER | CON_ANYTIME | CON_CONSDEV,
.index  = -1,
.data   = _reg,
 };

~~

The 4.9 has been reverted it, so backport that reverted patch can fix 
this bug, but I don't know why this related to qemumips64?


Thanks

Dengke

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

[OE-core] [PATCH] buildstats.bbclass: Avoid index exception in /proc/PID/io parsing

[Daniel Lublin]

From: Pavel Modilaynen 

There is some probability (depends on system load) to get empty
or line containing "0" as the last line while reading /proc/PID/io.
Avoid build failure by checking if line contains separator
":" before split.

Signed-off-by: Pavel Modilaynen 
Signed-off-by: Daniel Lublin 
---
 meta/classes/buildstats.bbclass | 5 +
 1 file changed, 5 insertions(+)

diff --git a/meta/classes/buildstats.bbclass b/meta/classes/buildstats.bbclass
index 8d7b5988e3..960653c704 100644
--- a/meta/classes/buildstats.bbclass
+++ b/meta/classes/buildstats.bbclass
@@ -31,6 +31,11 @@ def get_process_cputime(pid):
 i = f.readline().strip()
 if not i:
 break
+if not ":" in i:
+# one more extra line is appended (empty or containing "0")
+# most probably due to race condition in kernel while
+# updating IO stats
+break
 i = i.split(": ")
 iostats[i[0]] = i[1]
 resources = resource.getrusage(resource.RUSAGE_SELF)
-- 
2.11.1

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

Re: [OE-core] [PATCH 0/5] Packages upgrade

[Robert Yang]

Mike Crowe has done the upgrade for ccache, so I removed it from the PULL:

The following changes since commit 65cfc8aca3ff7e39453977a0215a350d13cb85ef:

  libva: Find the correct wayland-scanner (2017-02-23 12:29:21 -0800)

are available in the git repository at:

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

Robert Yang (4):
  strace: 4.15 -> 4.16
  guile: 2.0.13 -> 2.0.14
  slang: 2.3.1 -> 2.3.1a
  file: 5.29 -> 5.30


// Robert

On 02/22/2017 09:44 AM, Robert Yang wrote:

The following changes since commit def3800c7e58d9d1b54ea1df27b190a0f6d1d544:

  layer.conf: bump version for change in eSDK selftest behaviour (2017-02-19 
09:38:59 -0800)

are available in the git repository at:

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

Robert Yang (5):
  strace: 4.15 -> 4.16
  guile: 2.0.13 -> 2.0.14
  slang: 2.3.1 -> 2.3.1a
  ccache: 3.3.3 -> 3.3.4
  file: 5.29 -> 5.30

 .../ccache/{ccache_3.3.3.bb => ccache_3.3.4.bb}|  6 +--
 .../file/{file_5.29.bb => file_5.30.bb}|  2 +-
 .../guile/{guile_2.0.13.bb => guile_2.0.14.bb} |  4 +-
 .../strace/strace/Makefile-ptest.patch | 13 +++---
 .../strace/strace/disable-git-version-gen.patch| 18 
 .../strace/strace/use-asm-sgidefs.h.patch  | 51 --
 .../strace/{strace_4.15.bb => strace_4.16.bb}  |  7 ++-
 .../slang/{slang_2.3.1.bb => slang_2.3.1a.bb}  |  4 +-
 8 files changed, 27 insertions(+), 78 deletions(-)
 rename meta/recipes-devtools/ccache/{ccache_3.3.3.bb => ccache_3.3.4.bb} (48%)
 rename meta/recipes-devtools/file/{file_5.29.bb => file_5.30.bb} (96%)
 rename meta/recipes-devtools/guile/{guile_2.0.13.bb => guile_2.0.14.bb} (97%)
 delete mode 100644 meta/recipes-devtools/strace/strace/use-asm-sgidefs.h.patch
 rename meta/recipes-devtools/strace/{strace_4.15.bb => strace_4.16.bb} (84%)
 rename meta/recipes-extended/slang/{slang_2.3.1.bb => slang_2.3.1a.bb} (93%)


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

[OE-core] [RFC PATCH 0/1] core-image-minimal-initramfs: set QB_DEFAULT_FSTYPE

[Robert Yang]

Hi,

This is a RFC patch, my concern is that QB_DEFAULT_FSTYPE is only used
for qemu boot, it is harmless for non qemu machines, so I assume that it
is OK to set it in the image recipe.

There are also other image recipes have the similar issues:
WARNING: meta/recipes-core/images/core-image-minimal-initramfs.bb: 
QB_DEFAULT_FSTYPE 'ext4' is not in IMAGE_FSTYPES 'cpio.gz'.
WARNING: meta/recipes-extended/images/core-image-testmaster-initramfs.bb: 
QB_DEFAULT_FSTYPE 'ext4' is not in IMAGE_FSTYPES 'cpio.gz'.
WARNING: meta-selftest/recipes-test/images/wic-image-minimal.bb: 
QB_DEFAULT_FSTYPE 'ext4' is not in IMAGE_FSTYPES 'wic'.
WARNING: meta/recipes-core/images/core-image-tiny-initramfs.bb: 
QB_DEFAULT_FSTYPE 'ext4' is not in IMAGE_FSTYPES 'cpio.gz wic'.
WARNING: meta/recipes-core/images/build-appliance-image_15.0.0.bb: 
QB_DEFAULT_FSTYPE 'ext4' is not in IMAGE_FSTYPES 'vmdk'.

I added the WARNING locally to do the checking. I will fix others if this patch 
is fine.

BTW, I'm working runqemu testcases (oe-selftest -r runqemu) recently,
please feel free to give your comments on what should be tested.

https://bugzilla.yoctoproject.org/show_bug.cgi?id=10249

// Robert

The following changes since commit 65cfc8aca3ff7e39453977a0215a350d13cb85ef:

  libva: Find the correct wayland-scanner (2017-02-23 12:29:21 -0800)

are available in the git repository at:

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

Robert Yang (1):
  core-image-minimal-initramfs: set QB_DEFAULT_FSTYPE

 meta/recipes-core/images/core-image-minimal-initramfs.bb | 2 ++
 1 file changed, 2 insertions(+)

-- 
2.10.2

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

[OE-core] [RFC PATCH 1/1] core-image-minimal-initramfs: set QB_DEFAULT_FSTYPE

[Robert Yang]

Fixed:
MACHINE = "qemux86"
$ bitbake core-image-minimal-initramfs
$ runqemu qemux86 nographic
[snip]
Exception: Failed to find rootfs: 
tmp/deploy/images/qemux86/core-image-minimal-initramfs-qemux86-20170224082533*.ext4
 or tmp/deploy/images/qemux86/core-image-minimal-initramfs-qemux86*.ext4
[snip]

This is because core-image-minimal-initramfs doesn't generate ext4 image which
is the default value or QB_DEFAULT_FSTYPE, it only generates cpio.gz.

Signed-off-by: Robert Yang 
---
 meta/recipes-core/images/core-image-minimal-initramfs.bb | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/meta/recipes-core/images/core-image-minimal-initramfs.bb 
b/meta/recipes-core/images/core-image-minimal-initramfs.bb
index 5794a25..1ea3490 100644
--- a/meta/recipes-core/images/core-image-minimal-initramfs.bb
+++ b/meta/recipes-core/images/core-image-minimal-initramfs.bb
@@ -16,6 +16,8 @@ LICENSE = "MIT"
 IMAGE_FSTYPES = "${INITRAMFS_FSTYPES}"
 inherit core-image
 
+QB_DEFAULT_FSTYPE = "cpio.gz"
+
 IMAGE_ROOTFS_SIZE = "8192"
 IMAGE_ROOTFS_EXTRA_SPACE = "0"
 
-- 
2.10.2

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

Re: [OE-core] [PATCH] deprecated.bbclass: Add a PNDEPRECATED variable for recipes

[Martin Jansa]

> If nobody speaks up within some
amount of time the maintainer considers reasonable (I'm thinking a Yocto
release
cycle) then it's fair game to remove the recipe in question.

Maybe this is different case with at least some PNBLACKLIST entries we
currently have, but
I don't remove PNBLACKLISTed recipes, because as we discussed it's always
easier to unblacklist
recipe from e.g. DISTRO config if the issue doesn't affect you for whatever
reason and causes
less churn in the metadata when it gets unblacklisted.

And many PNBLACKLISTed recipes are also abandonware.

So my question is, if we will remove PNDEPRECATed recipes after one cycle,
should we start
removing PNBLACKLISTed recipes as well (maybe after 2 cycles?). In both
cases it might backfire
when someone will fail to find recipe for his favorite abandonware and will
try to add completely
new recipe for it, or we see someone restoring these recipes (e.g. in own
layers instead of fixing
the PNBLACKLIST/PNDEPRECATED reasons in original layer).

On Fri, Feb 24, 2017 at 5:55 AM, Khem Raj  wrote:

>
> On Thu, Feb 23, 2017 at 8:00 PM Joe MacDonald 
> wrote:
>
>> Based on the blacklist behaviour, recipes can be tagged as deprecated.
>> Such recipes will produce a warning message when included in a build but
>> unlike blacklisted recipes, the build will continue.
>
>
> Perhaps this should also be documented in manuals
>
>>
>>
>> Signed-off-by: Joe MacDonald 
>> ---
>>
>> I threw this together a long time ago and never got around to sending it
>> out for
>> consideration, but after the excitement last week and this, I got
>> thinking about
>> it again and thought it might be useful.  My specific use-case for this is
>> recipes I see in meta-networking that I know are largely abandonware but
>> that I
>> don't want to completely throw out without giving some kind of heads up.
>> Obviously this is purely informational, there's no mechanism set up for
>> purging
>> deprecated recipes, that's intended to be a maintainer activity, but the
>> idea
>> would be that the maintainer would flag a recipe as deprecated (probably
>> when
>> it's become more trouble than it seems to be worth) and thereafter users
>> would
>> have fair warning that this thing is on notice.  If nobody speaks up
>> within some
>> amount of time the maintainer considers reasonable (I'm thinking a Yocto
>> release
>> cycle) then it's fair game to remove the recipe in question.
>>
>>  meta/classes/deprecated.bbclass| 16 
>>  meta/conf/distro/defaultsetup.conf |  3 ++-
>>  2 files changed, 18 insertions(+), 1 deletion(-)
>>  create mode 100644 meta/classes/deprecated.bbclass
>>
>> diff --git a/meta/classes/deprecated.bbclass b/meta/classes/deprecated.
>> bbclass
>> new file mode 100644
>> index 000..3dcdadb
>> --- /dev/null
>> +++ b/meta/classes/deprecated.bbclass
>> @@ -0,0 +1,16 @@
>> +# To use the deprecated recipe check, a distribution should
>> +# include this class in the INHERIT_DISTRO
>> +#
>> +# Features:
>> +#
>> +# * To add a package to the deprecated list, set:
>> +#   PNDEPRECATED[pn] = "message"
>> +#
>> +
>> +addtask check_deprecated before do_fetch
>> +python do_check_deprecated () {
>> +deprecated = d.getVarFlag('PNDEPRECATED', d.getVar('PN', True),
>> False)
>> +
>> +if deprecated:
>> +bb.warn("Recipe is deprecated: ", (deprecated))
>> +}
>> diff --git a/meta/conf/distro/defaultsetup.conf b/meta/conf/distro/
>> defaultsetup.conf
>> index ca2f917..16ece3a 100644
>> --- a/meta/conf/distro/defaultsetup.conf
>> +++ b/meta/conf/distro/defaultsetup.conf
>> @@ -20,5 +20,6 @@ CACHE = "${TMPDIR}/cache/${TCMODE}-${TCLIBC}${@['',
>> '/' + str(d.getVar('MACHINE'
>>  USER_CLASSES ?= ""
>>  PACKAGE_CLASSES ?= "package_ipk"
>>  INHERIT_BLACKLIST = "blacklist"
>> +INHERIT_DEPRECATED = "deprecated"
>>  INHERIT_DISTRO ?= "debian devshell sstate license remove-libtool"
>> -INHERIT += "${PACKAGE_CLASSES} ${USER_CLASSES} ${INHERIT_DISTRO}
>> ${INHERIT_BLACKLIST}"
>> +INHERIT += "${PACKAGE_CLASSES} ${USER_CLASSES} ${INHERIT_DISTRO}
>> ${INHERIT_BLACKLIST} ${INHERIT_DEPRECATED}"
>> --
>> 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
>
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] tar: CVE-2016-6321

[Sona Sarmadi]

Skip members whose names contain "..".

Reference:
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-6321

Upstream patch:
http://git.savannah.gnu.org/cgit/tar.git/commit/?id=7340f67b9860ea0531c1450e5aa261c50f671

Signed-off-by: Sona Sarmadi 
---
 meta/recipes-extended/tar/tar/CVE-2016-6321.patch | 58 +++
 meta/recipes-extended/tar/tar_1.29.bb |  1 +
 2 files changed, 59 insertions(+)
 create mode 100644 meta/recipes-extended/tar/tar/CVE-2016-6321.patch

diff --git a/meta/recipes-extended/tar/tar/CVE-2016-6321.patch 
b/meta/recipes-extended/tar/tar/CVE-2016-6321.patch
new file mode 100644
index 000..4705d2d
--- /dev/null
+++ b/meta/recipes-extended/tar/tar/CVE-2016-6321.patch
@@ -0,0 +1,58 @@
+From 7340f67b9860ea0531c1450e5aa261c50f67165d Mon Sep 17 00:00:00 2001
+From: Paul Eggert 
+Date: Sat, 29 Oct 2016 21:04:40 -0700
+Subject: When extracting, skip ".." members
+
+* NEWS: Document this.
+* src/extract.c (extract_archive): Skip members whose names
+contain "..".
+
+CVE: CVE-2016-6321
+Upstream-Status: Backport
+
+Signed-off-by: Sona Sarmadi 
+
+diff -Nurp a/NEWS b/NEWS
+--- a/NEWS 2016-05-16 10:51:12.0 +0200
 b/NEWS 2017-02-24 07:51:53.279524073 +0100
+@@ -1,9 +1,15 @@
+-GNU tar NEWS - User visible changes. 2016-05-16
++GNU tar NEWS - User visible changes. 2016-10-29
+ Please send GNU tar bug reports to 
+ 
+ 
+ version 1.29 - Sergey Poznyakoff, 2016-05-16
+ 
++CVE-2016-6321
++* Member names containing '..' components are now skipped when extracting.
++This fixes tar's behavior to match its documentation, and is a bit
++safer when extracting untrusted archives over old files (an unsafe
++practice that the tar manual has long recommended against).
++
+ * New options: --verbatim-files-from, --no-verbatim-files-from
+ 
+ The --verbatim-files-from option instructs tar to treat each line read
+diff -Nurp a/src/extract.c b/src/extract.c
+--- a/src/extract.c2016-01-20 10:26:32.0 +0100
 b/src/extract.c2017-02-24 07:41:27.990942240 +0100
+@@ -1629,12 +1629,20 @@ extract_archive (void)
+ {
+   char typeflag;
+   tar_extractor_t fun;
++  bool skip_dotdot_name;
+ 
+   fatal_exit_hook = extract_finish;
+ 
+   set_next_block_after (current_header);
+ 
++  skip_dotdot_name = (!absolute_names_option
++&& contains_dot_dot (current_stat_info.orig_file_name));
++  if (skip_dotdot_name)
++ERROR ((0, 0, _("%s: Member name contains '..'"),
++  quotearg_colon (current_stat_info.orig_file_name)));
++
+   if (!current_stat_info.file_name[0]
++  || skip_dotdot_name
+   || (interactive_option
+ && !confirm ("extract", current_stat_info.file_name)))
+ {
diff --git a/meta/recipes-extended/tar/tar_1.29.bb 
b/meta/recipes-extended/tar/tar_1.29.bb
index efce57d..f22d9c9 100644
--- a/meta/recipes-extended/tar/tar_1.29.bb
+++ b/meta/recipes-extended/tar/tar_1.29.bb
@@ -8,6 +8,7 @@ LIC_FILES_CHKSUM = 
"file://COPYING;md5=d32239bcb673463ab874e80d47fae504"
 
 SRC_URI += "file://remove-gets.patch \
 file://musl_dirent.patch \
+file://CVE-2016-6321.patch \
"
 SRC_URI[md5sum] = "955cd533955acb1804b83fd70218da51"
 SRC_URI[sha256sum] = 
"236b11190c0a3a6885bdb8d61424f2b36a5872869aa3f7f695dea4b4843ae2f2"
-- 
1.9.1

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

[OE-core] [PATCH] webkitgtk: update to 2.14.5

[Alexander Kanavin]

Remove a reference to WebKit/LICENSE, as the directory is not there anymore
(and the LICENSE file in it hasn't been moved somewhere else) - it was
a relic of webkit 1.x era.

Signed-off-by: Alexander Kanavin 
---
 .../recipes-sato/webkit/{webkitgtk_2.14.2.bb => webkitgtk_2.14.5.bb} | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)
 rename meta/recipes-sato/webkit/{webkitgtk_2.14.2.bb => webkitgtk_2.14.5.bb} 
(96%)

diff --git a/meta/recipes-sato/webkit/webkitgtk_2.14.2.bb 
b/meta/recipes-sato/webkit/webkitgtk_2.14.5.bb
similarity index 96%
rename from meta/recipes-sato/webkit/webkitgtk_2.14.2.bb
rename to meta/recipes-sato/webkit/webkitgtk_2.14.5.bb
index 6338101395a..5fb07da26d9 100644
--- a/meta/recipes-sato/webkit/webkitgtk_2.14.2.bb
+++ b/meta/recipes-sato/webkit/webkitgtk_2.14.5.bb
@@ -4,7 +4,6 @@ BUGTRACKER = "http://bugs.webkit.org/;
 
 LICENSE = "BSD & LGPLv2+"
 LIC_FILES_CHKSUM = 
"file://Source/JavaScriptCore/COPYING.LIB;md5=d0c6d6397a5d84286dda758da57bd691 \
-
file://Source/WebKit/LICENSE;md5=4646f90082c40bcf298c285f8bab0b12 \
 
file://Source/WebCore/LICENSE-APPLE;md5=4646f90082c40bcf298c285f8bab0b12 \

file://Source/WebCore/LICENSE-LGPL-2;md5=36357ffde2b64ae177b2494445b79d21 \

file://Source/WebCore/LICENSE-LGPL-2.1;md5=a778a33ef338abbaf8b8a7c36b6eec80 \
@@ -23,8 +22,8 @@ SRC_URI = 
"http://www.webkitgtk.org/releases/${BPN}-${PV}.tar.xz \
file://x32_support.patch \
"
 
-SRC_URI[md5sum] = "2fe3cadbc546d93ca68a13756c2be015"
-SRC_URI[sha256sum] = 
"2edbcbd5105046aea55af9671c4de8deedb5b0e3567c618034d440a760675556"
+SRC_URI[md5sum] = "7fe3cb2699e64f969b285823c5ae2516"
+SRC_URI[sha256sum] = 
"3ca8f1c33a9b43d6c753dcac1c0788656930e06382b10fdf5c2805ea8f96369f"
 
 inherit cmake pkgconfig gobject-introspection perlnative distro_features_check 
upstream-version-is-even gtk-doc
 
-- 
2.11.0

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

Re: [OE-core] [PATCH 20/24] libiconv: remove recipe

[Alexander Kanavin]

On 02/24/2017 01:04 AM, Burton, Ross wrote:

> ERROR: Nothing PROVIDES 'virtual/nativesdk-libiconv' (but
> 
virtual:nativesdk:/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-qa-extras/build/meta/recipes-core/gettext/gettext_0.19.8.1.bb

> DEPENDS on or otherwise requires it)

It seems that nativesdk-glibc is not providing it. We
should fix that


Oh, this was with  SDKMACHINE = "i686-mingw32" which likely makes a
difference but it's too late for me to make an informed opinion. :)


Must be. Compiling nativesdk-gettext works perfectly fine on plain poky, 
so it's mingw stuff that needs to be fixed (or take libiconv recipe if 
they need it).


Alex

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

[OE-core] Failed to boot core-image-minimal-qemux86-64.cpio.gz

[Robert Yang]

Does anyone know the reason, please ?

$ runqemu nographic tmp/deploy/images/qemux86-64 core-image-minimal cpio.gz

[6.375829] ALSA device list:
[6.375990]   No soundcards found.
[6.429357] Freeing unused kernel memory: 1376K (81f1f000 - 
82077000)

[6.429708] Write protecting the kernel read-only data: 14336k
[6.433613] Freeing unused kernel memory: 704K (88000195 - 
880001a0)
[6.458184] Freeing unused kernel memory: 1124K (880001ce7000 - 
880001e0)

INIT: version 2.88 booting
[6.497317] usb 1-1: new full-speed USB device number 2 using uhci_hcd
[6.682837] input: QEMU QEMU USB Tablet as 
/devices/pci:00/:00:01.2/usb1/1-1/1-1:1.0/0003:0627:0001.0001/input/input4
[6.686286] hid-generic 0003:0627:0001.0001: input: USB HID v0.01 Pointer 
[QEMU QEMU USB Tablet] on usb-:00:01.2-1/input0
[6.851785] input: ImExPS/2 Generic Explorer Mouse as 
/devices/platform/i8042/serio1/input/input3

[   11.744796] uvesafb: 5000 ms task timeout, infinitely waiting.
[   16.864725] uvesafb: 5000 ms task timeout, infinitely waiting.
[   21.984430] uvesafb: 5000 ms task timeout, infinitely waiting.
[   27.104459] uvesafb: 5000 ms task timeout, infinitely waiting.
[   32.224577] uvesafb: 5000 ms task timeout, infinitely waiting.
[   37.344413] uvesafb: 5000 ms task timeout, infinitely waiting.
[   42.464578] uvesafb: 5000 ms task timeout, infinitely waiting.
[   47.584458] uvesafb: 5000 ms task timeout, infinitely waiting.


--
Thanks

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