Re: [OE-core] Crazy display

[Gary Thomas]

On 2016-09-16 00:00, Paul Eggleton wrote:

On Thu, 15 Sep 2016 22:51:47 Richard Purdie wrote:

On Fri, 2016-09-16 at 08:41 +1200, Paul Eggleton wrote:

On Thu, 15 Sep 2016 22:26:09 Gary Thomas wrote:

On 2016-09-15 22:12, Burton, Ross wrote:

On 15 September 2016 at 21:03, Paul Eggleton





wrote:

Are you guys perhaps using the same terminal application?
Using screen
/ tmux / anything similar? (I'm using screen here and haven't
experienced problems though.)

I'm using iTerm2 on a Mac to run normal SSH to my Linux box. No
screen/tmux/etc.


Pretty much the same for me - just SSH in an xterm window.


Hmm, I'm still no closer then.

Does it just start happening at some point in the middle of a build?
Or right
from the start?


Seems to happen at various points during the build. Looks like bad
timing of console updates so can happen at any point, I'd see evidence
its happened multiple times in a given build.


This is bizarre. Clearly something is different between your systems and mine
:/


I've only seen it when my build machine was quite busy (yesterday
when I first noticed, I had three builds going at once)

--

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] [PATCH 2/2] package_manager.py: Change diagnostic messages per IRC

[Paul Eggleton]

On Thu, 15 Sep 2016 17:47:39 Mark Hatle wrote:
> Based on a discussion with IRC user: Ulfalizer
> 
> It was suggested that removing the diagnostic list, and replacing it with a
> simple hint to what might be causing the problem was a better solution.
> 
> Signed-off-by: Mark Hatle 
> ---
>  meta/lib/oe/package_manager.py | 20 
>  1 file changed, 12 insertions(+), 8 deletions(-)
> 
> diff --git a/meta/lib/oe/package_manager.py b/meta/lib/oe/package_manager.py
> index d609593..dc88f62 100644
> --- a/meta/lib/oe/package_manager.py
> +++ b/meta/lib/oe/package_manager.py
> @@ -838,11 +838,13 @@ class RpmPM(PackageManager):
>  new_pkg = self._search_pkg_name_in_feeds(subst,
> feed_archs) if not new_pkg:
>  # Failed to translate, package not found!
> -err_msg = '%s not found in the %s feeds (%s).' % \
> -  (pkg, mlib, " ".join(feed_archs))
> +err_msg = '%s not found in the %s feeds (%s) in
> %s.' % \ +  (pkg, mlib, "
> ".join(feed_archs), self.d.getVar('DEPLOY_DIR_RPM', True)) if not
> attempt_only:
> -bb.error("List of available packages: " + "
> ".join(self.fullpkglist)) -bb.fatal(err_msg)
> +bb.error(err_msg)
> +bb.fatal("This is often caused by an empty
> package declared " \ + "in a recipe's
> PACKAGES variable. (Empty packages are " \ +   
>  "not constructed unless ALLOW_EMPTY_ = '1' is used.)")
> bb.warn(err_msg)
>  else:
>  new_pkgs.append(new_pkg)
> @@ -855,11 +857,13 @@ class RpmPM(PackageManager):
>  default_archs = self.ml_prefix_list['default']
>  new_pkg = self._search_pkg_name_in_feeds(pkg,
> default_archs) if not new_pkg:
> -err_msg = '%s not found in the feeds (%s).' % \
> -  (pkg, ' '.join(default_archs))
> +err_msg = '%s not found in the feeds (%s) in %s.' % \
> +  (pkg, " ".join(default_archs),
> self.d.getVar('DEPLOY_DIR_RPM', True)) if not attempt_only:
> -bb.error("List of available packages: " + "
> ".join(self.fullpkglist)) -bb.fatal(err_msg)
> +bb.error(err_msg)
> +bb.fatal("This is often caused by an empty package
> declared " \ + "in a recipe's PACKAGES
> variable. (Empty packages are " \ + "not
> constructed unless ALLOW_EMPTY_ = '1' is used.)") bb.warn(err_msg)
>  else:
>  new_pkgs.append(new_pkg)

Thanks for sorting this out - it's always bothered me a little bit every time 
I came across it (no doubt this came across in our discussion, I hope I wasn't 
too impertinent).

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 2/2] package_manager.py: Change diagnostic messages per IRC

[Ulf Magnusson]

On Fri, Sep 16, 2016 at 12:47 AM, Mark Hatle  wrote:
> Based on a discussion with IRC user: Ulfalizer
>
> It was suggested that removing the diagnostic list, and replacing it with a
> simple hint to what might be causing the problem was a better solution.
>
> Signed-off-by: Mark Hatle 
> ---
>  meta/lib/oe/package_manager.py | 20 
>  1 file changed, 12 insertions(+), 8 deletions(-)
>
> diff --git a/meta/lib/oe/package_manager.py b/meta/lib/oe/package_manager.py
> index d609593..dc88f62 100644
> --- a/meta/lib/oe/package_manager.py
> +++ b/meta/lib/oe/package_manager.py
> @@ -838,11 +838,13 @@ class RpmPM(PackageManager):
>  new_pkg = self._search_pkg_name_in_feeds(subst, 
> feed_archs)
>  if not new_pkg:
>  # Failed to translate, package not found!
> -err_msg = '%s not found in the %s feeds (%s).' % \
> -  (pkg, mlib, " ".join(feed_archs))
> +err_msg = '%s not found in the %s feeds (%s) in %s.' 
> % \
> +  (pkg, mlib, " ".join(feed_archs), 
> self.d.getVar('DEPLOY_DIR_RPM', True))
>  if not attempt_only:
> -bb.error("List of available packages: " + " 
> ".join(self.fullpkglist))
> -bb.fatal(err_msg)
> +bb.error(err_msg)
> +bb.fatal("This is often caused by an empty 
> package declared " \
> + "in a recipe's PACKAGES variable. 
> (Empty packages are " \
> + "not constructed unless 
> ALLOW_EMPTY_ = '1' is used.)")
>  bb.warn(err_msg)
>  else:
>  new_pkgs.append(new_pkg)
> @@ -855,11 +857,13 @@ class RpmPM(PackageManager):
>  default_archs = self.ml_prefix_list['default']
>  new_pkg = self._search_pkg_name_in_feeds(pkg, default_archs)
>  if not new_pkg:
> -err_msg = '%s not found in the feeds (%s).' % \
> -  (pkg, ' '.join(default_archs))
> +err_msg = '%s not found in the feeds (%s) in %s.' % \
> +  (pkg, " ".join(default_archs), 
> self.d.getVar('DEPLOY_DIR_RPM', True))
>  if not attempt_only:
> -bb.error("List of available packages: " + " 
> ".join(self.fullpkglist))
> -bb.fatal(err_msg)
> +bb.error(err_msg)
> +bb.fatal("This is often caused by an empty package 
> declared " \
> + "in a recipe's PACKAGES variable. (Empty 
> packages are " \
> + "not constructed unless ALLOW_EMPTY_ = 
> '1' is used.)")
>  bb.warn(err_msg)
>  else:
>  new_pkgs.append(new_pkg)
> --
> 2.5.5
>
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core

Looks good to me.

Maybe the hint could be stored in a variable to avoid repeating it, or
a helper function factored out. ALLOW_EMPTY_ = "1" instead of '1'
avoids encouraging random single quotes in files too.

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

[OE-core] [PATCH 1/2] package_manager.py: Adjust error message order

[Mark Hatle]

Move the debug before the error (as it can take many pages.)  This makes it
much easier for the user to see the actual error message as it is still on
the screen.

Signed-off-by: Mark Hatle 
---
 meta/lib/oe/package_manager.py | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/meta/lib/oe/package_manager.py b/meta/lib/oe/package_manager.py
index 2802254..d609593 100644
--- a/meta/lib/oe/package_manager.py
+++ b/meta/lib/oe/package_manager.py
@@ -838,10 +838,10 @@ class RpmPM(PackageManager):
 new_pkg = self._search_pkg_name_in_feeds(subst, feed_archs)
 if not new_pkg:
 # Failed to translate, package not found!
-err_msg = '%s not found in the %s feeds (%s).\n' % \
+err_msg = '%s not found in the %s feeds (%s).' % \
   (pkg, mlib, " ".join(feed_archs))
 if not attempt_only:
-err_msg += " ".join(self.fullpkglist)
+bb.error("List of available packages: " + " 
".join(self.fullpkglist))
 bb.fatal(err_msg)
 bb.warn(err_msg)
 else:
@@ -855,10 +855,10 @@ class RpmPM(PackageManager):
 default_archs = self.ml_prefix_list['default']
 new_pkg = self._search_pkg_name_in_feeds(pkg, default_archs)
 if not new_pkg:
-err_msg = '%s not found in the base feeds (%s).\n' % \
+err_msg = '%s not found in the feeds (%s).' % \
   (pkg, ' '.join(default_archs))
 if not attempt_only:
-err_msg += " ".join(self.fullpkglist)
+bb.error("List of available packages: " + " 
".join(self.fullpkglist))
 bb.fatal(err_msg)
 bb.warn(err_msg)
 else:
-- 
2.5.5

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

[OE-core] [PATCH 2/2] package_manager.py: Change diagnostic messages per IRC

[Mark Hatle]

Based on a discussion with IRC user: Ulfalizer

It was suggested that removing the diagnostic list, and replacing it with a
simple hint to what might be causing the problem was a better solution.

Signed-off-by: Mark Hatle 
---
 meta/lib/oe/package_manager.py | 20 
 1 file changed, 12 insertions(+), 8 deletions(-)

diff --git a/meta/lib/oe/package_manager.py b/meta/lib/oe/package_manager.py
index d609593..dc88f62 100644
--- a/meta/lib/oe/package_manager.py
+++ b/meta/lib/oe/package_manager.py
@@ -838,11 +838,13 @@ class RpmPM(PackageManager):
 new_pkg = self._search_pkg_name_in_feeds(subst, feed_archs)
 if not new_pkg:
 # Failed to translate, package not found!
-err_msg = '%s not found in the %s feeds (%s).' % \
-  (pkg, mlib, " ".join(feed_archs))
+err_msg = '%s not found in the %s feeds (%s) in %s.' % 
\
+  (pkg, mlib, " ".join(feed_archs), 
self.d.getVar('DEPLOY_DIR_RPM', True))
 if not attempt_only:
-bb.error("List of available packages: " + " 
".join(self.fullpkglist))
-bb.fatal(err_msg)
+bb.error(err_msg)
+bb.fatal("This is often caused by an empty package 
declared " \
+ "in a recipe's PACKAGES variable. (Empty 
packages are " \
+ "not constructed unless ALLOW_EMPTY_ 
= '1' is used.)")
 bb.warn(err_msg)
 else:
 new_pkgs.append(new_pkg)
@@ -855,11 +857,13 @@ class RpmPM(PackageManager):
 default_archs = self.ml_prefix_list['default']
 new_pkg = self._search_pkg_name_in_feeds(pkg, default_archs)
 if not new_pkg:
-err_msg = '%s not found in the feeds (%s).' % \
-  (pkg, ' '.join(default_archs))
+err_msg = '%s not found in the feeds (%s) in %s.' % \
+  (pkg, " ".join(default_archs), 
self.d.getVar('DEPLOY_DIR_RPM', True))
 if not attempt_only:
-bb.error("List of available packages: " + " 
".join(self.fullpkglist))
-bb.fatal(err_msg)
+bb.error(err_msg)
+bb.fatal("This is often caused by an empty package 
declared " \
+ "in a recipe's PACKAGES variable. (Empty 
packages are " \
+ "not constructed unless ALLOW_EMPTY_ = 
'1' is used.)")
 bb.warn(err_msg)
 else:
 new_pkgs.append(new_pkg)
-- 
2.5.5

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

Re: [OE-core] [PATCH v2 2/2] util-linux: Disable bfs support

[Randy MacLeod]

On 2016-09-15 05:11 PM, Patrick Williams wrote:

Disable building of mkfs.bfs, which is used to create
BFS file-systems used by SCO UnixWare.  This is highly
unlikely to be utilized and there are otherwise no
references to 'bfs' throughout the rest of the tree.



SCO, yeah not many people using that...
some people (that I work with) would remove the code upstream even!

Thanks Patrick.

../Randy



Signed-off-by: Patrick Williams 
---
 meta/recipes-core/util-linux/util-linux.inc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-core/util-linux/util-linux.inc 
b/meta/recipes-core/util-linux/util-linux.inc
index 608f198..c635502 100644
--- a/meta/recipes-core/util-linux/util-linux.inc
+++ b/meta/recipes-core/util-linux/util-linux.inc
@@ -46,7 +46,7 @@ SHARED_EXTRA_OECONF = "--disable-use-tty-group \
--disable-vipw --disable-newgrp --disable-chfn-chsh \
--enable-write --enable-mount \
--enable-libuuid --enable-libblkid --enable-fsck \
-   --disable-minix --without-udev \
+   --disable-minix --disable-bfs --without-udev \
usrsbin_execdir='${sbindir}' \
 "





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

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

Re: [OE-core] Crazy display

[Paul Eggleton]

On Thu, 15 Sep 2016 22:51:47 Richard Purdie wrote:
> On Fri, 2016-09-16 at 08:41 +1200, Paul Eggleton wrote:
> > On Thu, 15 Sep 2016 22:26:09 Gary Thomas wrote:
> > > On 2016-09-15 22:12, Burton, Ross wrote:
> > > > On 15 September 2016 at 21:03, Paul Eggleton 
> > 
> > 
> > 
> > > wrote:
> > > > Are you guys perhaps using the same terminal application?
> > > > Using screen
> > > > / tmux / anything similar? (I'm using screen here and haven't
> > > > experienced problems though.)
> > > > 
> > > > I'm using iTerm2 on a Mac to run normal SSH to my Linux box. No
> > > > screen/tmux/etc.
> > > 
> > > Pretty much the same for me - just SSH in an xterm window.
> > 
> > Hmm, I'm still no closer then.
> > 
> > Does it just start happening at some point in the middle of a build?
> > Or right 
> > from the start?
> 
> Seems to happen at various points during the build. Looks like bad
> timing of console updates so can happen at any point, I'd see evidence
> its happened multiple times in a given build.

This is bizarre. Clearly something is different between your systems and mine 
:/

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] Crazy display

[Richard Purdie]

On Fri, 2016-09-16 at 08:41 +1200, Paul Eggleton wrote:
> On Thu, 15 Sep 2016 22:26:09 Gary Thomas wrote:
> > 
> > On 2016-09-15 22:12, Burton, Ross wrote:
> > > 
> > > On 15 September 2016 at 21:03, Paul Eggleton 
> 
> > wrote:
> > 
> > > 
> > > Are you guys perhaps using the same terminal application?
> > > Using screen
> > > / tmux / anything similar? (I'm using screen here and haven't
> > > experienced problems though.)
> > > 
> > > I'm using iTerm2 on a Mac to run normal SSH to my Linux box. No
> > > screen/tmux/etc.
> > Pretty much the same for me - just SSH in an xterm window.
> Hmm, I'm still no closer then.
> 
> Does it just start happening at some point in the middle of a build?
> Or right 
> from the start?

Seems to happen at various points during the build. Looks like bad
timing of console updates so can happen at any point, I'd see evidence
its happened multiple times in a given build.

Cheers,

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

Re: [OE-core] Crazy display

[Richard Purdie]

On Thu, 2016-09-15 at 22:26 +0200, Gary Thomas wrote:
> On 2016-09-15 22:12, Burton, Ross wrote:
> > 
> > 
> > On 15 September 2016 at 21:03, Paul Eggleton  > ntel.com > wrote:
> > 
> > Are you guys perhaps using the same terminal application? Using
> > screen / tmux
> > / anything similar? (I'm using screen here and haven't
> > experienced problems
> > though.)
> > 
> > 
> > I'm using iTerm2 on a Mac to run normal SSH to my Linux box. No
> > screen/tmux/etc.
> Pretty much the same for me - just SSH in an xterm window.

I've also seen it on a standard linux ssh session to a remote machine,
no screen, no tmux, just ssh from a gnome-terminal window to a remote.
I've not spotted what the pattern is, other than it seems to be
something about the console write timing being off and started around
the time of the progress changes.

Cheers,

Richard


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

[OE-core] [PATCH v2 2/2] util-linux: Disable bfs support

[Patrick Williams]

Disable building of mkfs.bfs, which is used to create
BFS file-systems used by SCO UnixWare.  This is highly
unlikely to be utilized and there are otherwise no
references to 'bfs' throughout the rest of the tree.

Signed-off-by: Patrick Williams 
---
 meta/recipes-core/util-linux/util-linux.inc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-core/util-linux/util-linux.inc 
b/meta/recipes-core/util-linux/util-linux.inc
index 608f198..c635502 100644
--- a/meta/recipes-core/util-linux/util-linux.inc
+++ b/meta/recipes-core/util-linux/util-linux.inc
@@ -46,7 +46,7 @@ SHARED_EXTRA_OECONF = "--disable-use-tty-group \
--disable-vipw --disable-newgrp --disable-chfn-chsh \
--enable-write --enable-mount \
--enable-libuuid --enable-libblkid --enable-fsck \
-   --disable-minix --without-udev \
+   --disable-minix --disable-bfs --without-udev \
usrsbin_execdir='${sbindir}' \
 "
 
-- 
2.7.3


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

Re: [OE-core] Crazy display

[Paul Eggleton]

On Thu, 15 Sep 2016 22:26:09 Gary Thomas wrote:
> On 2016-09-15 22:12, Burton, Ross wrote:
> > On 15 September 2016 at 21:03, Paul Eggleton 
> wrote:
> > Are you guys perhaps using the same terminal application? Using screen
> > / tmux / anything similar? (I'm using screen here and haven't
> > experienced problems though.)
> > 
> > I'm using iTerm2 on a Mac to run normal SSH to my Linux box. No
> > screen/tmux/etc.
>
> Pretty much the same for me - just SSH in an xterm window.

Hmm, I'm still no closer then.

Does it just start happening at some point in the middle of a build? Or right 
from the start?

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 1/2] util-linux: Disable minix support.

[Randy MacLeod]

On 2016-09-15 03:05 PM, Patrick Williams wrote:

Disable building of {mkfs,fsck}.minix.


Nice clean-up patch Patrick.

I know what minux is but your next patch disables
bfs and I don't have a clue what that is.

Could you re-send with longer commit messages that
explains what the change is in a way that doesn't
require knowing 25 years of linux history? :)

Something like:


Disable building of {mkfs,fsck}.minix.

Disable filesystem tools for minix filesystems.
The Minix OS predates linux and such filesystems are rarely used.
No other oe-core or meta-oe recipes reference minux so
this should not cause secondary problems.

and something similar for bfs.

Thanks,
../Randy



Signed-off-by: Patrick Williams 
---
 meta/recipes-core/util-linux/util-linux.inc | 9 -
 1 file changed, 4 insertions(+), 5 deletions(-)

diff --git a/meta/recipes-core/util-linux/util-linux.inc 
b/meta/recipes-core/util-linux/util-linux.inc
index bf770d8..608f198 100644
--- a/meta/recipes-core/util-linux/util-linux.inc
+++ b/meta/recipes-core/util-linux/util-linux.inc
@@ -45,7 +45,8 @@ SHARED_EXTRA_OECONF = "--disable-use-tty-group \
--enable-raw --enable-reset --disable-login \
--disable-vipw --disable-newgrp --disable-chfn-chsh \
--enable-write --enable-mount \
-   --enable-libuuid --enable-libblkid --enable-fsck 
--without-udev \
+   --enable-libuuid --enable-libblkid --enable-fsck \
+   --disable-minix --without-udev \
usrsbin_execdir='${sbindir}' \
 "

@@ -191,7 +192,7 @@ do_install_append_class-native () {
 ALTERNATIVE_PRIORITY = "80"

 ALTERNATIVE_${PN}  = "dmesg kill more mkswap blockdev pivot_root switch_root"
-ALTERNATIVE_${PN} += "mkfs.minix hexdump last lastb logger mesg renice wall"
+ALTERNATIVE_${PN} += "hexdump last lastb logger mesg renice wall"
 ALTERNATIVE_${PN} += "setsid chrt flock utmpdump eject"

 ALTERNATIVE_LINK_NAME[dmesg] = "${base_bindir}/dmesg"
@@ -201,7 +202,6 @@ ALTERNATIVE_LINK_NAME[mkswap] = "${base_sbindir}/mkswap"
 ALTERNATIVE_LINK_NAME[blockdev] = "${base_sbindir}/blockdev"
 ALTERNATIVE_LINK_NAME[pivot_root] = "${base_sbindir}/pivot_root"
 ALTERNATIVE_LINK_NAME[switch_root] = "${base_sbindir}/switch_root"
-ALTERNATIVE_LINK_NAME[mkfs.minix] = "${base_sbindir}/mkfs.minix"
 ALTERNATIVE_LINK_NAME[eject] = "${bindir}/eject"

 ALTERNATIVE_${PN}-doc = "mountpoint.1 last.1 lastb.1 mesg.1 wall.1 nologin.8 
sulogin.8 utmpdump.1 reset.1 kill.1 libblkid.3 blkid.8 findfs.8 fsck.8 uuid.3"
@@ -248,8 +248,7 @@ ALTERNATIVE_util-linux-swaponoff = "swapoff swapon"
 ALTERNATIVE_LINK_NAME[swapoff] = "${base_sbindir}/swapoff"
 ALTERNATIVE_LINK_NAME[swapon] = "${base_sbindir}/swapon"

-ALTERNATIVE_util-linux-fsck = "fsck.minix fsck"
-ALTERNATIVE_LINK_NAME[fsck.minix] = "${base_sbindir}/fsck.minix"
+ALTERNATIVE_util-linux-fsck = "fsck"
 ALTERNATIVE_LINK_NAME[fsck] = "${base_sbindir}/fsck"

 ALTERNATIVE_util-linux-blkid = "blkid"




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

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

[OE-core] [PATCH] qemuboot-x86: Add task_timeout = -1 to uvesafb

[Saul Wold]

This causes the default timeout to be set to infinity, it will still report out
every 5000 milliseconds

Signed-off-by: Saul Wold 
---
 meta/conf/machine/include/qemuboot-x86.inc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/conf/machine/include/qemuboot-x86.inc 
b/meta/conf/machine/include/qemuboot-x86.inc
index 2ff3ca9..221cc95 100644
--- a/meta/conf/machine/include/qemuboot-x86.inc
+++ b/meta/conf/machine/include/qemuboot-x86.inc
@@ -10,5 +10,5 @@ QB_CPU_KVM_x86-64 = "-cpu kvm64"
 
 QB_AUDIO_DRV = "alsa"
 QB_AUDIO_OPT = "-soundhw ac97,es1370"
-QB_KERNEL_CMDLINE_APPEND = "vga=0 uvesafb.mode_option=640x480-32 
oprofile.timer=1"
+QB_KERNEL_CMDLINE_APPEND = "vga=0 uvesafb.mode_option=640x480-32 
oprofile.timer=1 uvesafb.task_timeout=-1"
 QB_OPT_APPEND = "-vga vmware -show-cursor -usb -usbdevice tablet"
-- 
2.7.4

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

[OE-core] [PATCH] add uvesa timeout to kernel

[Saul Wold]

This depends on the SRCREV update from Bruce to add Jianxun's patch that 
adds the task_timeout code to the uvesafb code.

Please merge this after the kernel SRCREV udpates have been merged.

Sau!


Saul Wold (1):
  qemuboot-x86: Add task_timeout = -1 to uvesafb

 meta/conf/machine/include/qemuboot-x86.inc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

-- 
2.7.4

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

Re: [OE-core] Crazy display

[Gary Thomas]

On 2016-09-15 22:12, Burton, Ross wrote:


On 15 September 2016 at 21:03, Paul Eggleton > wrote:

Are you guys perhaps using the same terminal application? Using screen / 
tmux
/ anything similar? (I'm using screen here and haven't experienced problems
though.)


I'm using iTerm2 on a Mac to run normal SSH to my Linux box. No screen/tmux/etc.


Pretty much the same for me - just SSH in an xterm window.

--

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] Crazy display

[Burton, Ross]

On 15 September 2016 at 21:03, Paul Eggleton 
wrote:

> Are you guys perhaps using the same terminal application? Using screen /
> tmux
> / anything similar? (I'm using screen here and haven't experienced problems
> though.)
>

I'm using iTerm2 on a Mac to run normal SSH to my Linux box. No
screen/tmux/etc.

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

Re: [OE-core] Crazy display

[Paul Eggleton]

I understand some people are seeing this issue with the progress bar, but so 
far I haven't observed any problems here - any help reproducing it would be 
much appreciated. The bugzilla entry is:

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

Are you guys perhaps using the same terminal application? Using screen / tmux 
/ anything similar? (I'm using screen here and haven't experienced problems 
though.)

Cheers,
Paul

On Thu, 15 Sep 2016 12:38:21 Burton, Ross wrote:
> Yes, I see this at least once a day, and there's a bug for it somewhere in
> bugzilla.
> 
> Ross
> 
> On 15 September 2016 at 12:30, Gary Thomas  wrote:
> > I haven't seen this before, just thought I'd toss it out there.
> > I was doing a build (actually three in parallel in separate
> > windows on my build box) and noticed this:
> > 
> > Currently  3 running tasks (3282 of 5081)  64%
> > 
> > |###|
> > 
> > 0: busybox-1.24.1-r0 do_compile (pid 29425)
> > Currently  3 running tasks (3283 of 5081)  64%
> > 
> > |###|
> > 
> > Currently  3 running tasks (3429 of 5081)  67%
> > 
> > |#|
> > 
> > 0: gstreamer1.0-libav-1.8.3-r0 do_configure (pid 10393)
> > Currently  1 running tasks (3560 of 5081)  70%
> > 
> > ||
> > 
> > 0: gstreamer1.0-libav-1.8.3-r0 do_compile (pid 17458)
> > Currently  3 running tasks (3601 of 5081)  70%
> > 
> > ||
> > 
> > 0: gstreamer1.0-libav-1.8.3-r0 do_compile (pid 17458)
> > 1: gdk-pixbuf-2.34.0-r0 do_package_write_ipk (pid 12673)
> > 2: unifdef-native-2.11-r0 do_populate_lic (pid 24548)
> > 
> > Somehow the task tracker (that does a nice job of telling the user
> > what's going on without being overwhelming BTW) got very confused!
> > 
> > I doubt if I can every repeat this, just passing on the observation!
> > 
> > --
> > 
> > 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

-- 

Paul Eggleton
Intel Open Source Technology Centre
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] pseudo 1.8.1 doesn't work with docker & dumb-init

[Randy MacLeod]

On 2016-09-14 10:24 PM, Randy MacLeod wrote:

I'll see if I can reproduce
the failure overnight.


The laptop build worked without error. I may try again tonight.

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

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

[OE-core] [PATCH 2/2] util-linux: Disable bfs support

[Patrick Williams]

Disable building of mkfs.bfs.

Signed-off-by: Patrick Williams 
---
 meta/recipes-core/util-linux/util-linux.inc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-core/util-linux/util-linux.inc 
b/meta/recipes-core/util-linux/util-linux.inc
index 608f198..c635502 100644
--- a/meta/recipes-core/util-linux/util-linux.inc
+++ b/meta/recipes-core/util-linux/util-linux.inc
@@ -46,7 +46,7 @@ SHARED_EXTRA_OECONF = "--disable-use-tty-group \
--disable-vipw --disable-newgrp --disable-chfn-chsh \
--enable-write --enable-mount \
--enable-libuuid --enable-libblkid --enable-fsck \
-   --disable-minix --without-udev \
+   --disable-minix --disable-bfs --without-udev \
usrsbin_execdir='${sbindir}' \
 "
 
-- 
2.7.3


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

[OE-core] [PATCH 1/1] useradd_base.bbclass: Do not mess with the gshadow file in the sysroot

[Peter Kjellerstedt]

Previously, if the gshadow file did not exist in the sysroot when
perform_groupmems() was run, it would be temporarily created and
removed again afterwards. This was supposedly due to groupmems failing
if it does not exist.

However, based on empirical testing and examination of the source code
for groupmems, it should not fail if the gshadow file does not exist
when groupmems is started. But it WILL fail if the file is removed
sometime after its existence has been check at the beginning of the
execution, but before it needs to be modified. And this is exactly
what the previous code in perform_groupmems() could cause if multiple
tasks simultaneously modified users or groups. It could cause any of
the useradd, groupadd and groupmems commands to fail as long as at
least one other recipe invoked perform_groupmems().

Signed-off-by: Peter Kjellerstedt 
---
 meta/classes/useradd_base.bbclass | 12 
 1 file changed, 12 deletions(-)

diff --git a/meta/classes/useradd_base.bbclass 
b/meta/classes/useradd_base.bbclass
index f4dc713..ba87edc 100644
--- a/meta/classes/useradd_base.bbclass
+++ b/meta/classes/useradd_base.bbclass
@@ -51,14 +51,6 @@ perform_groupmems () {
local groupname=`echo "$opts" | awk '{ for (i = 1; i < NF; i++) if ($i 
== "-g" || $i == "--group") print $(i+1) }'`
local username=`echo "$opts" | awk '{ for (i = 1; i < NF; i++) if ($i 
== "-a" || $i == "--add") print $(i+1) }'`
bbnote "${PN}: Running groupmems command with group $groupname and user 
$username"
-   # groupmems fails if /etc/gshadow does not exist
-   local gshadow=""
-   if [ -f $rootdir${sysconfdir}/gshadow ]; then
-   gshadow="yes"
-   else
-   gshadow="no"
-   touch $rootdir${sysconfdir}/gshadow
-   fi
local mem_exists="`grep 
"^$groupname:[^:]*:[^:]*:\([^,]*,\)*$username\(,[^,]*\)*" $rootdir/etc/group || 
true`"
if test "x$mem_exists" = "x"; then
eval flock -x $rootdir${sysconfdir} -c \"$PSEUDO groupmems 
\$opts\" || true
@@ -69,10 +61,6 @@ perform_groupmems () {
else
bbnote "${PN}: group $groupname already contains $username, not 
re-adding it"
fi
-   if test "x$gshadow" = "xno"; then
-   rm -f $rootdir${sysconfdir}/gshadow
-   rm -f $rootdir${sysconfdir}/gshadow-
-   fi
 }
 
 perform_groupdel () {
-- 
2.9.0

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

[OE-core] [PATCH 0/1] Avoid race in perform_groupmems()

[Peter Kjellerstedt]

We have seen sporadic failures in our CI builds due to useradd,
groupadd or groupmems failing. I have now tracked it down to
perform_groupmems() in useradd_base.bbclass, where I found code to
temporarily create the /etc/gshadow file in the sysroot if it did not
exist. Purportedly this was due to groupmems requiring the gshadow
file to exist. There are, however, no real evidence of that
requirement, and actually creating and removing the file the way it is
currently done WILL cause failures when one task removes it while
another task expects it to already exist.

//Peter

The following changes since commit 53b1fa2d3e1244c46a705d9a40ca0dbee92eab98:

  bitbake: build: Allow dirs/cleandirs to work for empty functions (2016-09-15 
12:15:07 +0100)

are available in the git repository at:

  git://git.yoctoproject.org/poky-contrib pkj/groupmems
  http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=pkj/groupmems

Peter Kjellerstedt (1):
  useradd_base.bbclass: Do not mess with the gshadow file in the sysroot

 meta/classes/useradd_base.bbclass | 12 
 1 file changed, 12 deletions(-)

-- 
2.9.0

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

Re: [OE-core] State of bitbake world 2016-09-13

[Martin Jansa]

On Thu, Sep 15, 2016 at 10:43:38AM +0200, Martin Jansa wrote:
> == Number of issues - stats ==
> {| class='wikitable'
> !|Date !!colspan='3'|Failed tasks 
> !!colspan='6'|Failed depencencies!!|Signatures
> !!colspan='12'|QA !!Comment
> |-
> ||||qemuarm   ||qemux86   ||qemux86_64
> ||qemuarm||max||min ||qemux86||max||min ||all   ||already-stripped
>   ||libdir||textrel   ||build-deps||file-rdeps
> ||version-going-backwards   ||host-user-contaminated
> ||installed-vs-shipped  ||unknown-configure-option  ||symlink-to-sysroot  
>   ||invalid-pkgconfig ||pkgname   ||  
> |-
> ||2016-09-13  ||3 ||4 ||4 ||16||4 ||3 ||16||4 
> ||4 ||0 ||0 ||0 ||1 ||10  
>   ||4 ||0 ||0 ||0 ||0 
> ||0 ||0 ||0 ||  
> |}

> === Failed dependencies for qemuarm (16) ===
> 
> Complete log: 
> http://logs.nslu2-linux.org/buildlogs/oe/world/log.dependencies.qemuarm.20160913_042944.log/
> Found differences: 
> * WARN: jasper: jasper-bin rdepends on freeglut, but it isn't a build 
> dependency?
> * WARN: jasper: jasper-bin rdepends on libgl-mesa, but it isn't a build 
> dependency?
> * WARN: jasper: jasper-bin rdepends on libglu, but it isn't a build 
> dependency?
> * WARN: enchant: enchant rdepends on hunspell, but it isn't a build 
> dependency?
> Found errors: 
> * ERROR: 16 issues were found in these recipes: enchant jasper libdrm 
> libunwind qtwebkit samba xfsprogs

...
> gammu-1.32.0: libgsmsd rdepends on unixodbc, but it isn't a build dependency, 
> missing unixodbc in DEPENDS or PACKAGECONFIG? [build-deps]
> libgit2-0.24.1: libgit2 rdepends on libssh2, but it isn't a build dependency, 
> missing libssh2 in DEPENDS or PACKAGECONFIG? [build-deps]
> mpv-0.15.0: mpv rdepends on libjack, but it isn't a build dependency, missing 
> jack in DEPENDS or PACKAGECONFIG? [build-deps]

I'm testing  patches for these (and chrony reported 2016-09-01 in
complete QA log).


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

[OE-core] [PATCH] pulseaudio: add ${S}/LICENSE to LIC_FILES_CHKSUM

[Ross Burton]

The LICENSE file describes how the various pieces are licensed, so add it to the
checksum so we notice when it changes.

Signed-off-by: Ross Burton 
---
 meta/recipes-multimedia/pulseaudio/pulseaudio.inc | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/meta/recipes-multimedia/pulseaudio/pulseaudio.inc 
b/meta/recipes-multimedia/pulseaudio/pulseaudio.inc
index 6ed79ef..7e54ad4 100644
--- a/meta/recipes-multimedia/pulseaudio/pulseaudio.inc
+++ b/meta/recipes-multimedia/pulseaudio/pulseaudio.inc
@@ -3,7 +3,8 @@ HOMEPAGE = "http://www.pulseaudio.org;
 AUTHOR = "Lennart Poettering"
 SECTION = "libs/multimedia"
 LICENSE = "GPLv2+ & LGPLv2.1"
-LIC_FILES_CHKSUM = "file://GPL;md5=4325afd396febcb659c36b49533135d4 \
+LIC_FILES_CHKSUM = "file://LICENSE;md5=d9ae089c8dc5339f8ac9d8563038a29f \
+file://GPL;md5=4325afd396febcb659c36b49533135d4 \
 file://LGPL;md5=2d5025d4aa3495befef8f17206a5b0a1 \
 
file://src/pulsecore/resampler.h;beginline=4;endline=21;md5=09794012ae16912c0270f3280cc8ff84"
 
-- 
2.8.1

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

Re: [OE-core] [PATCH 3/4] meta: use baserunner in oetest

[Joshua Lock]

On Tue, 2016-09-13 at 09:17 +0800, jwang wrote:
> From: zjh 
> 
> enable two features from baserunner:
> 1. loadtest
> 2. read test cases from manifest file
> 
> Signed-off-by: zjh 
> ---
>  meta/lib/oeqa/oetest.py | 24 ++--
>  1 file changed, 14 insertions(+), 10 deletions(-)
> 
> diff --git a/meta/lib/oeqa/oetest.py b/meta/lib/oeqa/oetest.py
> index 4a740fb..9211cec 100644
> --- a/meta/lib/oeqa/oetest.py
> +++ b/meta/lib/oeqa/oetest.py
> @@ -28,6 +28,8 @@ except ImportError:
>  pass
>  from oeqa.utils.decorators import LogResults, gettag, getResults
>  from oeqa.utils import avoid_paths_in_environ
> +from base.baserunner import TestRunnerBase
> +
>  
>  logger = logging.getLogger("BitBake")
>  
> @@ -203,8 +205,10 @@ def custom_verbose(msg, *args, **kwargs):
>  logger.info(_buffer_logger.rstrip("\n"), *args,
> **kwargs)
>  _buffer_logger = ""
>  
> -class TestContext(object):
> +class TestContext(TestRunnerBase):
> +_configure_in_init = True

This is a funny variable, when would it not be True and why? Could we
add a comment here about what the variable is for?

Should it be an argument passed at object construction, as it's denoted
as internal by the _ prefix?

>  def __init__(self, d, exported=False):
> +super(TestContext, self).__init__(self)
>  self.d = d
>  
>  self.testsuites = self._get_test_suites()
> @@ -223,6 +227,9 @@ class TestContext(object):
>  self.imagefeatures = d.getVar("IMAGE_FEATURES",
> True).split()
>  self.distrofeatures = d.getVar("DISTRO_FEATURES",
> True).split()
>  
> +if self._configure_in_init:
> +self.configure()

If we don't configure during __init__() when do we do it? Why might we
not do it during __init__() ?

> +
>  # get testcase list from specified file
>  # if path is a relative path, then relative to build/conf/
>  def _read_testlist(self, fpath, builddir):
> @@ -329,9 +336,7 @@ class TestContext(object):
>  def loadTests(self):
>  setattr(oeTest, "tc", self)
>  
> -testloader = unittest.TestLoader()
> -testloader.sortTestMethodsUsing = None
> -suites = [testloader.loadTestsFromName(name) for name in
> self.testslist]
> +suites = self.loadtest(self.testslist)
>  suites = filterByTagExp(suites, getattr(self, "tagexp",
> None))
>  
>  # Determine dependencies between suites by looking for
> @skipUnlessPassed
> @@ -376,9 +381,9 @@ class TestContext(object):
>  def cmpfunc(a, b):
>  return cmp((a.depth, a.index), (b.depth, b.index))
>  
> -suites.sort(key=functools.cmp_to_key(cmpfunc))
> +suites._tests.sort(key=functools.cmp_to_key(cmpfunc))

We appear to be using a non-public instance variable, is there
something else we could be using here to get the list of tests?

>  
> -self.suite = testloader.suiteClass(suites)
> +self.suite = suites
>  
>  return self.suite
>  
> @@ -387,11 +392,10 @@ class TestContext(object):
>  if hasattr(self, "tagexp") and self.tagexp:
>  logger.info("Filter test cases by tags: %s" %
> self.tagexp)
>  logger.info("Found %s tests" % self.suite.countTestCases())
> -runner = unittest.TextTestRunner(verbosity=2)
>  if 'bb' in sys.modules:
> -runner.stream.write = custom_verbose
> -
> -return runner.run(self.suite)
> +self.runner.stream.write = custom_verbose
> +self.start(self.suite)
> +return self.result()
>  
>  class RuntimeTestContext(TestContext):
>  def __init__(self, d, target, exported=False):
> -- 
> 2.1.4
> 
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 2/4] meta: implement key baserunner features

[Joshua Lock]

On Tue, 2016-09-13 at 09:17 +0800, jwang wrote:
> From: zjh 
> 
> Baserunner contains three features:
> 1. load cases from a manifest file
> 2. load cases from a package such as "oeqa.runtime"
> 3. create runner engine based on pyunit textrunner


I think this and 1/4 should probably be squashed together?

> 
> Signed-off-by: zjh 
> ---
>  meta/lib/base/baserunner.py | 44
> ++--
>  1 file changed, 38 insertions(+), 6 deletions(-)
> 
> diff --git a/meta/lib/base/baserunner.py
> b/meta/lib/base/baserunner.py
> index 56b838e..d59872f 100755
> --- a/meta/lib/base/baserunner.py
> +++ b/meta/lib/base/baserunner.py
> @@ -31,30 +31,62 @@ class FakeOptions(object):
>  class TestRunnerBase(object):
>  '''test runner base '''
>  def __init__(self, context=None):
> -self.tclist = []
> +self.testslist = []
>  self.runner = None
>  self.context = context if context else TestContext()
> +self.test_options = None
>  self.test_result = None
>  self.run_time = None
>  
> +def __del__(self):
> +"""
> +Because unittest.TestCase is a class object, it will exist
> as long as the python virtual machine process.
> +So tc can't be released if we don't release them explicitly.
> +"""
> +if hasattr(unittest.TestCase, "tc"):
> +delattr(unittest.TestCase, "tc")
> +
> +@staticmethod
> +def get_tc_from_manifest(fname):
> +'''get tc list from manifest format '''
> +with open(fname, "r") as f:
> +tclist = [n.strip() for n in f.readlines() \
> +if n.strip() and not
> n.strip().startswith('#')]
> +return tclist

It might be nice to handle open() failing here? If open() fails we're
trying to return an undefined instance.

>  
>  def configure(self, options=FakeOptions()):
>  '''configure before testing'''
> -pass
> +self.test_options = options
> +self.runner = unittest.TextTestRunner(stream=sys.stderr, \

There's no need for a backslash here, we can rely on Python's implied
continuation.

> +  verbosity=2)
>  
>  def result(self):
>  '''output test result '''
> -pass
> +return self.test_result
>  
>  def loadtest(self, names=None):
>  '''load test suite'''
> -pass
> +if names is None:

It's much more idiomatic to write these like:

if not names:

> +names = self.testslist
> +testloader = unittest.TestLoader()
> +tclist = []
> +for name in names:
> +tset = testloader.loadTestsFromName(name)
> +if tset.countTestCases() > 0:
> +tclist.append(tset)
> +elif tset._tests == []:

variable names prefixed with an underscore are, by convention,
internal/private to the object.

Is there a case where countTestCases() might not be > 0 and _tests[] !=
[] ? i.e. can we just use an else here?

> +tclist.append(testloader.discover(name, "[!_]*.py",
> os.path.curdir))
> +return testloader.suiteClass(tclist)
>  
>  def runtest(self, testsuite):
>  '''run test suite'''
> -pass
> +starttime = time.time()
> +self.test_result = self.runner.run(testsuite)
> +self.run_time = time.time() - starttime
>  
>  def start(self, testsuite):
>  '''start testing'''
> -pass
> +setattr(unittest.TestCase, "tc", self.context)
> +self.runtest(testsuite)
> +self.result()
>  
> -- 
> 2.1.4
> 
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 1/4] meta: introduce a small baserunner framework

[Joshua Lock]

Hi Jing, 

Thanks for your submission.

On Tue, 2016-09-13 at 09:17 +0800, jwang wrote:
> From: zjh 

There's no commit message here, which makes this harder to review as I
have to try and work out what it's for and why we want it. 

A useful commit message would tell me why we are introducing a
baserunner framework. This may also make a useful comment in the code
itself.

Also, the patch prefix for the series should be "lib/oeqa", i.e

"[PATCH 3/4] lib/oeqa: use baserunner in oetest"

> Signed-off-by: zjh 
> ---
>  meta/lib/base/baserunner.py | 60
> +
>  1 file changed, 60 insertions(+)
>  create mode 100755 meta/lib/base/baserunner.py
> 
> diff --git a/meta/lib/base/baserunner.py
> b/meta/lib/base/baserunner.py
> new file mode 100755
> index 000..56b838e
> --- /dev/null
> +++ b/meta/lib/base/baserunner.py
> @@ -0,0 +1,60 @@
> +#!/usr/bin/env python

We're defaulting to Python3 in OE-Core nowadays, do you really want
Python2 here (which is the default Python on most Linux distros)

> +# Copyright (C) 2013 Intel Corporation
> +#
> +# Released under the MIT license (see COPYING.MIT)
> +
> +# Base unittest module used by testrunner
> +# This provides the common test runner functionalities including
> manifest input,
> +# xunit output, timeout, tag filtering.
> +
> +"""Base testrunner"""
> +
> +from __future__ import absolute_import
> +import os
> +import sys
> +import time
> +import unittest
> +import shutil
> +
> +class TestContext(object):
> +'''test context which inject into testcase'''
> +def __init__(self):
> +self.target = None
> +
> +class FakeOptions(object):
> +'''This class just use for configure's defualt arg.
> +   Usually, we use this object in a non comandline
> environment.'''
> +timeout = 0
> +def __getattr__(self, name):
> +return None

What's the purpose of overloading __getattr__() here?

> +
> +class TestRunnerBase(object):
> +'''test runner base '''

This comment isn't very useful, same for other similar comments in this
series.

> +def __init__(self, context=None):
> +self.tclist = []
> +self.runner = None
> +self.context = context if context else TestContext()

This would probably be better as: 
self.context = context or TestContext()

or better yet, pass TestContext() as the default param for context,
rather than None?

> +self.test_result = None
> +self.run_time = None
> +
> +
> +def configure(self, options=FakeOptions()):
> +'''configure before testing'''
> +pass
> +
> +def result(self):
> +'''output test result '''
> +pass
> +
> +def loadtest(self, names=None):
> +'''load test suite'''
> +pass
> +
> +def runtest(self, testsuite):
> +'''run test suite'''
> +pass
> +
> +def start(self, testsuite):
> +'''start testing'''
> +pass
> +
> -- 
> 2.1.4
> 
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] Crazy display

[Burton, Ross]

Yes, I see this at least once a day, and there's a bug for it somewhere in
bugzilla.

Ross

On 15 September 2016 at 12:30, Gary Thomas  wrote:

> I haven't seen this before, just thought I'd toss it out there.
> I was doing a build (actually three in parallel in separate
> windows on my build box) and noticed this:
>
> Currently  3 running tasks (3282 of 5081)  64%
> |###|
> 0: busybox-1.24.1-r0 do_compile (pid 29425)
> Currently  3 running tasks (3283 of 5081)  64%
> |###|
> Currently  3 running tasks (3429 of 5081)  67%
> |#|
> 0: gstreamer1.0-libav-1.8.3-r0 do_configure (pid 10393)
> Currently  1 running tasks (3560 of 5081)  70%
> ||
> 0: gstreamer1.0-libav-1.8.3-r0 do_compile (pid 17458)
> Currently  3 running tasks (3601 of 5081)  70%
> ||
> 0: gstreamer1.0-libav-1.8.3-r0 do_compile (pid 17458)
> 1: gdk-pixbuf-2.34.0-r0 do_package_write_ipk (pid 12673)
> 2: unifdef-native-2.11-r0 do_populate_lic (pid 24548)
>
> Somehow the task tracker (that does a nice job of telling the user
> what's going on without being overwhelming BTW) got very confused!
>
> I doubt if I can every repeat this, just passing on the observation!
>
> --
> 
> 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
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] Crazy display

[Gary Thomas]

I haven't seen this before, just thought I'd toss it out there.
I was doing a build (actually three in parallel in separate
windows on my build box) and noticed this:

Currently  3 running tasks (3282 of 5081)  64% |### 
   |

0: busybox-1.24.1-r0 do_compile (pid 29425)
Currently  3 running tasks (3283 of 5081)  64% |### 
   |
Currently  3 running tasks (3429 of 5081)  67% |# 
   |

0: gstreamer1.0-libav-1.8.3-r0 do_configure (pid 10393)
Currently  1 running tasks (3560 of 5081)  70% | 
   |

0: gstreamer1.0-libav-1.8.3-r0 do_compile (pid 17458)
Currently  3 running tasks (3601 of 5081)  70% | 
   |

0: gstreamer1.0-libav-1.8.3-r0 do_compile (pid 17458)
1: gdk-pixbuf-2.34.0-r0 do_package_write_ipk (pid 12673)
2: unifdef-native-2.11-r0 do_populate_lic (pid 24548)

Somehow the task tracker (that does a nice job of telling the user
what's going on without being overwhelming BTW) got very confused!

I doubt if I can every repeat this, just passing on the observation!

--

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

[OE-core] [PATCH] sanity.bbclass: split out config re-parse check

[Markus Lehtonen]

Split out the functionality doing configuration re-parse check into a
separate event handler that is hooked into ConfigParsed event. This will
make config re-parsing actually work. Re-parsing in bitbake is triggered
by setting BB_INVALIDCONF whose value is checked after configuration has
been parsed (after ConfigParsed event). However, previously
BB_INVALIDCONF was set in SanityCheck event handler which caused
re-parsing never to happen.

[YOCTO #10188]

Signed-off-by: Markus Lehtonen 
---
 meta/classes/sanity.bbclass | 27 ---
 1 file changed, 12 insertions(+), 15 deletions(-)

diff --git a/meta/classes/sanity.bbclass b/meta/classes/sanity.bbclass
index f17e2d4..7682ffb 100644
--- a/meta/classes/sanity.bbclass
+++ b/meta/classes/sanity.bbclass
@@ -135,8 +135,7 @@ is a good way to visualise the changes."""
 bb.note("Your conf/bblayers.conf has been automatically updated.")
 return
 
-if not status.reparse:
-status.addresult()
+status.addresult()
 
 elif current_lconf == 6 and lconf_version > 6:
 # Handle rename of meta-yocto -> meta-poky
@@ -557,20 +556,17 @@ def check_perl_modules(sanity_data):
 return "Required perl module(s) not found: %s\n\n%s\n" % (ret, 
errresult)
 return None
 
-def sanity_check_conffiles(status, d):
+def sanity_check_conffiles(d):
 funcs = d.getVar('BBLAYERS_CONF_UPDATE_FUNCS', True).split()
 for func in funcs:
 conffile, current_version, required_version, func = func.split(":")
 if check_conf_exists(conffile, d) and d.getVar(current_version, True) 
is not None and \
 d.getVar(current_version, True) != d.getVar(required_version, 
True):
-success = True
 try:
 bb.build.exec_func(func, d, pythonexception=True)
 except NotImplementedError as e:
-success = False
-status.addresult(str(e))
-if success:
-status.reparse = True
+bb.fatal(e)
+d.setVar("BB_INVALIDCONF", True)
 
 def sanity_handle_abichanges(status, d):
 #
@@ -746,7 +742,7 @@ def check_sanity_version_change(status, d):
 status.addresult("You have a 32-bit libc, but no 32-bit headers.  
You must install the 32-bit libc headers.\n")
 
 bbpaths = d.getVar('BBPATH', True).split(":")
-if ("." in bbpaths or "./" in bbpaths or "" in bbpaths) and not 
status.reparse:
+if ("." in bbpaths or "./" in bbpaths or "" in bbpaths):
 status.addresult("BBPATH references the current directory, either 
through "\
 "an empty entry, a './' or a '.'.\n\t This is unsafe and means 
your "\
 "layer configuration is adding empty elements to BBPATH.\n\t "\
@@ -796,8 +792,6 @@ def check_sanity_everybuild(status, d):
 
 sanity_check_locale(d)
 
-sanity_check_conffiles(status, d)
-
 paths = d.getVar('PATH', True).split(":")
 if "." in paths or "./" in paths or "" in paths:
 status.addresult("PATH contains '.', './' or '' (empty element), which 
will break the build, please remove this.\nParsed PATH is " + str(paths) + "\n")
@@ -943,7 +937,6 @@ def check_sanity(sanity_data):
 def __init__(self):
 self.messages = ""
 self.network_error = False
-self.reparse = False
 
 def addresult(self, message):
 if message:
@@ -999,7 +992,6 @@ def check_sanity(sanity_data):
 
 if status.messages != "":
 raise_sanity_error(sanity_data.expand(status.messages), sanity_data, 
status.network_error)
-return status.reparse
 
 # Create a copy of the datastore and finalise it to ensure appends and 
 # overrides are set - the datastore has yet to be finalised at ConfigParsed
@@ -1008,15 +1000,20 @@ def copy_data(e):
 sanity_data.finalize()
 return sanity_data
 
+addhandler config_reparse_eventhandler
+config_reparse_eventhandler[eventmask] = "bb.event.ConfigParsed"
+python config_reparse_eventhandler() {
+sanity_check_conffiles(e.data)
+}
+
 addhandler check_sanity_eventhandler
 check_sanity_eventhandler[eventmask] = "bb.event.SanityCheck 
bb.event.NetworkTest"
 python check_sanity_eventhandler() {
 if bb.event.getName(e) == "SanityCheck":
 sanity_data = copy_data(e)
+check_sanity(sanity_data)
 if e.generateevents:
 sanity_data.setVar("SANITY_USE_EVENTS", "1")
-reparse = check_sanity(sanity_data)
-e.data.setVar("BB_INVALIDCONF", reparse)
 bb.event.fire(bb.event.SanityCheckPassed(), e.data)
 elif bb.event.getName(e) == "NetworkTest":
 sanity_data = copy_data(e)
-- 
2.6.6

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

Re: [OE-core] [PATCH] util-linux: split {mkfs, fsck}.minix into packages

[Richard Purdie]

On Wed, 2016-09-14 at 21:21 -0500, Patrick Williams wrote:
> On Wed, Sep 14, 2016 at 10:01:01PM +0100, Burton, Ross wrote:
> > 
> > On 14 September 2016 at 18:12, Patrick Williams 
> > wrote:
> > 
> > > 
> > > mkfs.minix and fsck.minix are likely rarely used, so split
> > > them into their own packages to reduce the footprint of
> > > util-linux.  This follows the pattern of cramfs support
> > > within util-linux.
> > > 
> > Minix is so unlikely to be used, why don't we just disable it
> > entirely?
> > (--disable-minix).
> > 
> > Ross
> Sure, prefer I submit that instead?

Please, might as well not bother building that!

Cheers,

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

[OE-core] [PATCH] openjade/sgml-common: Add sstate postrm commands

[Richard Purdie]

If you bump the PR of sgml-common and openjade-native but not sgml-
common-native, you will see a failure as files were removed from the
sysroot but still referenced by the sgml docbook catalog.

To properly handle this, the clean function needs to run at sstate
removal time, the problem is that this sstate removal can happen when
the metadata isn't present, so the correct removal commands are
unknown.

To avoid this, we need to write the commands into a "postrm" script
when we install the files, this can then be executed at sstate removal
time.

[YOCTO #8273]

Signed-off-by: Richard Purdie 

diff --git a/meta/recipes-devtools/openjade/openjade-native_1.3.2.bb 
b/meta/recipes-devtools/openjade/openjade-native_1.3.2.bb
index afcb8ca..d922db9 100644
--- a/meta/recipes-devtools/openjade/openjade-native_1.3.2.bb
+++ b/meta/recipes-devtools/openjade/openjade-native_1.3.2.bb
@@ -48,7 +48,6 @@ CXXFLAGS += "-fno-tree-dse"
 
 SSTATEPOSTINSTFUNCS += "openjade_sstate_postinst"
 SYSROOT_PREPROCESS_FUNCS += "openjade_sysroot_preprocess"
-CLEANFUNCS += "openjade_sstate_clean"
 
 # configure.in needs to be reloacted to trigger reautoconf
 do_extraunpack () {
@@ -104,19 +103,19 @@ openjade_sstate_postinst() {
    
${SYSROOT_DESTDIR}${bindir_crossscripts}/install-catalog-openjade \
    --add ${sysconfdir}/sgml/sgml-docbook.cat \
    ${sysconfdir}/sgml/openjade-${PV}.cat
+   cat << EOF > ${SSTATE_INST_POSTRM}
+#!/bin/sh
+# Ensure that the catalog file sgml-docbook.cat is properly
+# updated when the package is removed from sstate cache.
+files="${sysconfdir}/sgml/sgml-docbook.bak ${sysconfdir}/sgml/sgml-docbook.cat"
+for f in \$files; do
+   [ ! -f \$f ] || sed -i '/\/sgml\/openjade-${PV}.cat/d' \$f
+done
+EOF
    fi
 }
 
 openjade_sysroot_preprocess () {
 install -d ${SYSROOT_DESTDIR}${bindir_crossscripts}/
 install -m 755 ${STAGING_BINDIR_NATIVE}/install-catalog 
${SYSROOT_DESTDIR}${bindir_crossscripts}/install-catalog-openjade
-}
-
-openjade_sstate_clean () {
-   # Ensure that the catalog file sgml-docbook.cat is properly
-   # updated when the package is removed from sstate cache.
-   files="${sysconfdir}/sgml/sgml-docbook.bak 
${sysconfdir}/sgml/sgml-docbook.cat"
-   for f in $files; do
-   [ ! -f $f ] || sed -i '/\/sgml\/openjade-${PV}.cat/d' $f
-   done
-}
+}
diff --git a/meta/recipes-devtools/sgml-common/sgml-common-native_0.6.3.bb 
b/meta/recipes-devtools/sgml-common/sgml-common-native_0.6.3.bb
index 5975365..97b308a 100644
--- a/meta/recipes-devtools/sgml-common/sgml-common-native_0.6.3.bb
+++ b/meta/recipes-devtools/sgml-common/sgml-common-native_0.6.3.bb
@@ -22,8 +22,6 @@ S = "${WORKDIR}/sgml-common-${PV}"
 
 SYSROOT_PREPROCESS_FUNCS += "sgml_common_native_mangle"
 SSTATEPOSTINSTFUNCS += "sgml_common_sstate_postinst"
-CLEANFUNCS += "sgml_common_sstate_clean"
-
 
 do_install_append() {
    # install-catalog script contains hard-coded references to
@@ -59,13 +57,14 @@ sgml_common_sstate_postinst() {
    fi
    done
    fi
-   fi
-}
+   cat << EOF > ${SSTATE_INST_POSTRM}
+#!/bin/sh
 
-sgml_common_sstate_clean () {
-   # Ensure that the catalog file sgml-docbook.cat is properly
-   # updated when the package is removed from sstate cache.
-   if [ -f ${sysconfdir}/sgml/sgml-docbook.cat ]; then
-   sed -i '/\/sgml\/sgml-ent.cat/d' 
${sysconfdir}/sgml/sgml-docbook.cat
+# Ensure that the catalog file sgml-docbook.cat is properly
+# updated when the package is removed from sstate cache.
+if [ -f ${sysconfdir}/sgml/sgml-docbook.cat ]; then
+   sed -i '/\/sgml\/sgml-ent.cat/d' ${sysconfdir}/sgml/sgml-docbook.cat
+fi
+EOF
    fi
 }


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

Re: [OE-core] [PATCH] x264: add textrel to INSANE_SKIP to skip the warning

[Phil Blundell]

On Thu, 2016-09-15 at 12:22 +0530, Sujith H wrote:
> From: Fahad Usman 
> 
> This change help fix the warning message:
> 
> x264/r2491+gitAUTOINC+c8a773ebfc-r0/packages-
> split/x264/usr/lib/libx264.so.144' has relocations in .text [textrel]
> 
> Adding textrel to INSANE_SKIP resolves this issue.

This is a poor commit message.  Adding textrel to INSANE_SKIP prevents
the check from being done, so it is fairly self-evident that it will
suppress the corresponding warning message.  Please add an explanation
of why this is an appropriate thing to do, i.e. why the textrels are
present and why you can't get rid of them by other means.

In particular please clarify whether you want to do this because the
textrels are absolutely unavoidable for some reason on your
architecture, or just because you think this is a good trade-off for
performance.  If the latter then I think the change probably belongs in
a distro or BSP layer not in oe-core.

p.

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

[OE-core] [PATCH] sstate: Add postrm command support

[Richard Purdie]

There are some issues in sstate which can't be handled by file removal
alone. Currently there is no way to execute a command against sstate and
doing so is potentially problematic for things like dependencies. This
patch adds a mechanism where any "postrm" script is executed if its present
allowing some openjade/sgml issues to be resolved.

[YOCTO #8273]

Signed-off-by: Richard Purdie 

diff --git a/meta/classes/sstate.bbclass b/meta/classes/sstate.bbclass
index 8b6ac50..0498a38 100644
--- a/meta/classes/sstate.bbclass
+++ b/meta/classes/sstate.bbclass
@@ -175,6 +175,8 @@ def sstate_install(ss, d):
 if os.access(manifest, os.R_OK):
 bb.fatal("Package already staged (%s)?!" % manifest)
 
+d.setVar("SSTATE_INST_POSTRM", manifest + ".postrm")
+
 locks = []
 for lock in ss['lockfiles-shared']:
 locks.append(bb.utils.lockfile(lock, True))
@@ -407,6 +409,13 @@ def sstate_clean_manifest(manifest, d):
 except OSError:
 pass
 
+postrm = manifest + ".postrm"
+if os.path.exists(manifest + ".postrm"):
+import subprocess
+os.chmod(postrm, 0o755)
+subprocess.call(postrm, shell=True)
+oe.path.remove(postrm)
+
 oe.path.remove(manifest)
 
 def sstate_clean(ss, d):
@@ -1011,6 +1020,8 @@ python sstate_eventhandler2() {
 for r in toremove:
 (stamp, manifest, workdir) = r.split()
 for m in glob.glob(manifest + ".*"):
+if m.endswith(".postrm"):
+continue
 sstate_clean_manifest(m, d)
 bb.utils.remove(stamp + "*")
 if removeworkdir:


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

[OE-core] State of bitbake world 2016-09-13

[Martin Jansa]

== Number of issues - stats ==
{| class='wikitable'
!|Date   !!colspan='3'|Failed tasks 
!!colspan='6'|Failed depencencies!!|Signatures
!!colspan='12'|QA !!Comment
|-
||  ||qemuarm   ||qemux86   ||qemux86_64
||qemuarm||max||min ||qemux86||max||min ||all   ||already-stripped  
||libdir||textrel   ||build-deps||file-rdeps
||version-going-backwards   ||host-user-contaminated
||installed-vs-shipped  ||unknown-configure-option  ||symlink-to-sysroot
||invalid-pkgconfig ||pkgname   ||  
|-
||2016-09-13||3 ||4 ||4 ||16||4 ||3 ||16||4 
||4 ||0 ||0 ||0 ||1 ||10
||4 ||0 ||0 ||0 ||0 
||0 ||0 ||0 ||  
|}

http://www.openembedded.org/wiki/Bitbake_World_Status

== Failed tasks 2016-09-13 ==

INFO: jenkins-job.sh-1.8.10 Complete log available at 
http://logs.nslu2-linux.org/buildlogs/oe/world/log.report.20160914_215344.log

=== common (2) ===
* 
meta-openembedded/meta-filesystems/recipes-utils/xfsprogs/xfsprogs_4.7.0.bb:do_compile
* 
openembedded-core/meta/recipes-support/libunwind/libunwind_git.bb:do_compile

=== common-x86 (1) ===
* 
meta-openembedded/meta-oe/recipes-support/vboxguestdrivers/vboxguestdrivers_4.3.36.bb:do_compile

=== qemuarm (1) ===
* meta-qt5/recipes-qt/qt5/qtwebkit_git.bb:do_compile

=== qemux86 (1) ===
* meta-browser/recipes-browser/chromium/chromium_52.0.2743.76.bb:do_compile

=== qemux86_64 (0) ===

=== Number of failed tasks (11) ===
{| class=wikitable
|-
|| qemuarm  || 3 || 
http://logs.nslu2-linux.org/buildlogs/oe/world/log.world.qemuarm.20160912_221615.log/
 || http://errors.yoctoproject.org/Errors/Build/21484/
|-
|| qemux86  || 4 || 
http://logs.nslu2-linux.org/buildlogs/oe/world/log.world.qemux86.20160912_221620.log/
 || http://errors.yoctoproject.org/Errors/Build/21481/
|-
|| qemux86_64   || 4 || 
http://logs.nslu2-linux.org/buildlogs/oe/world/log.world.qemux86-64.20160913_012915.log/
 || http://errors.yoctoproject.org/Errors/Build/21505/
|}

=== PNBLACKLISTs (120) ===

=== QA issues (15) ===
{| class=wikitable
!| Count||Issue
|-
||0 ||already-stripped
|-
||0 ||host-user-contaminated
|-
||0 ||installed-vs-shipped
|-
||0 ||invalid-pkgconfig
|-
||0 ||libdir
|-
||0 ||pkgname
|-
||0 ||symlink-to-sysroot
|-
||0 ||unknown-configure-option
|-
||0 ||version-going-backwards
|-
||10||build-deps
|-
||1 ||textrel
|-
||4 ||file-rdeps
|}



=== Failed dependencies for qemuarm (16) ===

Complete log: 
http://logs.nslu2-linux.org/buildlogs/oe/world/log.dependencies.qemuarm.20160913_042944.log/
Found differences: 
* WARN: libdrm: libdrm-tests rdepends on cunit, but it isn't a build 
dependency?
* WARN: libdrm: libdrm-tests rdepends on libdrm-amdgpu, but it isn't a 
build dependency?
* WARN: jasper: jasper-bin rdepends on freeglut, but it isn't a build 
dependency?
* WARN: jasper: jasper-bin rdepends on libgl-mesa, but it isn't a build 
dependency?
* WARN: jasper: jasper-bin rdepends on libglu, but it isn't a build 
dependency?
* WARN: enchant: enchant rdepends on hunspell, but it isn't a build 
dependency?
Found errors: 
* ERROR: 16 issues were found in these recipes: enchant jasper libdrm 
libunwind qtwebkit samba xfsprogs

=== Recipes failing with maximal dependencies for qemuarm (4) ===
* libunwind -- 
http://logs.nslu2-linux.org/buildlogs/oe/world/log.dependencies.qemuarm.20160913_042944.log//2_max/failed/libunwind.log
* qtwebkit -- 
http://logs.nslu2-linux.org/buildlogs/oe/world/log.dependencies.qemuarm.20160913_042944.log//2_max/failed/qtwebkit.log
* samba -- 
http://logs.nslu2-linux.org/buildlogs/oe/world/log.dependencies.qemuarm.20160913_042944.log//2_max/failed/samba.log
* xfsprogs -- 
http://logs.nslu2-linux.org/buildlogs/oe/world/log.dependencies.qemuarm.20160913_042944.log//2_max/failed/xfsprogs.log

=== Recipes failing with minimal dependencies for qemuarm (3) ===
* libunwind -- 
http://logs.nslu2-linux.org/buildlogs/oe/world/log.dependencies.qemuarm.20160913_042944.log//3_min/failed/libunwind.log
* samba -- 
http://logs.nslu2-linux.org/buildlogs/oe/world/log.dependencies.qemuarm.20160913_042944.log//3_min/failed/samba.log
* xfsprogs -- 
http://logs.nslu2-linux.org/buildlogs/oe/world/log.dependencies.qemuarm.20160913_042944.log//3_min/failed/xfsprogs.log

=== Failed dependencies for qemux86 (16) ===

Complete log: 
http://logs.nslu2-linux.org/buildlogs/oe/world/log.dependencies.qemux86.20160913_100956.log/
Found differences: 
* WARN: jasper: jasper-bin rdepends on freeglut, but it isn't a build 
dependency?
* WARN: jasper: jasper-bin rdepends on libgl-mesa, but it isn't a build 
dependency?
  

Re: [OE-core] [PATCH] x264: add textrel to INSANE_SKIP for cyclone5 machine

[sujith h]

On Thu, Sep 15, 2016 at 12:15 PM, sujith h  wrote:

>
>
> On Thu, Sep 15, 2016 at 10:13 AM, sujith h  wrote:
>
>>
>>
>> On Thu, Sep 15, 2016 at 4:41 AM, Burton, Ross 
>> wrote:
>>
>>>
>>> On 12 September 2016 at 07:13, Sujith H  wrote:
>>>
 +# PIC can't be enabled for 32-bit x86 and cyclone5
  INSANE_SKIP_${PN}_append_x86 = " textrel"
 +INSANE_SKIP_${PN}_append_cyclone5 = " textrel"

>>>
>>> Can this be generalised or is it absolutely specific to cyclone5?  If it
>>> can't be generalised then I feel that this should belong in the cyclone5
>>> BSP.
>>>
>>
>> We found this with cyclone5 BSP. I will try to figure out how if we can
>> see it with qemuarm or other BSP's too.
>>
>
> I tried with qemuarm, it wasn't reproducible. But with imx6qsabresd from
> meta-fsl-arm, it was reproducible. So I believe we can generalize this
> patch. I will send the updated one shortly. Thanks for the pointer Ross.
>

I forgot to mention that I posted this change in meta-altera for review. I
got the feedback from meta-altera to post the change for review here:
https://github.com/kraj/meta-altera/pull/37. Sharing this for the reference.


>
>>
>>>
>>> Ross
>>>
>>
>>
>>
>> --
>> സുജിത് ഹരിദാസന്
>> Bangalore
>> Contributor to KDE project
>> Contributor to Yocto project
>> http://fci.wikia.com/wiki/Anti-DRM-Campaign
>>  http://sujithh.info
>> C-x C-c
>>
>
>
>
> --
> സുജിത് ഹരിദാസന്
> Bangalore
> Contributor to KDE project
> Contributor to Yocto project
> http://fci.wikia.com/wiki/Anti-DRM-Campaign
>  http://sujithh.info
> C-x C-c
>



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

Re: [OE-core] [PATCH] e2fsprogs: configure with enable-symlink

[André Draszik]

On 15 Sep 2016 03:21, "Patrick Williams"  wrote:
>
> On Wed, Sep 14, 2016 at 11:23:47PM +0200, Martin Jansa wrote:
> > It was also proposed and discussed some 15 months ago and it was
packaging
> > issue not handling hardlinks correctly:
> >
http://lists.openembedded.org/pipermail/openembedded-core/2015-April/103939.html
> >
> > I believe this was fixed then, but maybe it got broken again?
>
> Sorry, this is my fault.  I didn't think about hard-links.  I was just
> skimming the cpio extract for parts that could be trimmed out and
> noticed it.
>
> $ ls -i *fsck*
> 19455718 e2fsck
> 19455671 fsck
> 19455718 fsck.ext2
> 19455718 fsck.ext3
> 19455718 fsck.ext4
> 19455718 fsck.ext4dev
> 19455679 fsck.minix
> 19455695 fsck.minix.util-linux
> 19455675 fsck.util-linux
>
> Is there a reason to prefer hardlinks over softlinks, for my own
> education?  My desktop system used softlinks for fsck.

Mine too. I don't really care, soft links are surely more obvious, though.

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

[OE-core] [PATCH] x264: add textrel to INSANE_SKIP to skip the warning

[Sujith H]

From: Fahad Usman 

This change help fix the warning message:

x264/r2491+gitAUTOINC+c8a773ebfc-r0/packages-split/x264/usr/lib/libx264.so.144' 
has relocations in .text [textrel]

Adding textrel to INSANE_SKIP resolves this issue.
This issue was observed in cyclone5 and imx6qsabresd BSP's.
So generalizing the patch.

Signed-off-by: Fahad Usman 
Signed-off-by: Sujith Haridasan 
---
 meta/recipes-multimedia/x264/x264_git.bb | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/meta/recipes-multimedia/x264/x264_git.bb 
b/meta/recipes-multimedia/x264/x264_git.bb
index fa44f9c..393310f 100644
--- a/meta/recipes-multimedia/x264/x264_git.bb
+++ b/meta/recipes-multimedia/x264/x264_git.bb
@@ -48,6 +48,6 @@ do_install() {
 oe_runmake install DESTDIR=${D}
 }
 
-# PIC can't be enabled for 32-bit x86
-INSANE_SKIP_${PN}_append_x86 = " textrel"
+# PIC can't be enabled for few BSP's
+INSANE_SKIP_${PN}_append = " textrel"
 
-- 
1.9.1

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

Re: [OE-core] [PATCH] x264: add textrel to INSANE_SKIP for cyclone5 machine

[sujith h]

On Thu, Sep 15, 2016 at 10:13 AM, sujith h  wrote:

>
>
> On Thu, Sep 15, 2016 at 4:41 AM, Burton, Ross 
> wrote:
>
>>
>> On 12 September 2016 at 07:13, Sujith H  wrote:
>>
>>> +# PIC can't be enabled for 32-bit x86 and cyclone5
>>>  INSANE_SKIP_${PN}_append_x86 = " textrel"
>>> +INSANE_SKIP_${PN}_append_cyclone5 = " textrel"
>>>
>>
>> Can this be generalised or is it absolutely specific to cyclone5?  If it
>> can't be generalised then I feel that this should belong in the cyclone5
>> BSP.
>>
>
> We found this with cyclone5 BSP. I will try to figure out how if we can
> see it with qemuarm or other BSP's too.
>

I tried with qemuarm, it wasn't reproducible. But with imx6qsabresd from
meta-fsl-arm, it was reproducible. So I believe we can generalize this
patch. I will send the updated one shortly. Thanks for the pointer Ross.


>
>>
>> Ross
>>
>
>
>
> --
> സുജിത് ഹരിദാസന്
> Bangalore
> Contributor to KDE project
> Contributor to Yocto project
> http://fci.wikia.com/wiki/Anti-DRM-Campaign
>  http://sujithh.info
> C-x C-c
>



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

Re: [OE-core] [PATCH] scripts: introduce buildstats-diff

[Markus Lehtonen]

From:  "Burton, Ross" 
Date:  Wednesday 14 September 2016 at 19:38
To:  Markus Lehtonen 
Cc:  OE-core 
Subject:  Re: [OE-core] [PATCH] scripts: introduce buildstats-diff


On 14 September 2016 at 12:24, Markus Lehtonen
 wrote:
> +if not tasks1:
> +pkg_op = '++'
> +elif not tasks2:
> +pkg_op = '--'

BTW, I've been reading buildstats-diff output all day and find the lack of
whitespace between the operator and the package name makes the output harder
to read, so I've patched it locally to be just '+ ' or '- ' for clarity.

Sounds fine to me. I don't object your modification.
  - Markus



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