[OE-core] npm thoughts

[Trevor Woerner]

Hi,

I was trying out devtool+npm with the electron quick-start node stuff and
noticed some interesting results. This simple app can be found at
https://github.com/electron/electron-quick-start

According to https://wiki.yoctoproject.org/wiki/TipsAndTricks/NPM there are
two ways to create a recipe for a node app using The Yocto Project's devtool:
1) by pointing devtool at the npm registry
2) by pointing devtool at the project's source code
It is also possible to:
3) point to a tarball of the project's source

Preparation for 2) is as follows:
$ git clone git://github.com/electron/electron-quick-start

Further preparation for 3) continues:
$ tar -c electron-quick-start/ > electron-quick-start.tar
$ gzip electron-quick-start.tar

It is important to note that the following assumes morty. Master is messed up
right now with the introduction of per-recipe sysroots (but is expected to get
fixed eventually). The layers used are openembedded-core:morty, bitbake:1.32,
and meta-openembedded:morty.

This app's package.json is:

{
  "name": "electron-quick-start",
  "version": "1.0.0",
  "description": "A minimal Electron application",
  "main": "main.js",
  "scripts": {
"start": "electron ."
  },  
  "repository": "https://github.com/electron/electron-quick-start;,
  "keywords": [
"Electron",
"quick",
"start",
"tutorial",
"demo"
  ],  
  "author": "GitHub",
  "license": "CC0-1.0",
  "devDependencies": {
"electron": "^1.4.1"
  }
}


Testing 3)
$ . layers/openembedded-core/oe-init-build-env tarball layers/bitbake
edit conf/bblayers.conf to add meta-openembedded/meta-oe
$ devtool add electron-quick-start 
~/npm/source/electron-quick-start.tar.gz

Here is the recipe devtool creates:
# Recipe created by recipetool
# This is the basis of a recipe and may need further editing in 
order to be fully functional.
# (Feel free to remove these comments when editing.)

SUMMARY = "A minimal Electron application"
# WARNING: the following LICENSE and LIC_FILES_CHKSUM values 
are best guesses - it is
# your responsibility to verify that the values are complete 
and correct.
#
# The following license files were not able to be identified 
and are
# represented as "Unknown" below, you will need to check them 
yourself:
#   LICENSE.md
#
LICENSE = "CC0-1.0"
LIC_FILES_CHKSUM = 
"file://LICENSE.md;md5=c4bb4655ae0c8ab590a1aa591e3a80c5"

SRC_URI = "file:///z/npm/source/electron-quick-start.tar.gz"

NPM_LOCKDOWN := "${THISDIR}/${PN}/lockdown.json"

inherit npm 

# Must be set after inherit npm since that itself sets S
S = "${WORKDIR}/electron-quick-start.git"
LICENSE_${PN} = "CC0-1.0"

$ bitbake electron-quick-start
$ tree 
tmp-glibc/work/i586-oe-linux/electron-quick-start/1.0.0-r0/packages-split/electron-quick-start
electron-quick-start
└── usr
└── lib
└── node_modules
└── electron-quick-start
├── index.html
├── LICENSE.md
├── main.js
├── package.json
├── README.md
└── renderer.js


Testing 2)
$ . layers/openembedded-core/oe-init-build-env clone layers/bitbake
edit conf/bblayers.conf to add meta-openembedded/meta-oe
$ devtool add electron-quick-start ~/npm/source/electron-quick-start.git

Here is the recipe:
# Recipe created by recipetool
# This is the basis of a recipe and may need further editing in 
order to be fully functional.
# (Feel free to remove these comments when editing.)

SUMMARY = "A minimal Electron application"
# WARNING: the following LICENSE and LIC_FILES_CHKSUM values 
are best guesses - it is
# your responsibility to verify that the values are complete 
and correct.
#
# The following license files were not able to be identified 
and are
# represented as "Unknown" below, you will need to check them 
yourself:
#   LICENSE.md
#
LICENSE = "CC0-1.0"
LIC_FILES_CHKSUM = 
"file://LICENSE.md;md5=c4bb4655ae0c8ab590a1aa591e3a80c5"

SRC_URI = "git://github.com/electron/electron-quick-start.git"

# Modify these as desired
PV = "1.0.0+git${SRCPV}"

Re: [OE-core] [oe] OEDAM - Portland 2017

[Trevor Woerner]

Okay thanks, sounds good.
See you then.

On Sun, Feb 19, 2017 at 5:49 PM, Philip Balister <phi...@balister.org> wrote:
> It sounds like a bunch of us will meet in the Hilton lobby at 0800 and
> use Lyft/Uber/other.
>
> Philip
>
> On 02/19/2017 07:12 AM, Trevor Woerner wrote:
>> Does anyone have any recommendations for how to get from the
>> conference venue to the Mentor Graphics office?
>>
> --
> ___
> Openembedded-devel mailing list
> openembedded-de...@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-devel
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] OEDAM - Portland 2017

[Trevor Woerner]

Does anyone have any recommendations for how to get from the
conference venue to the Mentor Graphics office?
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

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

[Trevor Woerner]

This reverts commit 3632abd01abb8dfff230e18f828af705da488f97.

Multiple people have expressed issues with flex-2.6.2; personally I had
problems compiling libsepol from meta-selinux (for libselinux). I tried
upgrading to flex-2.6.3, but that caused binutils-cross_2.27 to fail.

The simplest for now is to downgrade to flex-2.6.0.
---
 ...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*)",
+   "   
M4_YY_CALL_LAST_ARG);",
+-- 
+2.5.5
+
diff --git a/meta/recipes-devtools/flex/flex/CVE-2016-6354.patch 
b/meta/recipes-devtools/flex/flex/CVE-2016-6354.patch
new file mode 100644
index 00..216ac7ae1c
--- /dev/null
+++ b/meta/recipes-devtools/flex/flex/CVE-2016-6354.patch
@@ -0,0 +1,59 @@
+From 3939eccdff598f47e5b37b05d58bf1b44d3796e7 Mon Sep 17 00:00:00 2001
+From: Jussi Kukkonen 
+Date: Fri, 7 Oct 2016 14:15:38 +0300
+Subject: [PATCH] Prevent buffer overflow in 

Re: [OE-core] [PATCH 4/7] flex: upgrade to 2.6.2

[Trevor Woerner]

On Mon, Jan 30, 2017 at 2:56 PM, Denys Dmytriyenko  wrote:
> On Thu, Jan 26, 2017 at 06:21:48PM -0800, Khem Raj wrote:
>> On Thu, Jan 26, 2017 at 6:19 PM, Martin Jansa  wrote:
>> > I did try 2.6.3 but it was even worse as reported,
>>
>> thats just sad.

Has anyone made a decision on this? I wasn't able to compile libsepol
from meta-security due to flex-2.6.2. I also tried upgrading to 2.6.3
but that caused binutils to fail. Reverting to 2.6.0 seems to fix the
issues I'm seeing.
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] Patchwork and incoming patch testing

[Trevor Woerner]

On Wed 2017-01-18 @ 07:05:58 AM, Paul Eggleton wrote:
> This should give us a bit more visibility into 
> where patches are at in the process, although we are still working on a few 
> places where patch series status needs to be updated (e.g. when a patch goes 
> into testing).

Is the testing process for OE patches formalized?

I'm not referring to the Yocto Project's release testing.
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] ncurses.inc: add v6 binconfig-disabled entries

[Trevor Woerner]

Newer host distributions are moving to ncurses6, therefore add entries so the
host's ncurses{w}6-config scripts aren't picked up.

Signed-off-by: Trevor Woerner <twoer...@gmail.com>
---
 meta/classes/binconfig-disabled.bbclass | 1 +
 meta/recipes-core/ncurses/ncurses.inc   | 5 -
 2 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/meta/classes/binconfig-disabled.bbclass 
b/meta/classes/binconfig-disabled.bbclass
index 602a669..096b670 100644
--- a/meta/classes/binconfig-disabled.bbclass
+++ b/meta/classes/binconfig-disabled.bbclass
@@ -15,6 +15,7 @@ do_install_append () {
echo "echo 'ERROR: $x should not be used, use an alternative 
such as pkg-config' >&2" >> ${D}$x
echo "echo '--should-not-have-used-$x'" >> ${D}$x
echo "exit 1" >> ${D}$x
+   chmod +x ${D}$x
done
 }
 
diff --git a/meta/recipes-core/ncurses/ncurses.inc 
b/meta/recipes-core/ncurses/ncurses.inc
index ff0117b..3f4bf67 100644
--- a/meta/recipes-core/ncurses/ncurses.inc
+++ b/meta/recipes-core/ncurses/ncurses.inc
@@ -7,7 +7,8 @@ SECTION = "libs"
 DEPENDS = "ncurses-native"
 DEPENDS_class-native = ""
 
-BINCONFIG = "${bindir}/ncurses5-config ${bindir}/ncursesw5-config"
+BINCONFIG = "${bindir}/ncurses5-config ${bindir}/ncursesw5-config \
+   ${bindir}/ncurses6-config ${bindir}/ncursesw6-config"
 
 inherit autotools binconfig-disabled multilib_header pkgconfig
 
@@ -278,6 +279,8 @@ FILES_${PN} = "\
   ${bindir}/tset \
   ${bindir}/ncurses5-config \
   ${bindir}/ncursesw5-config \
+  ${bindir}/ncurses6-config \
+  ${bindir}/ncursesw6-config \
   ${datadir}/tabset \
 "
 
-- 
2.10.2

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

Re: [OE-core] [PATCH] util-linux: 2.28.1 -> 2.29

[Trevor Woerner]

On Tue 2016-12-20 @ 03:16:54 PM, Burton, Ross wrote:
> On 20 December 2016 at 15:14, Trevor Woerner <twoer...@gmail.com> wrote:
> 
> > So I only have the version 5 -config scripts, but my host has version 5 and
> > version 6 -config scripts. I'm guessing we need a dummy ncurses{w}6-config
> > script in the sysroot too (?)
> >
> 
> Yeah, that seems like a good diagnosis.  Can you knock up a patch as you
> can replicate?

No problem, doing that now.
Thanks for your awesome help!
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] util-linux: 2.28.1 -> 2.29

[Trevor Woerner]

On Tue 2016-12-20 @ 10:14:01 AM, Trevor Woerner wrote:
> So I only have the version 5 -config scripts, but my host has version 5 and
> version 6 -config scripts. I'm guessing we need a dummy ncurses{w}6-config
> script in the sysroot too (?)

YES!

Going into my sysroot and creating v6 -config scripts by simply copying the v5
ones allows util-linux-native to build successfully :-D
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] util-linux: 2.28.1 -> 2.29

[Trevor Woerner]

On Tue 2016-12-20 @ 03:05:20 PM, Burton, Ross wrote:
> On 20 December 2016 at 15:00, Burton, Ross  wrote:
> 
> > This would be the autoconf macro UL_NCURSES_CHECK in m4/ul.m4, which calls
> > ncurses6-config.  I thought the sysroot was ahead of the host so it should
> > find our broken script before the hosts...
> >
> 
> $ bitbake -e util-linux-native -e
> ...
> export
> PATH="/home/ross/Yocto/poky/scripts/native-intercept:/data/poky-master/tmp-glibc/sysroots-uninative/x86_64-linux/usr/bin:/home/ross/Yocto/poky/scripts:/data/poky-master/tmp-glibc/sysroots/x86_64-linux/usr/bin/x86_64-linux:/data/poky-master/tmp-glibc/sysroots/x86_64-linux/usr/bin:/data/poky-master/tmp-glibc/sysroots/x86_64-linux/usr/sbin:/data/poky-master/tmp-glibc/sysroots/x86_64-linux/usr/bin:/data/poky-master/tmp-glibc/sysroots/x86_64-linux/sbin:/data/poky-master/tmp-glibc/sysroots/x86_64-linux/bin:/home/ross/Yocto/poky/scripts:/home/ross/Yocto/poky/bitbake/bin:/home/ross/BUILD/bin:/home/ross/bin:/home/ross/Yocto/bb/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games"
> 
> Definitely the sysroot before the host.

I have:

export 
PATH="/z/layerindex-master/layers/openembedded-core/scripts/native-intercept:/z/layerindex-master/raspi3/tmp-glibc/sysroots-uninative/x86_64-linux/usr/bin:/z/layerindex-master/layers/openembedded-core/scripts:/z/layerindex-master/raspi3/tmp-glibc/sysroots/x86_64-linux/usr/bin/x86_64-linux:/z/layerindex-master/raspi3/tmp-glibc/sysroots/x86_64-linux/usr/bin:/z/layerindex-master/raspi3/tmp-glibc/sysroots/x86_64-linux/usr/sbin:/z/layerindex-master/raspi3/tmp-glibc/sysroots/x86_64-linux/usr/bin:/z/layerindex-master/raspi3/tmp-glibc/sysroots/x86_64-linux/sbin:/z/layerindex-master/raspi3/tmp-glibc/sysroots/x86_64-linux/bin:/z/layerindex-master/layers/openembedded-core/scripts:/z/layerindex-master/layers/bitbake/bin:/home/trevor/local/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/home/trevor/local/packages/apache-maven-2.2.1/bin"

which also shows my sysroots before the host.

In my sysroot I have:

$ find . -name "*curse*" -print | grep config
./x86_64-linux/usr/share/x86_64-linux_config_site.d/ncurses_config
./x86_64-linux/usr/lib/pkgconfig/ncurses++.pc
./x86_64-linux/usr/lib/pkgconfig/ncurses.pc
./x86_64-linux/usr/lib/pkgconfig/ncursesw.pc
./x86_64-linux/usr/lib/pkgconfig/ncurses++w.pc
./x86_64-linux/usr/bin/crossscripts/ncurses5-config
./x86_64-linux/usr/bin/crossscripts/ncursesw5-config
./x86_64-linux/usr/bin/ncurses5-config
./x86_64-linux/usr/bin/ncursesw5-config

./raspberrypi3/usr/share/arm-oe-linux-gnueabi_config_site.d/ncurses_config
./raspberrypi3/usr/lib/pkgconfig/ncurses++.pc
./raspberrypi3/usr/lib/pkgconfig/ncurses.pc
./raspberrypi3/usr/lib/pkgconfig/ncursesw.pc
./raspberrypi3/usr/lib/pkgconfig/ncurses++w.pc
./raspberrypi3/usr/bin/crossscripts/ncurses5-config
./raspberrypi3/usr/bin/crossscripts/ncursesw5-config

So I only have the version 5 -config scripts, but my host has version 5 and
version 6 -config scripts. I'm guessing we need a dummy ncurses{w}6-config
script in the sysroot too (?)
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] util-linux: 2.28.1 -> 2.29

[Trevor Woerner]

On Tue 2016-12-20 @ 02:41:21 PM, Burton, Ross wrote:
> On 19 December 2016 at 22:12, Khem Raj  wrote:
> 
> > checking ncursesw... (v6) yes
> >
> 
> I'm pretty sure this indicates that it found a ncursesw-config binary,
> which we disable. So it must be running the host tool.  I'm seeing if we
> can force it to use the sysroot easily now.

Hi Ross,

Thanks for continuing to look into this! :-)

I spent the last while trying some things to see if I could fix this issue. I
tried adding --disable-widechar to OECONF since that was one of the new things
added between 2.28.1 and 2.29 (no change).

Looking through the config.log I found a couple things that weren't right:

$ cat -n config.log | grep "\/usr\/include" | grep -v x86_64
  3326  In file included from /usr/include/linux/gsmmux.h:4:0,
  3328  /usr/include/linux/if.h:211:19: error: field 'ifru_addr' has 
incomplete type
  3331  /usr/include/linux/if.h:212:19: error: field 'ifru_dstaddr' has 
incomplete type
  3334  /usr/include/linux/if.h:213:19: error: field 'ifru_broadaddr' 
has incomplete type
  3337  /usr/include/linux/if.h:214:19: error: field 'ifru_netmask' has 
incomplete type
  3340  /usr/include/linux/if.h:215:20: error: field 'ifru_hwaddr' has 
incomplete type
  8662  NCURSES_CFLAGS='-I/usr/include/ncurses6/ncursesw 
-I/usr/include/ncurses6'

The biggest one is probably the last one (line 8662) where something is
setting NCURSES_CFLAGS explicitly to /usr/include. I'm looking for that one
now.

The first issue I see in my config.log is confusing to me too. Looking at the
full log around that area gives:

3325 configure:17946: gcc  -std=gnu99 -c 
-isystem/z/layerindex-master/raspi3/tmp-glibc/sysroots/x86_64-linux/usr/include 
-O2 -pipe 
-isystem/z/layerindex-master/raspi3/tmp-glibc/sysroots/x86_64-linux/usr/include 
conftest.c >&5
3326 In file included from /usr/include/linux/gsmmux.h:4:0,
3327  from conftest.c:82:
3328 /usr/include/linux/if.h:211:19: error: field 'ifru_addr' has 
incomplete type
3329struct sockaddr ifru_addr;
3330^
3331 /usr/include/linux/if.h:212:19: error: field 'ifru_dstaddr' has 
incomplete type
3332struct sockaddr ifru_dstaddr;
^
3334 /usr/include/linux/if.h:213:19: error: field 'ifru_broadaddr' has 
incomplete type
3335struct sockaddr ifru_broadaddr;
3336^
3337 /usr/include/linux/if.h:214:19: error: field 'ifru_netmask' has 
incomplete type
3338struct sockaddr ifru_netmask;
3339^
3340 /usr/include/linux/if.h:215:20: error: field 'ifru_hwaddr' has 
incomplete type
3341struct  sockaddr ifru_hwaddr;

The compile line is clearly telling gcc to use -isystem/z/layerindex In
other words gcc is being directed to look in the correct locations. But in the
error messages it's saying that it looked in "/usr/include/linux/if.h". Does
this mean that -isystem isn't doing what we hope it should be doing? Or is gcc
stripping out the -isystem prefix when reporting this error?
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] util-linux: 2.28.1 -> 2.29

[Trevor Woerner]

On Mon, Dec 19, 2016 at 4:53 PM, Burton, Ross  wrote:
> Definitely works here:

:-(

>> Can you share the do_configure log?

sure, attached


log.do_configure
Description: Binary data
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] util-linux: 2.28.1 -> 2.29

[Trevor Woerner]

On Mon 2016-12-19 @ 08:31:25 PM, Burton, Ross wrote:
> On 19 December 2016 at 15:23, Trevor Woerner <twoer...@gmail.com> wrote:
> 
> > Is anyone else seeing build failures as a result of this commit?
> >
> 
> Can you reproduce this on demand?

Yes. Last night's raspi2 and minnow/turbot builds failed, and trying with qemu
(x86-64 and x86) all failed.

A fresh build in a new directory fails readily:

$ git clone git://git.openembedded.org/openembedded-core.git
(e82a7f879419828b42b5cc71e6229c8235090f21)
$ git clone git://git.openembedded.org/bitbake.git
(50633012a64a3b5f0662145e29ff426374fb7683)
$ . openembedded-core/oe-init-build-env build bitbake
$ bitbake util-linux-native


Build Configuration:
BB_VERSION= "1.32.0"
BUILD_SYS = "x86_64-linux"
NATIVELSBSTRING   = "opensuse-42.2"
TARGET_SYS= "i586-oe-linux"
MACHINE   = "qemux86"
DISTRO= "nodistro"
DISTRO_VERSION= "nodistro.0"
TUNE_FEATURES = "m32 i586"
TARGET_FPU= ""
meta  = "master:e82a7f879419828b42b5cc71e6229c8235090f21"

*BOOM!* ;-)

| disk-utils/cfdisk-cfdisk.o:cfdisk.c:(.text.startup+0x8fd): more undefined 
references to `_nc_stdscr' follow
| collect2: error: ld returned 1 exit status
| Makefile:5737: recipe for target 'cfdisk' failed
| make[2]: *** [cfdisk] Error 1
| make[2]: Leaving directory 
'/z/qemu/build/tmp-glibc/work/x86_64-linux/util-linux-native/2.29-r0/build'
| Makefile:11450: recipe for target 'all-recursive' failed
| make[1]: *** [all-recursive] Error 1
| make[1]: Leaving directory 
'/z/qemu/build/tmp-glibc/work/x86_64-linux/util-linux-native/2.29-r0/build'
| Makefile:4781: recipe for target 'all' failed
| make: *** [all] Error 2
| ERROR: Function failed: do_compile (log file is located at 
/z/qemu/build/tmp-glibc/work/x86_64-linux/util-linux-native/2.29-r0/temp/log.do_compile.28460)
ERROR: Task 
(virtual:native:/z/qemu/openembedded-core/meta/recipes-core/util-linux/util-linux_2.29.bb:do_compile)
 failed with exit code '1'
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] util-linux: 2.28.1 -> 2.29

[Trevor Woerner]

Is anyone else seeing build failures as a result of this commit?

... [lots of lines omitted] ...
| cfdisk.c:(.text+0x207b): undefined reference to `_nc_stdscr'
| cfdisk.c:(.text+0x20a4): undefined reference to `_nc_stdscr'
| cfdisk.c:(.text+0x2268): undefined reference to `_nc_stdscr'
| cfdisk.c:(.text+0x2284): undefined reference to `_nc_acs_map'
| cfdisk.c:(.text+0x2290): undefined reference to `_nc_stdscr'
| cfdisk.c:(.text+0x22b9): undefined reference to `_nc_stdscr'
| cfdisk.c:(.text+0x22d4): undefined reference to `_nc_acs_map'
| cfdisk.c:(.text+0x22e5): undefined reference to `_nc_stdscr'
| cfdisk.c:(.text+0x2304): undefined reference to `_nc_stdscr'
| cfdisk.c:(.text+0x231d): undefined reference to `_nc_acs_map'
| cfdisk.c:(.text+0x2329): undefined reference to `_nc_stdscr'
| cfdisk.c:(.text+0x2374): undefined reference to `_nc_stdscr'
| cfdisk.c:(.text+0x2392): undefined reference to `_nc_acs_map'
| cfdisk.c:(.text+0x239e): undefined reference to `_nc_stdscr'
| disk-utils/cfdisk-cfdisk.o: In function `ui_menu_resize':
| cfdisk.c:(.text+0x244a): undefined reference to `_nc_stdscr'
| disk-utils/cfdisk-cfdisk.o: In function `ui_refresh':
| cfdisk.c:(.text+0x24c5): undefined reference to `_nc_stdscr'
| cfdisk.c:(.text+0x24d2): undefined reference to `_nc_stdscr'
| cfdisk.c:(.text+0x24ff): undefined reference to `_nc_stdscr'
| disk-utils/cfdisk-cfdisk.o:cfdisk.c:(.text+0x2587): more undefined 
references to `_nc_stdscr' follow
| disk-utils/cfdisk-cfdisk.o: In function `main':
| cfdisk.c:(.text.startup+0x334): undefined reference to `_nc_LINES'
| cfdisk.c:(.text.startup+0x342): undefined reference to `_nc_COLS'
| cfdisk.c:(.text.startup+0x39d): undefined reference to `_nc_stdscr'
| cfdisk.c:(.text.startup+0x45b): undefined reference to `_nc_stdscr'
| cfdisk.c:(.text.startup+0x4d3): undefined reference to `_nc_stdscr'
| cfdisk.c:(.text.startup+0x4e0): undefined reference to `_nc_stdscr'
| cfdisk.c:(.text.startup+0x77d): undefined reference to `_nc_stdscr'
| disk-utils/cfdisk-cfdisk.o:cfdisk.c:(.text.startup+0x8fd): more 
undefined references to `_nc_stdscr' follow
| collect2: error: ld returned 1 exit status
| Makefile:5737: recipe for target 'cfdisk' failed
| make[2]: *** [cfdisk] Error 1
| make[2]: Leaving directory 
'/z/layerindex-master/raspi3/tmp-glibc/work/x86_64-linux/util-linux-native/2.29-r0/build'
| Makefile:11450: recipe for target 'all-recursive' failed
| make[1]: *** [all-recursive] Error 1
| make[1]: Leaving directory 
'/z/layerindex-master/raspi3/tmp-glibc/work/x86_64-linux/util-linux-native/2.29-r0/build'
| Makefile:4781: recipe for target 'all' failed
| make: *** [all] Error 2
| ERROR: Function failed: do_compile (log file is located at 
/z/layerindex-master/raspi3/tmp-glibc/work/x86_64-linux/util-linux-native/2.29-r0/temp/log.do_compile.18807)
ERROR: Task 
(virtual:native:/z/layerindex-master/layers/openembedded-core/meta/recipes-core/util-linux/util-linux_2.29.bb:do_compile)
 failed with exit code '1'
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [meta-intel] [PATCH 2/2] gstreamer1.0-vaapi: Import from meta-intel

[Trevor Woerner]

On Thu, Dec 15, 2016 at 8:55 AM, Burton, Ross  wrote:
> When gst-vaapi moved to oe-core it also renamed to match the convention in
> there.  I guess we should add a PROVIDES for the old name to ensure it
> replaces the old version.  Can you test that this works for you?


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

Re: [OE-core] [meta-intel] [PATCH 2/2] gstreamer1.0-vaapi: Import from meta-intel

[Trevor Woerner]

I'm guessing I have to wait a little longer for various repositories to sync
up with respect to each other, or is something going bad here?

| configure: error: Requested 'gstreamer-codecparsers-1.0 <= 1.8.99' 
but version of GStreamer codec parsers is 1.10.1
| WARNING: 
/z/layerindex-master/minnowmax/tmp-glibc/work/corei7-64-oe-linux/gstreamer-vaapi-1.0/1.8.2-r0/temp/run.do_configure.11053:1
 exit 1 from 'exit 1'
| ERROR: Function failed: do_configure (log file is located at 
/z/layerindex-master/minnowmax/tmp-glibc/work/corei7-64-oe-linux/gstreamer-vaapi-1.0/1.8.2-r0/temp/log.do_configure.11053)
ERROR: Task 
(/z/layerindex-master/layers/meta-intel/common/recipes-multimedia/gstreamer/gstreamer-vaapi-1.0_1.8.2.bb:do_configure)
 failed with exit code '1'

This is a core-image-x11 build using master for minnow/turbot:

Build Configuration:
BB_VERSION= "1.32.0"
BUILD_SYS = "x86_64-linux"
NATIVELSBSTRING   = "opensuse-42.2"
TARGET_SYS= "x86_64-oe-linux"
MACHINE   = "intel-corei7-64"
DISTRO= "nodistro"
DISTRO_VERSION= "nodistro.0"
TUNE_FEATURES = "m64 corei7"
TARGET_FPU= ""
meta  = "master:91f856426c7523e1ebdf6d6f93f5fa7e509d6e49"
meta-intel= "master:3d218385a7d8509fbb66b6aa92efef185d1cfcde"
meta-oe
meta-gnome= "master:e6c7a66eb4f3944059bd4fff4103f8a9fdcb167c"
meta-browser  = "master:3f4fc6dd50650417a0b966c4157f3ad7f3697633"
meta-nodejs   = "master:7d63ea2e056e96a617a6281613afff6fe7762619"
meta-realtime = "master:c7807efaaa9933f45a68576c56a2ff2f9bd24203"
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 3/4] kern-tools: fix processing for no branch meta-data

[Trevor Woerner]

On Wed, Dec 7, 2016 at 1:05 PM, Trevor Woerner <twoer...@gmail.com> wrote:
> On Wed, Dec 7, 2016 at 11:18 AM, Bruce Ashfield
> <bruce.ashfi...@windriver.com> wrote:
>> With the attached patch, I see nothing else that is named  in /tmp/
>>
>> If you have the cycles, can you give it a try and let me know ?
>
> Yes, I'm giving it a whirl right now. Thanks!

That patch looks good, how soon can it land? ;-)

I'm sure there's still something in the build that is creating
temporary files in /tmp. I'm not sure which process is doing it, I
have no reason to suspect it's the kernel tools (in fact I think it
happens too early in the build to be the kernel tools), and the tmp
files that are created are named with temporary names (e.g.
/tmp/tmp.2wavbhTlDU) so they shouldn't interfere with multiple users
building on the same machine. Each build appears to create two such
temp files that aren't cleaned up at the end of the build. Not a big
deal. I don't think it's something new that was introduced recently
(but I'd have to do more investigation to verify).
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 3/4] kern-tools: fix processing for no branch meta-data

[Trevor Woerner]

On Wed, Dec 7, 2016 at 11:18 AM, Bruce Ashfield
 wrote:
> With the attached patch, I see nothing else that is named  in /tmp/
>
> If you have the cycles, can you give it a try and let me know ?

Yes, I'm giving it a whirl right now. Thanks!
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 3/4] kern-tools: fix processing for no branch meta-data

[Trevor Woerner]

This patch does fix the raspberrypi issue, and it has been pushed, thankfully.

But I'm still seeing hard-coded filenames in /tmp that are messing up
the ability for more than one person to use a given build machine.
E.g.:

/tmp/patch.standard.arm-versatile-926ejs.queue
/tmp/patch.standard.mti-malta32.queue
/tmp/patch.standard.mti-malta64.queue
/tmp/patch.standard.preempt-rt.base.queue
/tmp/patch.standard.preempt-rt.queue
/tmp/patch.standard.queue
/tmp/patch.unused.queue

I think the malta ones are used for qemumips64, which is still failing
for this reason (multiple users)

On Tue, Dec 6, 2016 at 6:02 PM, Paul Barker  wrote:
> On Tue, 06 Dec 2016 22:14:41 +0100
> Patrick Ohly  wrote:
>
>> On Fri, 2016-12-02 at 16:09 -0500, Bruce Ashfield wrote:
>> > Lernel meta-data that has patches, but no branches, can trigger an
>> > error due to no branch specific patch queue.
>> >
>> > This error then cascades to more issues since the tools are using
>> > a named file in /tmp to store and display error messages to the
>> > user.
>> >
>> > We fix both issues though the following kern tools tweaks:
>> >
>> >   commit bd9e1d6c9b0a34ff3e19a06999aaf57ffadfd04c
>> >   Author: Bruce Ashfield 
>> >   Date:   Fri Dec 2 13:09:40 2016 -0500
>> >
>> > scc: use mktemp for consolidated output capture
>> >
>> > To provide useful error messages the tools dump pre-processed
>> > files and messages to a temporary file. If multiple users are
>> > doing builds, this means they either race, or can have permissions
>> > issues.
>> >
>> > By creating the temporary file via mktemp, we avoid both issues.
>> > (We also make sure to clean these up on exit, or /tmp will get
>> > polluted quickly).
>> >
>> >   commit a287da4bfe0b4acb8f2b0627bd8e7abd1a1dde26
>> >   Author: Bruce Ashfield 
>> >   Date:   Fri Dec 2 13:08:08 2016 -0500
>> >
>> > patch: do not assume a branch specific patch queue is needed
>> >
>> > When processing input files per-branch and global patch queues are
>> > generated. If the meta-data has not created any branches in the
>> > repo, no branch specific queue is required.
>> >
>> > The tools assumed that one is always valid, and hence would throw a
>> > non-zero exit code and stop processing.
>> >
>> > By testing for a named per-branch queue, we avoid this issue.
>>
>> Ostro OS runs into the problem while trying to use current OE-core
>> master:
>>
>>  .../patch.cmd: line 29: : No such file or directory
>>
>> | ERROR: Function failed: do_kernel_metadata (log file is located ...)
>>
>> This commit here fixed it for me. I see that it is already in Ross' mut2
>> branch, so hopefully that'll land in master soon.
>>
>
> Ditto for meta-raspberrypi, the kernel doesn't build with current
> oe-core master as discussed on the yocto@ list. This patch is needed
> to fix things.
>
> Thanks,
> Paul Barker
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 0/4] kernel-yocto: consolidated pull request

[Trevor Woerner]

On Fri 2016-12-02 @ 04:09:21 PM, Bruce Ashfield wrote:
> This pull request is mainly to fix a couple of bugs that were reported
> on the mailing list recently, but it also includes some kernel version
> updates that I *think* I sent previously.

Thanks Bruce, I've tested these and they look good.
-- 
___
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-08-24

[Trevor Woerner]

I performed a verbose build on my build machine to see how it compares to
yours.

On Wed 2016-08-31 @ 05:41:06 AM, Trevor Woerner wrote:
> On Fri 2016-08-26 @ 05:51:54 PM, Martin Jansa wrote:
> | [2278/20239] CXX obj.host/third_party/icu/source/common/icuuc.servrbf.o
> | FAILED: obj.host/third_party/icu/source/common/icuuc.servrbf.o
> | g++  -MMD -MF obj.host/third_party/icu/source/common/icuuc.servrbf.o.d 
> -DU_USING_ICU_NAMESPACE=0 -DHAVE_DLOPEN=0 -DUCONFIG_ONLY_HTML_CONVERSION=1 
> -DU_CHARSET_IS_UTF8=1 -DV8_DEPRECATION_WARNINGS -D_FILE_OFFSET_BITS=64 
> -DDISABLE_NACL -DU_STATIC_IMPLEMENTATION -DCHROMIUM_BUILD 
> -DUI_COMPOSITOR_IMAGE_TRANSPORT -DUSE_AURA=1 -DUSE_PANGO=1 -DUSE_CAIRO=1 
> -DUSE_DEFAULT_RENDER_THEME=1 -DUSE_LIBJPEG_TURBO=1 -DUSE_X11=1 
> -DUSE_CLIPBOARD_AURAX11=1 -DENABLE_WEBRTC=1 -DENABLE_MEDIA_ROUTER=1 
> -DENABLE_PEPPER_CDMS -DENABLE_NOTIFICATIONS -DENABLE_TOPCHROME_MD=1 
> -DUSE_UDEV -DFIELDTRIAL_TESTING_ENABLED -DENABLE_TASK_MANAGER=1 
> -DENABLE_EXTENSIONS=1 -DENABLE_PDF=1 -DENABLE_PLUGINS=1 
> -DENABLE_SESSION_SERVICE=1 -DENABLE_THEMES=1 -DENABLE_PRINTING=1 
> -DENABLE_BASIC_PRINTING=1 -DENABLE_PRINT_PREVIEW=1 -DENABLE_SPELLCHECK=1 
> -DENABLE_CAPTIVE_PORTAL_DETECTION=1 -DENABLE_SUPERVISED_USERS=1 
> -DENABLE_MDNS=1 -DENABLE_SERVICE_DISCOVERY=1 -DFULL_SAFE_BROWSING 
> -DSAFE_BROWSING_CSD -DSAFE_BROWSING_DB_LOCAL -DU_CO
 MMON_IMPLEMENTATION -DU_ICUDATAENTRY_IN_COMMON -DU_ENABLE_DYLOAD=0 
-DU_NOEXCEPT= -DUSE_LIBPCI=1 -DUSE_GLIB=1 -DUSE_NSS_CERTS=1 -DNDEBUG 
-DNVALGRIND -DDYNAMIC_ANNOTATIONS_ENABLED=0 
-I../../third_party/icu/source/common -I../../third_party/icu/source/i18n -Igen 
-fstack-protector --param=ssp-buffer-size=4  -pthread -fno-strict-aliasing 
-Wno-extra -Wno-unused-parameter -Wno-missing-field-initializers 
-fvisibility=hidden -pipe -fPIC -Wno-unused-local-typedefs 
-Wno-deprecated-declarations -Wno-unused-function -m32 -O2 -fno-ident 
-fdata-sections -ffunction-sections -funwind-tables -fno-exceptions -fno-rtti 
-fno-threadsafe-statics -fvisibility-inlines-hidden -frtti -Wno-deprecated 
-std=gnu++11 -Wno-narrowing  -c ../../third_party/icu/source/common/servrbf.cpp 
-o obj.host/third_party/icu/source/common/icuuc.servrbf.o

Buried deep in all your compiler options is "-m32". On my machine all these
options are exactly the same except for this one; in my case my build has
"-m64".

Are you doing your world builds on a 32-bit machine?

Could this one change account for my build success and your build failure?
-- 
___
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-08-24

[Trevor Woerner]

On Fri 2016-08-26 @ 05:51:54 PM, Martin Jansa wrote:
> === common-x86 (1) ===
> * 
> meta-browser/recipes-browser/chromium/chromium-wayland_48.0.2548.0.bb:do_patch

It was pointed out to me that while re-organizing the chromium recipes I
dropped an important line in chromium-wayland. However this recipe didn't
succeed before and my goal was to make chromium (on x11) succeed. So even with
the fix I'm not sure chromium-wayland is going to be okay.

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

This one surprised me since I perform a chromium build every night on my CI
farm. Looking at your build logs I find:

| [2278/20239] CXX obj.host/third_party/icu/source/common/icuuc.servrbf.o
| FAILED: obj.host/third_party/icu/source/common/icuuc.servrbf.o
| g++  -MMD -MF obj.host/third_party/icu/source/common/icuuc.servrbf.o.d 
-DU_USING_ICU_NAMESPACE=0 -DHAVE_DLOPEN=0 -DUCONFIG_ONLY_HTML_CONVERSION=1 
-DU_CHARSET_IS_UTF8=1 -DV8_DEPRECATION_WARNINGS -D_FILE_OFFSET_BITS=64 
-DDISABLE_NACL -DU_STATIC_IMPLEMENTATION -DCHROMIUM_BUILD 
-DUI_COMPOSITOR_IMAGE_TRANSPORT -DUSE_AURA=1 -DUSE_PANGO=1 -DUSE_CAIRO=1 
-DUSE_DEFAULT_RENDER_THEME=1 -DUSE_LIBJPEG_TURBO=1 -DUSE_X11=1 
-DUSE_CLIPBOARD_AURAX11=1 -DENABLE_WEBRTC=1 -DENABLE_MEDIA_ROUTER=1 
-DENABLE_PEPPER_CDMS -DENABLE_NOTIFICATIONS -DENABLE_TOPCHROME_MD=1 -DUSE_UDEV 
-DFIELDTRIAL_TESTING_ENABLED -DENABLE_TASK_MANAGER=1 -DENABLE_EXTENSIONS=1 
-DENABLE_PDF=1 -DENABLE_PLUGINS=1 -DENABLE_SESSION_SERVICE=1 -DENABLE_THEMES=1 
-DENABLE_PRINTING=1 -DENABLE_BASIC_PRINTING=1 -DENABLE_PRINT_PREVIEW=1 
-DENABLE_SPELLCHECK=1 -DENABLE_CAPTIVE_PORTAL_DETECTION=1 
-DENABLE_SUPERVISED_USERS=1 -DENABLE_MDNS=1 -DENABLE_SERVICE_DISCOVERY=1 
-DFULL_SAFE_BROWSING -DSAFE_BROWSING_CSD -DSAFE_BROWSING_DB_LOCAL -DU_COMM
 ON_IMPLEMENTATION -DU_ICUDATAENTRY_IN_COMMON -DU_ENABLE_DYLOAD=0 -DU_NOEXCEPT= 
-DUSE_LIBPCI=1 -DUSE_GLIB=1 -DUSE_NSS_CERTS=1 -DNDEBUG -DNVALGRIND 
-DDYNAMIC_ANNOTATIONS_ENABLED=0 -I../../third_party/icu/source/common 
-I../../third_party/icu/source/i18n -Igen -fstack-protector 
--param=ssp-buffer-size=4  -pthread -fno-strict-aliasing -Wno-extra 
-Wno-unused-parameter -Wno-missing-field-initializers -fvisibility=hidden -pipe 
-fPIC -Wno-unused-local-typedefs -Wno-deprecated-declarations 
-Wno-unused-function -m32 -O2 -fno-ident -fdata-sections -ffunction-sections 
-funwind-tables -fno-exceptions -fno-rtti -fno-threadsafe-statics 
-fvisibility-inlines-hidden -frtti -Wno-deprecated -std=gnu++11 -Wno-narrowing  
-c ../../third_party/icu/source/common/servrbf.cpp -o 
obj.host/third_party/icu/source/common/icuuc.servrbf.o
| In file included from 
../../third_party/icu/source/common/unicode/std_string.h:33:0,
|  from ../../third_party/icu/source/common/unicode/unistr.h:31,
|  from 
../../third_party/icu/source/common/unicode/strenum.h:14,
|  from ../../third_party/icu/source/common/unicode/uenum.h:24,
|  from ../../third_party/icu/source/common/unicode/uloc.h:25,
|  from ../../third_party/icu/source/common/unicode/ures.h:27,
|  from 
../../third_party/icu/source/common/unicode/resbund.h:51,
|  from ../../third_party/icu/source/common/servrbf.cpp:13:
| /usr/include/c++/4.8/string:38:28: fatal error: bits/c++config.h: No such 
file or directory
|  #include 

Odd. It looks like your build is picking up your host's c++ compiler version
4.8 (?). The odd thing is, my build machine also does not have a
/usr/include/bits/c++config.h but my compile succeeds.
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] kernel.bbclass: add lzop dependency

[Trevor Woerner]

On Wed 2016-08-03 @ 09:39:59 PM, Bruce Ashfield wrote:
> On Wed, Aug 3, 2016 at 8:53 AM, Trevor Woerner <twoer...@gmail.com> wrote:
> 
> > On Mon 2016-08-01 @ 03:08:36 PM, Burton, Ross wrote:
> > > On 1 August 2016 at 15:07, Bruce Ashfield <bruce.ashfi...@gmail.com>
> > wrote:
> > >
> > > > Not a large dependency, but it does bring to mind the question if this
> > > > could be conditional on the type of image being built ? via  distro
> > > > feature, some other mechanism ?
> > > >
> > >
> > > Exactly this: image building adds dependencies automatically based on
> > what
> > > is actually being used, so can the kernel do this too?
> >
> > The way the build knows which image was built is to build the kernel then
> > look
> > in the output directory to see what extension was given to the artifact.
> > iow,
> > it only discovers the dependency partway through the build; it doesn't know
> > the dependency when the build starts.
> >
> > Either bitbake will have to put together the kernel's config at the start
> > of
> > the build, then parse through it to try to determine which kernel will be
> > built, or we need some sort of mechanism that allows us to add dependencies
> > partway through a build, or we can add (yet another) build variable and
> > hope
> > people are able to keep it in sync.
> >
> >
> I'm on vacation for the next two weeks, so sorry for the slow reply.

np enjoy! "'tis the season" :-)

> 
> Wouldn't something like PACKAGECONFIG work here ? Something automatic
> is going to be complex (like you describe), but something like this would
> be an
> easy way for a BSP (or other) layer to bbappend the kernel and add this as
> a dependency.
> 
> ... but then again, I suppose they could currently just bbappend the kernel
> recipe
> and add it directly to the DEPENDS.

I've proposed a change to the kernel.bbclass to add the lzop-native DEPENDS to
the existing

DEPENDS += "virtual/${TARGET_PREFIX}binutils 
virtual/${TARGET_PREFIX}gcc kmod-native depmodwrapper-cross bc-native"

because it's in this file that the lzop program is being called.

It seems as though your suggestions are discussing changes to a recipe (?)
which is fine, I'll propose a patch to the BSP-in-question's kernel recipe.

> 
> >
> > ...or we could just add lzop-native as a static dependency in the
> > off-chance that
> > it's needed.
> >
> 
> 
> 
> -- 
> "Thou shalt not follow the NULL pointer, for chaos and madness await thee
> at its end"
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] kernel.bbclass: add lzop dependency

[Trevor Woerner]

On Mon 2016-08-01 @ 03:08:36 PM, Burton, Ross wrote:
> On 1 August 2016 at 15:07, Bruce Ashfield  wrote:
> 
> > Not a large dependency, but it does bring to mind the question if this
> > could be conditional on the type of image being built ? via  distro
> > feature, some other mechanism ?
> >
> 
> Exactly this: image building adds dependencies automatically based on what
> is actually being used, so can the kernel do this too?

The way the build knows which image was built is to build the kernel then look
in the output directory to see what extension was given to the artifact. iow,
it only discovers the dependency partway through the build; it doesn't know
the dependency when the build starts.

Either bitbake will have to put together the kernel's config at the start of
the build, then parse through it to try to determine which kernel will be
built, or we need some sort of mechanism that allows us to add dependencies
partway through a build, or we can add (yet another) build variable and hope
people are able to keep it in sync.

...or we could just add lzop-native as a static dependency in the off-chance 
that
it's needed.
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] kernel.bbclass: add lzop dependency

[Trevor Woerner]

On Mon 2016-08-01 @ 03:08:36 PM, Burton, Ross wrote:
> On 1 August 2016 at 15:07, Bruce Ashfield  wrote:
> 
> > Not a large dependency, but it does bring to mind the question if this
> > could be conditional on the type of image being built ? via  distro
> > feature, some other mechanism ?
> >
> 
> Exactly this: image building adds dependencies automatically based on what
> is actually being used, so can the kernel do this too?

I'm uncertain regarding the status of this patch:

1) will it be applied? (doesn't sound like it)

2) do you want me to work on it some more? (i'll look for other examples of
conditional DEPENDS, i'm not aware of any off the top of my head)

3) should i be looking to push this into a BSP layer? (since BSPs usually
choose their kernel)
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] kernel.bbclass: add lzop dependency

[Trevor Woerner]

If the initramfs image is type lzo, then a native lzop is needed.

Signed-off-by: Trevor Woerner <twoer...@gmail.com>
---
 meta/classes/kernel.bbclass | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index fa76a14..db42744 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -1,7 +1,7 @@
 inherit linux-kernel-base kernel-module-split
 
 PROVIDES += "virtual/kernel"
-DEPENDS += "virtual/${TARGET_PREFIX}binutils virtual/${TARGET_PREFIX}gcc 
kmod-native depmodwrapper-cross bc-native"
+DEPENDS += "virtual/${TARGET_PREFIX}binutils virtual/${TARGET_PREFIX}gcc 
kmod-native depmodwrapper-cross bc-native lzop-native"
 
 S = "${STAGING_KERNEL_DIR}"
 B = "${WORKDIR}/build"
-- 
2.9.2

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

[OE-core] [PATCH] gstreamer1.0-plugins-bad: opengl handling

[Trevor Woerner]

Enable the opengl configuration option if DISTRO_FEATURES contains opengl.

Signed-off-by: Trevor Woerner <twoer...@gmail.com>
---
 meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad.inc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad.inc 
b/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad.inc
index 9e2b94e..1a342f8 100644
--- a/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad.inc
+++ b/meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad.inc
@@ -12,7 +12,7 @@ SRC_URI_append = " \
 
 # opengl packageconfig factored out to make it easy for distros
 # and BSP layers to pick either (desktop) opengl, gles2, or no GL
-PACKAGECONFIG_GL ?= "${@bb.utils.contains('DISTRO_FEATURES', 'opengl', 
'gles2', '', d)}"
+PACKAGECONFIG_GL ?= "${@bb.utils.contains('DISTRO_FEATURES', 'opengl', 'opengl 
gles2', '', d)}"
 
 # gtk is not in the PACKAGECONFIG variable by default until
 # the transition to gtk+3 is finished
-- 
2.9.2

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

Re: [OE-core] [PATCH V2] glibc: Upgrade to latest tip of master

[Trevor Woerner]

On Fri 2016-07-08 @ 01:55:18 PM, Khem Raj wrote:
> Trevor
> 
> On Thu, Jul 7, 2016 at 1:25 PM, Khem Raj  wrote:
> > Ok thanks. Let me know if you get to see the same issue on say qemuarm or
> > qemuarm64
> 
> I built core-image-sato/qemux86-64 vmdk with chromium added
> 
> CORE_IMAGE_EXTRA_INSTALL_append = " chromium "
> 
> launched this image in VM and chromium starts normally.

Someday I hope that we'll have a mechanism in place that will be able to
better record the full information about a build to help make it easier for
multiple people to fully recreate the exact same builds, independently (iow,
in situations like this).

I've done my best to recreate your build, and I'm still seeing the failure.
I was able, however, to convince someone else to try building and running
chromium (from master), they tried it, and are seeing the run-time failure
too.

> 
> I am using github.com/kraj/openembedded-core kraj/master branch and
> github.com/kraj/meta-raspberrypi kraj/master
> everything else is upstream master and gcc is 5.x
> 
> here is my build info
> 
> Build Configuration:
> BB_VERSION= "1.31.0"
> BUILD_SYS = "x86_64-linux"
> NATIVELSBSTRING   = "universal"
> TARGET_SYS= "x86_64-oe-linux"
> MACHINE   = "qemux86-64"
> DISTRO= "nodistro"
> DISTRO_VERSION= "nodistro.0"
> TUNE_FEATURES = "m64 core2"
> TARGET_FPU= ""
> meta-raspberrypi  = "kraj/master:b9ba221e520f39bc3e273f709b5ceea02897d525"
> meta-qcom = "master:0eaea003cac6c3175b0a3682efd6e1f20ecc9dab"
> meta-96boards = "master:6b2744bf3e82154a9329ab89cf03eec9d1f80837"
> oe-meta-go= "master:dc19a245ae5224d1c9859119a9c53b6331812400"
> meta-browser  = "master:77736988073a5d90fcff9d0005c8477332ede387"
> meta-metrological = "kraj/master:356f0c33298eb63af415f333fe06121d056261e1"
> meta-multimedia
> meta-gnome
> meta-oe   = "master:f11f8664de82e4f8c23b075542f4c98c16ce1f5e"
> meta  = "kraj/master:96ed9e94082589a62a6c602e5f774c11de3328c6"

At first I looked at your list and thought to myself: why all the extras? For
qemux86-64, all that's needed are:
- something to provide the meta (poky or openembedded-core)
- meta-browser
- meta-openembedded

As such my first build was:

BB_VERSION= "1.31.0"
BUILD_SYS = "x86_64-linux"
NATIVELSBSTRING   = "SUSELINUX-42.1"
TARGET_SYS= "x86_64-oe-linux"
MACHINE   = "qemux86-64"
DISTRO= "nodistro"
DISTRO_VERSION= "nodistro.0"
TUNE_FEATURES = "m64 core2"
TARGET_FPU= ""
meta  = 
"kraj/master:f30e9793b8f247f691e5ffd023e1b83301508409"
meta-browser  = "master:77736988073a5d90fcff9d0005c8477332ede387"
meta-oe
meta-gnome
meta-multimedia   = "master:303d9ea960e2d88281079a4e71abe2cf8c815184"

Running chromium showed the failure, as usual.

So then I thought I'd try to recreate your build exactly -- except that's not 
possible:

oe-meta-go from https://github.com/errordeveloper/oe-meta-go doesn't 
contain a dc19a245ae5224d1c9859119a9c53b6331812400
meta-openembedded doesn't contain a 
f11f8664de82e4f8c23b075542f4c98c16ce1f5e
openembedded-core from https://github.com/kraj/openembedded-core 
doesn't contain a 96ed9e94082589a62a6c602e5f774c11de3328c6


But even at that, I ended up removing meta-metrological because:
ERROR: ParseError at 
/z/chromium-qemux86-64/meta-metrological/recipes-qt/qtbrowser/qtbrowser_2.0.11.bb:14:
 Could not inherit file classes/qmake5.bbclass


So I performed my build with:
BB_VERSION= "1.31.0"
BUILD_SYS = "x86_64-linux"
NATIVELSBSTRING   = "SUSELINUX-42.1"
TARGET_SYS= "x86_64-oe-linux"
MACHINE   = "qemux86-64"
DISTRO= "nodistro"
DISTRO_VERSION= "nodistro.0"
TUNE_FEATURES = "m64 core2"
TARGET_FPU= ""
meta-raspberrypi__kraj = "HEAD:b9ba221e520f39bc3e273f709b5ceea02897d525"
meta-qcom = "HEAD:0eaea003cac6c3175b0a3682efd6e1f20ecc9dab"
meta-96boards = "HEAD:6b2744bf3e82154a9329ab89cf03eec9d1f80837"
oe-meta-go= "master:0712320950adf810fb324d49fba5d49ae19981b0"
meta-browser  = "HEAD:77736988073a5d90fcff9d0005c8477332ede387"
meta-oe
meta-gnome
meta-multimedia   = "master:303d9ea960e2d88281079a4e71abe2cf8c815184"
meta  = 
"kraj/master:f30e9793b8f247f691e5ffd023e1b83301508409"

This build succeeded (with gcc-5%), but running chromium caused the failure to
occur, as usual.

In the last couple weeks I've built chromium for x86-64 52 times and haven't
once seen it run successfully unless glibc was at 2.23. Plus I've had someone
else independently build and run chromium once, and it failed. I'm baffled how
it could be failing for me but 

Re: [OE-core] [PATCH V2] glibc: Upgrade to latest tip of master

[Trevor Woerner]

On Thu 2016-07-07 @ 09:27:30 AM, Khem Raj wrote:
> Is it specific to x86-64

Up to this point I've only been focused on x86-64, but now that I have things
cleared up on that arch, I'll be working on aarch64 to see how that goes.

My "solution" for the time-being is to simply pull in the glibc_2.23 recipes
into my build and set GLIBCVERSION to match. At some point I'll be trying to
bisect the glibc commits themselves to see if I can find anything conclusive
(but, as always, that'll take some time).
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH V2] glibc: Upgrade to latest tip of master

[Trevor Woerner]

Even after applying this patch, I'm still seeing crashes in Chromium (which
aren't there before the glibc update to 2.24)

I wish I could understand why Chromium is crashing, but everything else seems
to run okay. I wouldn't be surprised to find Chromium is doing something
funky; but what, exactly, would be nice to know.
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 1/6] glibc: Add recipes for 2.24 release

[Trevor Woerner]

Hi Khem,

Sorry for the delay, I wanted to make absolutely sure of the statements in
this email so I started fresh and rebuilt everything from scratch a number of
times, stripped it down to the minimum, just to make sure I wasn't doing
something wrong with the things I'm doing in my normal builds. As you can
guess, building images (especially debug images) involving chromium can take a
while, not to mention I then need to download them from my build machine at
work to my home machine over a slow connection in order to run them... :-)


On Sun 2016-07-03 @ 08:02:04 AM, Khem Raj wrote:
> On Sun, Jul 3, 2016 at 6:45 AM, Trevor Woerner <twoer...@gmail.com> wrote:
> > I just finished a bisection task which implies this patch is the reason why
> > chromium crashes when run on x86_64 (minnow) with signal 4 ILL_ILLOPN. Note
> > that chromium compiles fine both before and after this patch, the problem is
> > when chromium is run.
> >
> > I'm not 100% how to move forward, at this point. Maybe the problem is caused
> > by the remove of the SSE patch?
> >
> > Any suggestions greatly appreciated! :-)
> >
> >
> > Received signal Received signal 44 ILL_ILLOPN  ILL_ILLOPN 
> > 557b2cb6cc90557b2cb6cc90
> 
> couple of ideas.
> 
> compile the image with debug info so we can see the full stack trace
> with symbols.

Taking your advice, I installed the chromium -dbg package to my minnow board,
then I installed all the -dbg packages opkg said the chromium -dbg package
recommended (28 in total) and re-ran the browser. I saw a slight improvement
in the dump to:

root@intel-corei7-64:~/opkg# export DISPLAY=:0
root@intel-corei7-64:~/opkg# google-chrome 
[808:808:0703/160711:ERROR:gl_implementation.cc(223)] Failed to load 
libGLESv2.so.2: libGLESv2.so.2: cannot open shared object file: No such file or 
directory
[808:808:0703/160712:ERROR:gpu_child_thread.cc(376)] Exiting GPU 
process due to errors during initialization
[780:800:0703/160712:ERROR:browser_gpu_channel_host_factory.cc(119)] 
Failed to launch GPU process.
[780:800:0703/160712:ERROR:browser_gpu_channel_host_factory.cc(119)] 
Failed to launch GPU process.
Received signal 4 ILL_ILLOPN 55f79db06c90
#0 0x55f7995a460e 
#1 0x55f7995a49d9 
#2 0x7fa49806fe40 
#3 0x55f79db06c90 
#4 0x55f79a2b5580 
#5 0x55f79a2b5d93 
#6 0x55f79a2b3956 
#7 0x55f79a2b41dc 
#8 0x55f79aa08c5d 
#9 0x55f79a9fd01e 
#10 0x55f79a9fdcf0 
#11 0x55f79cb295fe 
#12 0x55f79cb2a321 
#13 0x55f79cb1ea1b 
#14 0x55f79e03b172 
#15 0x55f79a0cfd86 
#16 0x55f79960e7fd 
#17 0x55f79e0a48ce 
#18 0x55f79e0a4ec4 
#19 0x55f79960e7fd 
#20 0x55f7995c265b 
#21 0x55f7995c31dd 
#22 0x55f7995c34ab 
#23 0x55f7995c4da9 
#24 0x55f7995db3fa 
#25 0x55f7995c1495 
#26 0x55f79cb40cd0 
#27 0x55f7995739a1 
#28 0x55f799573f3d 
#29 0x55f7995731d1 
#30 0x55f79913cf9a ChromeMain
#31 0x7fa493637040 
#32 0x55f79913cdfa _start
  r8:   r9:  r10:  r11: 
0202
 r12: 1884ff4181e0 r13: 0004 r14: 1884ff4181f8 r15: 
55f7a0ba0352
  di: 134bf2101000  si: 0001e000  bp: 1884ff464000  bx: 
1884ff418200
  dx: 0008  ax:   cx: ff58  sp: 
7ffe64badc10
  ip: 55f79db06c90 efl: 00010286 cgf: 0033 erf: 

 trp: 0006 msk:  cr2: 
[end of stack trace]


As you can see, I went from a dump where no symbols were known to one where
only one was known :-)

I then decided to build an image that included every -dbg package (by adding
"dbg-pkgs" to "EXTRA_IMAGE_FEATURES") and ran the resulting image only to end
up with the exact same trace as above; everything unknown except for one line
with ChromeMain, grrr. I wonder why that didn't work and how I could get it to
work better?



> secondly, see if it fails same way on qemux86-64 as well.


Good idea!

I created minimal, core-image-x11, builds for qemux86-64 and the problem is
demonstrated there as well.

I've attached my local.conf and my chromium recipe if anyone is interested in
seeing this same behaviour too.

At the last ELC I mentioned in the BoF that I was working on splitting the
chromium recipe into -x11 and -wayland parts so that the -x11 part could move
forward independently of the ozone patches. This is what I was working on when
I stumbled across this issue, so I wanted to clear this up before submitting
my chromium updates for review (and, hopefully, inclusion).

To make things easier, start w

Re: [OE-core] [PATCH 1/6] glibc: Add recipes for 2.24 release

[Trevor Woerner]

I just finished a bisection task which implies this patch is the reason why
chromium crashes when run on x86_64 (minnow) with signal 4 ILL_ILLOPN. Note
that chromium compiles fine both before and after this patch, the problem is
when chromium is run.

I'm not 100% how to move forward, at this point. Maybe the problem is caused
by the remove of the SSE patch?

Any suggestions greatly appreciated! :-)


Received signal Received signal 44 ILL_ILLOPN  ILL_ILLOPN 
557b2cb6cc90557b2cb6cc90

Received signal 4 ILL_ILLOPN 557b2cb6cc90
Received signal 4 ILL_ILLOPN 557b2cb6cc90
##0 00x 557b2860a60e0x 557b2860a60e 
#
1# 1 0x0x557b2860a9d9557b2860a9d9  
#2 0x7f0923227e40 

##32  0x0x7f0923227e40557b2cb6cc90  
#3 0x557b2cb6cc90 
#4 0x557b2931b580 
#5 0x557b2931bd93 Received signal 6

#6 0x557b29319956 #0 0x557b2860a60e 
#7 0x557b2931a1dc 
#1 0x557b2860a9d9 
#2 0x7f0923227e40 
#8
 #0x3557b29a6ec5d  0x7f091e801d38 
#9 0x557b29a6301e 
#10 0x
557b29a63cf0# 4 0x7f091e80318a 
#11 0x557b2bb8f5fe 
#5 0x557b28694b5a 
#
6# 120x 0x557b2869533b557b2bb90321  
#7 0x557b2860a885 
#8 0x557b2860a9f7 
#9 0x7f0923227e40 
#13 0x557b2bb84a1b 
#10 0x557b2cb6cc90 
#11 0x557b2931b580 
#12 0x557b2931bd93 
#13
 #0x14 557b293199560x 557b2d0a1172 
#14 0x557b2931a1dc 
#15 0x557b29a6ec5d 
#16 0x557b29a6301e 
#17 0x557b29a63cf0 
#
18#15  0x0x557b29135d86557b2bb8f5fe #0 0x557b2860a60e 
#19 0x557b2bb90321 
#20 0x557b2bb84a1b 
#21 0x557b2d0a1172 
#22 0x557b29135d86 
#1 0x557b2860a9d9 
#23 0x557b286747fd 
#24 0x557b2d10a8ce 
#25 0x557b2d10aec4 
#26 
0x#2557b286747fd 0x7f0923227e40  
#3 0x557b2cb6cc90 Received signal 11  

#4 0x557b2931b580 #0 0x557b2860a60e 
#1 0x557b2860a9d9 
#2 0x7f0923227e40
# 5 0x557b2931bd93 
#3 0x7f091e803286 
#6 0x557b29319956 
#7 0x557b2931a1dc 
#4 0x557b28694b5a 
#5 0x557b2869533b 

##8 60x 557b29a6ec5d0x 557b2860a885 
#7 0x557b2860a9f7 
#8 0x7f0923227e40 
#
9 #0x9557b29a6301e  0x7f091e801d38  #0 0x557b2860a60e 
#1 0x557b2860a9d9 
#2 0x7f0923227e40 
#10 0x557b29a63cf0 
#3 0x557b2cb6cc90 
#16 0x557b286747fd Received signal 6

#17 0x557b2d10a8ce #0 0x557b2860a60e 
#1 0x557b2860a9d9 
#18 0x557b2d10aec4 
#3 0x7f091e801d38 
#19 0x557b286747fd 
#20 0x557b2862865b 
#4 0x7f091e80318a 
#21 0x557b286291dd 
#22 0x557b286294ab 
#5 0x557b28694b5a 
#6 0x557b2869533b 
#7 0x557b2860a885 
#8 0x557b2860a9f7 
#9 0x7f0923227e40 
#23 
0x#557b2862ada910  0x557b2cb6cc90 
#11 0x557b2931b580 
#12 0x557b2931bd93 
#13 0x557b29319956 
#14 0x557b2931a1dc 
#15 0x557b29a6ec5d 
#16 0x557b29a6301e 
#17 0x557b29a63cf0 
#18 0x557b2bb8f5fe 
#19 0x557b2bb90321 
#20 0x557b2bb84a1b 

##2124  0x0x557b2d0a1172557b286413fa  
#25 0x557b28627495 
#26 0x557b2bba6cd0 
#27 0x557b285d99a1 
#28 0x557b285d9f3d 
#29 0x557b285d91d1 
#30 0x557b281a2f9a 
#31 0x7f091e7ef040 
#22 0x557b29135d86 
#32 0x557b281a2dfa 
  r8:   r9:  r10:  r11: 
0202
 r12: 27522aa181e0 r13: 0004 r14: 27522aa181f8 r15: 
557b2fc06352
  di: 357c8b781000  si: 0001e000  bp: 27522aa64000  bx: 
27522aa18200
  dx: 0008  ax:   cx: ff58  sp: 
7ffe2cd33b70
  ip: 557b2cb6cc90 efl: 00010286 cgf: 0033 erf: 

 trp: 0006 msk:  cr2: 
[end of stack trace]

#23 0x557b286747fd 
#24 0x557b2d10a8ce 
#11 0x557b2bb8f5fe 
#12 0x557b2bb90321 
#13 0x557b2bb84a1b 
#14 0x557b2d0a1172 
#15 0x557b29135d86 
#16 0x557b286747fd 
#17 0x557b2d10a8ce 
#18 0x557b2d10aec4 
#19 0x557b286747fd 
#20 0x557b2862865b 
#21 0x557b286291dd 
#25 0x557b2d10aec4 
#26 0x557b286747fd 
#27 0x557b2862865b 
#28 0x557b286291dd 
#22 0x557b286294ab 
#23 0x557b2862ada9 
#24 0x557b286413fa Received signal 11  
#0
 #0x25557b2860a60e  0x557b28627495 
#26 0x557b2bba6cd0 
#27 0x557b285d99a1 
#28 0x557b285d9f3d 
#29 0x557b285d91d1 
#30 0x557b281a2f9a 
#31 0x7f091e7ef040 
#1 0x557b2860a9d9 
#32 0x557b281a2dfa 
  r8:   r9:  r10:  r11: 
0202
 r12: 1991086181e0 r13: 0004 r14: 1991086181f8 r15: 
557b2fc06352
  di: 2a0341a41000  si: 0001e000  bp: 199108664000  bx: 
199108618200
  dx: 0008  ax:   cx: ff58  sp: 
7ffe2cd33b70
  ip: 557b2cb6cc90 efl: 00010286 cgf: 0033 erf: 

 trp: 0006 msk:  cr2: 
[end of stack trace]

#10 0x7f091e80318a 
#11 0x557b28694b5a 
#12 0x557b2869533b 
#13 0x557b2860a885 
#14 0x557b2860a9f7 
#15 0x7f0923227e40 
#16 0x557b2cb6cc90 
#17 0x557b2931b580 
#2 0x7f0923227e40 
#3 0x7f091e803286 
#4 0x557b28694b5a 
#5 0x557b2869533b 
#6 0x557b2860a885 
#18 0x557b2931bd93 
#19 0x557b29319956 
#20 0x557b2931a1dc 
#21 0x557b29a6ec5d
 #7 0x557b2860a9f7 
#8 0x7f0923227e40 
#9 0x7f091e801d38 
#22 
0x#557b29a6301e10  0x7f091e80318a 
#11 0x557b28694b5a 
#12 0x557b2869533b 
#13 0x557b2860a885 

Re: [OE-core] [PATCH] lib/oe/terminal.py: decode bytes variable before rstrip/split

[Trevor Woerner]

Thank you, that solves it! :-)
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] -c menuconfig stopped working in master

[Trevor Woerner]

It appears "bitbake virtual/kernel -c menuconfig" has stopped working in
master (python3-related?). The following is from a build on master of poky
(git://git.yoctoproject.org/poky) with qemux86 as the MACHINE (iow, the most
basic build). The same happens with master-next.

ERROR: linux-yocto-4.4.12+gitAUTOINC+8900370d33_1f3e98df09-r0 
do_menuconfig: Error executing a python function in exec_python_func() 
autogenerated:

The stack trace of python calls that resulted in this exception/failure 
was:
File: 'exec_python_func() autogenerated', lineno: 2, function: 
 0001:
 *** 0002:do_menuconfig(d)
 0003:
File: 
'/z/layerindex-master/layers/meta-poky/meta/classes/cml1.bbclass', lineno: 30, 
function: do_menuconfig
 0026:except OSError:
 0027:mtime = 0
 0028:
 0029:oe_terminal("${SHELL} -c \"make %s; if [ \$? -ne 0 ]; 
then echo 'Command failed.'; printf 'Press any key to continue... '; read r; 
fi\"" % d.getVar('KCONFIG_CONFIG_COMMAND', True),
 *** 0030:d.getVar('PN', True ) + ' Configuration', d)
 0031:
 0032:# FIXME this check can be removed when the minimum 
bitbake version has been bumped
 0033:if hasattr(bb.build, 'write_taint'):
 0034:try:
File: 
'/z/layerindex-master/layers/meta-poky/meta/classes/terminal.bbclass', lineno: 
90, function: oe_terminal
 0086:except oe.terminal.ExecutionError as exc:
 0087:bb.fatal('Unable to spawn terminal %s: %s' % 
(terminal, exc))
 0088:
 0089:try:
 *** 0090:oe.terminal.spawn_preferred(command, title, None, d)
 0091:except oe.terminal.NoSupportedTerminals:
 0092:bb.fatal('No valid terminal found, unable to open 
devshell')
 0093:except oe.terminal.ExecutionError as exc:
 0094:bb.fatal('Unable to spawn terminal %s: %s' % 
(terminal, exc))
File: '/z/layerindex-master/layers/meta-poky/meta/lib/oe/terminal.py', 
lineno: 197, function: spawn_preferred
 0193:def spawn_preferred(sh_cmd, title=None, env=None, d=None):
 0194:"""Spawn the first supported terminal, by priority"""
 0195:for terminal in prioritized():
 0196:try:
 *** 0197:spawn(terminal.name, sh_cmd, title, env, d)
 0198:break
 0199:except UnsupportedTerminal:
 0200:continue
 0201:else:
File: '/z/layerindex-master/layers/meta-poky/meta/lib/oe/terminal.py', 
lineno: 212, function: spawn
 0208:terminal = Registry.registry[name]
 0209:except KeyError:
 0210:raise UnsupportedTerminal(name)
 0211:
 *** 0212:pipe = terminal(sh_cmd, title, env, d)
 0213:output = pipe.communicate()[0]
 0214:if pipe.returncode != 0:
 0215:raise ExecutionError(sh_cmd, pipe.returncode, output)
 0216:
File: '/z/layerindex-master/layers/meta-poky/meta/lib/oe/terminal.py', 
lineno: 89, function: __init__
 0085:priority = 2
 0086:
 0087:def __init__(self, sh_cmd, title=None, env=None, d=None):
 0088:# Check version
 *** 0089:vernum = check_terminal_version("konsole")
 0090:if vernum and LooseVersion(vernum) < '2.0.0':
 0091:# Konsole from KDE 3.x
 0092:self.command = 'konsole -T "{title}" -e {command}'
 0093:XTerminal.__init__(self, sh_cmd, title, env, d)
File: '/z/layerindex-master/layers/meta-poky/meta/lib/oe/terminal.py', 
lineno: 249, function: check_terminal_version
 0245:newenv = os.environ.copy()
 0246:newenv["LANG"] = "C"
 0247:p = sub.Popen(['sh', '-c', cmdversion], 
stdout=sub.PIPE, stderr=sub.PIPE, env=newenv)
 0248:out, err = p.communicate()
 *** 0249:ver_info = out.rstrip().split('\n')
 0250:except OSError as exc:
 0251:import errno
 0252:if exc.errno == errno.ENOENT:
 0253:return None
Exception: TypeError: Type str doesn't support the buffer API
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] INHERIT += "image-buildinfo" doesn't parse

[Trevor Woerner]

On Sun 2016-06-05 @ 09:06:50 AM, Trevor Woerner wrote:
> On Sun 2016-06-05 @ 09:04:12 AM, Trevor Woerner wrote:
> > oh... wait, sorry my mistake I didn't test properly, let me try again...
> 
> yes, that fixes it :-D
> 
> (i was using git://git.yoctoproject.org/poky's meta instead of
> git://git.openembedded.org/openembedded-core.git's)

... and now that I check, I see that you've already pushed this to poky as
well. Sorry for the confusion, both work (my build was using one, I updated
the other, it didn't seem to work).
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] INHERIT += "image-buildinfo" doesn't parse

[Trevor Woerner]

On Sun 2016-06-05 @ 09:04:12 AM, Trevor Woerner wrote:
> oh... wait, sorry my mistake I didn't test properly, let me try again...

yes, that fixes it :-D

(i was using git://git.yoctoproject.org/poky's meta instead of
git://git.openembedded.org/openembedded-core.git's)
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] INHERIT += "image-buildinfo" doesn't parse

[Trevor Woerner]

oh... wait, sorry my mistake I didn't test properly, let me try again...
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] INHERIT += "image-buildinfo" doesn't parse

[Trevor Woerner]

On Sun 2016-06-05 @ 08:20:11 AM, Richard Purdie wrote:
> On Sat, 2016-06-04 at 18:55 -0400, Trevor Woerner wrote:
> > Any config with
> > INHERIT += "image-buildinfo"
> > doesn't parse on master (updated moments ago):
> > 
> > ERROR: Error in compiling python function in /z/layerindex
> > -master/layers/meta-poky/meta/classes/image-buildinfo.bbclass, line
> > 27:
> > 
> > The code lines resulting in this error were:
> > SyntaxError: invalid syntax (image-buildinfo.bbclass, line 35)
> > 
> > bb.BBHandledException: invalid syntax (image-buildinfo.bbclass,
> > line 35)
> 
> I've tweaked line 35 which used an obsolete python syntax so was an
> obvious/trivial fix. I've not tested it though...

I've pulled your change (6e7d9dd9b5cbf46b955036876a25353fafbf264c) but it's
still not happy:

ERROR: Error parsing configuration files
Traceback (most recent call last):
  File 
"/z/layerindex-master/layers/meta-poky/bitbake/lib/bb/parse/parse_py/BBHandler.py",
 line 145, in 
handle(fn='/z/layerindex-master/layers/meta-poky/meta/classes/image-buildinfo.bbclass',
 d=, include=True):
 try:
>statements.eval(d)
 except bb.parse.SkipRecipe:
  File "/z/layerindex-master/layers/meta-poky/bitbake/lib/bb/parse/ast.py", 
line 38, in StatementGroup.eval(data=):
 for statement in self:
>statement.eval(data)

  File "/z/layerindex-master/layers/meta-poky/bitbake/lib/bb/parse/ast.py", 
line 187, in PythonMethodNode.eval(data=):
 text = '\n'.join(self.body)
>bb.methodpool.insert_method(self.modulename, text, self.filename, 
self.lineno - len(self.body) - 1)
 data.setVarFlag(self.function, "func", 1)
  File "/z/layerindex-master/layers/meta-poky/bitbake/lib/bb/methodpool.py", 
line 27, in insert_method(modulename='image-buildinfo.bbclass', code='def 
get_layer_git_status(path):\nimport subprocess\ntry:\n
subprocess.check_output("cd %s; PSEUDO_UNLOAD=1 git diff --quiet --no-ext-diff" 
% path,\nshell=True,\n  
  stderr=subprocess.STDOUT)\nreturn ""\nexcept 
subprocess.CalledProcessError, ex:\n# Silently treat errors as 
"modified", without checking for the\n# (expected) return code 1 in a 
modified git repo. For example, we get\n# output and a 129 return code 
when a layer isn\'t a git repo at all.\nreturn "-- modified"\n', 
fn='/z/layerindex-master/layers/meta-poky/meta/classes/image-buildinfo.bbclass',
 lineno=27):
 """
>comp = better_compile(code, modulename, fn, lineno=lineno)
 better_exec(comp, None, code, fn)
  File "/z/layerindex-master/layers/meta-poky/bitbake/lib/bb/utils.py", line 
330, in better_compile(text='def get_layer_git_status(path):\nimport 
subprocess\ntry:\nsubprocess.check_output("cd %s; PSEUDO_UNLOAD=1 
git diff --quiet --no-ext-diff" % path,\n
shell=True,\nstderr=subprocess.STDOUT)\n
return ""\nexcept subprocess.CalledProcessError, ex:\n# Silently 
treat errors as "modified", without checking for the\n# (expected) 
return code 1 in a modified git repo. For example, we get\n# output and 
a 129 return code when a layer isn\'t a git repo at all.\nreturn "-- 
modified"\n', file='image-buildinfo.bbclass', 
realfile='/z/layerindex-master/layers/meta-poky/meta/classes/image-buildinfo.bbclass',
 mode='exec', lineno=27):
 e = bb.BBHandledException(e)
>raise e

bb.BBHandledException: invalid syntax (image-buildinfo.bbclass, line 35)
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] INHERIT += "image-buildinfo" doesn't parse

[Trevor Woerner]

Any config with
INHERIT += "image-buildinfo"
doesn't parse on master (updated moments ago):

ERROR: Error in compiling python function in 
/z/layerindex-master/layers/meta-poky/meta/classes/image-buildinfo.bbclass, 
line 27:

The code lines resulting in this error were:
SyntaxError: invalid syntax (image-buildinfo.bbclass, line 35)
ERROR: Error parsing configuration files
Traceback (most recent call last):
  File 
"/z/layerindex-master/layers/meta-poky/bitbake/lib/bb/parse/parse_py/BBHandler.py",
 line 145, in 
handle(fn='/z/layerindex-master/layers/meta-poky/meta/classes/image-buildinfo.bbclass',
 d=, include=True):
 try:
>statements.eval(d)
 except bb.parse.SkipRecipe:
  File 
"/z/layerindex-master/layers/meta-poky/bitbake/lib/bb/parse/ast.py", line 38, 
in StatementGroup.eval(data=):
 for statement in self:
>statement.eval(data)
 
  File 
"/z/layerindex-master/layers/meta-poky/bitbake/lib/bb/parse/ast.py", line 187, 
in PythonMethodNode.eval(data=):
 text = '\n'.join(self.body)
>bb.methodpool.insert_method(self.modulename, text, 
self.filename, self.lineno - len(self.body) - 1)
 data.setVarFlag(self.function, "func", 1)
  File 
"/z/layerindex-master/layers/meta-poky/bitbake/lib/bb/methodpool.py", line 27, 
in insert_method(modulename='image-buildinfo.bbclass', code='def 
get_layer_git_status(path):\nimport subprocess\ntry:\n
subprocess.check_output("cd %s; PSEUDO_UNLOAD=1 git diff --quiet --no-ext-diff" 
% path,\nshell=True,\n  
  stderr=subprocess.STDOUT)\nreturn ""\nexcept 
subprocess.CalledProcessError, ex:\n# Silently treat errors as 
"modified", without checking for the\n# (expected) return code 1 in a 
modified git repo. For example, we get\n# output and a 129 return code 
when a layer isn\'t a git repo at all.\nreturn "-- modified"\n', 
fn='/z/layerindex-master/layers/meta-poky/meta/classes/image-buildinfo.bbclass',
 lineno=27):
 """
>comp = better_compile(code, modulename, fn, lineno=lineno)
 better_exec(comp, None, code, fn)
  File "/z/layerindex-master/layers/meta-poky/bitbake/lib/bb/utils.py", 
line 330, in better_compile(text='def get_layer_git_status(path):\nimport 
subprocess\ntry:\nsubprocess.check_output("cd %s; PSEUDO_UNLOAD=1 
git diff --quiet --no-ext-diff" % path,\n
shell=True,\nstderr=subprocess.STDOUT)\n
return ""\nexcept subprocess.CalledProcessError, ex:\n# Silently 
treat errors as "modified", without checking for the\n# (expected) 
return code 1 in a modified git repo. For example, we get\n# output and 
a 129 return code when a layer isn\'t a git repo at all.\nreturn "-- 
modified"\n', file='image-buildinfo.bbclass', 
realfile='/z/layerindex-master/layers/meta-poky/meta/classes/image-buildinfo.bbclass',
 mode='exec', lineno=27):
 e = bb.BBHandledException(e)
>raise e
 
bb.BBHandledException: invalid syntax (image-buildinfo.bbclass, line 35)
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] layerindex upvoting Was: [oe] OE Changelog since 2016-05-15 until 2016-05-22

[Trevor Woerner]

On Fri 2016-05-27 @ 08:25:23 AM, Paul Eggleton wrote:
> On Thu, 26 May 2016 22:18:34 Andreas Müller wrote:
> > On Thu, May 26, 2016 at 10:14 PM, Paul Eggleton
> > 
> >  wrote:
> > > On Thu, 26 May 2016 13:46:21 Cliff Brake wrote:
> > >> On Tue, May 24, 2016 at 5:23 AM, Maxin B. John  
> wrote:
> > >> > meta-java repo was moved to:
> > >> > git://git.yoctoproject.org/meta-java
> > >> > 
> > >> > Is it possible to update the list with that info?
> > >> 
> > >> Done, thanks!
> > >> 
> > >> https://github.com/cbrake/openembedded-admin/commit/51604da79ed5a02341562
> > >> a9b f254b3dd9dc71704
> > > 
> > > At some point it would be great if this script could be driven from the OE
> > > layer index rather than being a separate entity - then updates would
> > > largely be self-service for the maintainers, or at least they would only
> > > need to be done in one place.
> > 
> > Maybe a bit off-topic but layer index should have some mechanism of
> > removing rotten layers.
> 
> We've discussed this on-and-off at OE developer meetings for a while now. 
> FWIW 
> I can remove them manually - actually I just got around to deleting meta-
> picosam9 which has been unmaintained for years.
> 
> Part of the problem though is determining what "rotten" actually means. 
> Additionally, there's an element of leaving things around in case someone 
> comes to fork/revive them again. We do show a "last updated" date but it 
> would 
> be good to figure out some other way of determining and indicating "layer 
> health" - to date I don't think we've managed to figure out anything 
> practical 
> for that.

It's nice to see this topic come up. For the last couple OEDEMs and OEDAMs I'm
usually the person to brings this up and it usually gets bandied about for a
while. There's certainly lots of interest in general and from the toaster
people in particular since old layers are likely to cause a build to fail
which leaves a bad impression on newbies.

Currently the best idea we've come up with is to have an opt-in class that
people can enable in their builds which will "phone home" to the layer index
indicating what was build (target, distro) which which layers. Hopefully we'll
think of a way of giving some sort of relevant status in the layer index;
maybe with different coloured balls (a la Jenkins) or something to click on
for the data. I.e. someone built a poky image for a raspi2 using master 2 days
ago and it succeeded, but the 3 people who tried since have all seen failures.
Maybe toaster could use this info somehow too.

Ideally, as a start, we would only record nodistro, core-image-minimal builds.
If people fed in their results with various branches and various (BSP) layers
doing this build in a month we'd have something meaningful.

We're open to any suggestions :-)
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] Please help edit OEDAM minutes

[Trevor Woerner]

On Fri 2016-05-13 @ 09:57:07 AM, Trevor Woerner wrote:
> On Thu 2016-05-12 @ 04:32:01 PM, Jeff Osier-Mixon wrote:
> > I admit defeat. I have been "trying to get to" the OEDAM minutes for a
> > month and I am clearly not getting to it, so I am now getting out of
> > the way. We are crowdsourcing these minutes, because collaborative
> > effort is what we do best.
> > 
> > My raw notes from the meeting are here. If you were present, please
> > help edit, fill in gaps, etc.
> > 
> > https://docs.google.com/document/d/1rPvy-QQkP0Z4a0PGOBkljfzGGzFVWREDz18vZzWyL9s/edit?usp=sharing
> 
> Ok, I'll take a stab at some formatting and stuff.

I've reformatted the notes (hope you like/prefer it?). Also, any place where
comments were recorded and attributed to me I tried to expand them to full
sentences and add the things I remember saying :-)

If everyone took 30 minutes to check/expand on anything attributed to them
that'd be great.

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

Re: [OE-core] Please help edit OEDAM minutes

[Trevor Woerner]

On Thu 2016-05-12 @ 04:32:01 PM, Jeff Osier-Mixon wrote:
> I admit defeat. I have been "trying to get to" the OEDAM minutes for a
> month and I am clearly not getting to it, so I am now getting out of
> the way. We are crowdsourcing these minutes, because collaborative
> effort is what we do best.
> 
> My raw notes from the meeting are here. If you were present, please
> help edit, fill in gaps, etc.
> 
> https://docs.google.com/document/d/1rPvy-QQkP0Z4a0PGOBkljfzGGzFVWREDz18vZzWyL9s/edit?usp=sharing

Ok, I'll take a stab at some formatting and stuff.
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] Yocto Project Status WW17

[Trevor Woerner]

On Fri 2016-04-22 @ 08:29:19 PM, Burton, Ross wrote:
> On 22 April 2016 at 18:04, Trevor Woerner <twoer...@gmail.com> wrote:
> >
> > Have the eSDK and CROPS projects been announced publicly? Are they
> available
> > for us to "play with"?
> 
> 
> eSDK is the "extensible SDK', or what appears when you do bitbake image -c
> populate_sdk_ext.  This should be in the manual already, the tl;dr is that
> its an SDK you can manipulate after installation.

Thanks for the update.

> CROPS is docker magic to do builds on Windows/Mac.  Todor did a
> presentation at ELC: http:
> //events.linuxfoundation.org/sites/events/files/slides/Todor_Minchev_CROPS_ELC_2016.pdf
> <http://events.linuxfoundation.org/sites/events/files/slides/Todor_Minchev_CROPS_ELC_2016.pdf>

I was *very* excited to learn about CROPS at ELC, which is why I was wondering
if it was available to experiment with somewhere?
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] Yocto Project Status WW17

[Trevor Woerner]

On Fri 2016-04-22 @ 03:13:21 PM, Jolley, Stephen K wrote:
> o   Encourage adoption of new tools (toaster, eSDK, CROPS)

Have the eSDK and CROPS projects been announced publicly? Are they available
for us to "play with"?
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [oe] OEDAM, April 8 in San Diego after ELC

[Trevor Woerner]

On Wed 2016-03-23 @ 09:36:40 AM, akuster808 wrote:
> There are only 10 people signed up.
> Is that enough people to justify the expense room or even meet?

I have no idea what the budget might be or what a room might cost. I'll leave
it to those who do know to worry about the costs versus the benefits.

In any case I certainly think it's still worth meeting. A smaller, more
focused group can sometimes get more done than a larger group. Secondly, it's
my experience that more people always show up than sign up.

With a project like this there will always be things to discuss, and sometimes
a discussion goes better in person rather than online.

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

Re: [OE-core] State of bitbake world, Failed tasks 2016-03-16

[Trevor Woerner]

On Thu 2016-03-17 @ 03:43:57 PM, Martin Jansa wrote:
> c278358 metadata-revs: provide more information

I think the general consensus was to not accept patch c278358 since it
affected the layout of a file that was expected to be processed by scripts.

> e2bf30c buildhistory.bbclass: metadata-revs show repo parent

But I *think* everyone was okay with this one?
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] metadata-revs: provide more information

[Trevor Woerner]

On 03/13/16 16:53, Paul Eggleton wrote:

On Sun, 13 Mar 2016 16:42:41 Trevor Woerner wrote:

That's the problem I'm trying to solve: how can I easily keep all the
information required to reproduce this build, exactly. The whole "two
meta's" thing was just a speed bump.


Right, understood, and it does make sense. I'm convinced there is an
underlying problem to fix that this just papers over though.


Okay, I think I see your point, and I agree. There is a layer clone 
problem that should be addressed.


But again, I think this is a speed bump.

My underlying point is that we're purposefully leaving out information 
that is vital to reproducible builds.




This probably fits with what you said at OEDEM, which was that too often the
system doesn't build properly out of the box for various boards. Have you had
a chance to think about that problem further?


Oh yes, but I'm rather sure nobody's going to like my suggestion, which 
makes me hesitant to suggest it ;-)


It should be possible for me to hand you _one_ configuration file and 
from that you could reproduce my entire build in _one_ step by issuing 
_one_ command. If I can get something to build successfully for a given 
board, you should too. But currently that's not always the case.


bblayers.conf and local.conf should somehow be rolled into one and the 
build should have some sort of "repo tool"-like functionality built in.


I hand you this one configuration file, you run "bitbake some-or-other" 
and the build starts by going through the provided list of layers 
checking out the exact ones I have used and potentially checking them 
out at the exact revisions I've used. This means the layer list will 
have to specify from where the layer was found, which branch, what the 
HEAD was, etc. In other words, exactly the information I'm trying to 
capture at the end of any build today.


I really think this might help everyone.

Newbies would have a better out-of-box experience. Chances are they just 
bought some board and want to make a build for it. I think it is rare 
that someone stumbles onto The Yocto Project and is happy just doing 
builds for qemu. My belief is that people find The Yocto Project as a 
secondary event, the main event is they want to perform a build for the 
hardware that just arrived and is sitting on their desk. The generic 
documentation doesn't target their board specifically, so in addition to 
trying to understand this new build system, they also have to figure out 
how to get a layer, where to get it from, and how to add it to their 
build. I know that The Yocto Project does have BSPs for beaglebone, 
raspberry pi 2, generic x86(-64), edgerouter, and some ppc board... and 
if this newbie happens to have one of those, things might go better. But 
if they have some other board...


I think experienced developers would be helped too by the combined 
config+layer-full-details thing too. For example, developers would swap 
configs between each other more easily, and build artifacts could be 
kept for future reference which is very important in a production 
environment.


The current way of doing things purposely hides information, and this is 
bad.


bblayers only tells you that on a given day on a specific machine there 
was a layer at a specific location that was used for this build. If that 
layer is something that was pulled from somewhere else (and not, as Khem 
was mentioning, something that was done locally) then there is no 
mechanism anywhere that preserves this information. There's a gap; a gap 
in the information. On my machine there's a meta-browser layer, on 
github there are hundreds of meta-browser layers, bblayers just says I 
used something called meta-browser... but the link is missing which 
points to from where I got this layer.


If I wanted to be really devious I could clone my repositories with any 
weird old name I wanted. I could clone meta-browser and name it 
openembedded-core and clone openembedded-core and name it meta-trevor. 
My build would still work 100%, but good luck with that! :-D


The genie's out of the bottle. There already are hundreds of clones. 
There is no way to police it, there is no way to force people to use 
globally unique names. I don't know how you're going to fix something 
like that. I think the best thing is to recognize this is going to 
happen and take steps to mitigate the issue... such as specifying where 
layers are coming from both in the config (for external layers) and 
after the build to record what happened.


I don't want to embarrass anyone by giving names, and I certainly don't 
want to be seen as a troll :-( I've been playing around with a large 
number of boards for the last while and there are lots of issues that 
I've come across. I already mentioned my thoughts on the out-of-box 
experience for newbies who have just bought a board and now have to 
figure out how to successfully add a layer.


Another thing I come across is 

Re: [OE-core] [PATCH] metadata-revs: provide more information

[Trevor Woerner]

(sorry about my previous reply, somehow the quoting got messed up and 
was hard to read. hopefully this one is better)


Hi Paul,

On 03/13/16 15:26, Paul Eggleton wrote:

On Sat, 12 Mar 2016 21:35:29 Trevor Woerner wrote:

Provide many more details concerning the repositories that are used in a
particular build: the remote information, the layer, the local branch, the
remote branch the local branch tracks (if any), and the HEAD commit.

Signed-off-by: Trevor Woerner <twoer...@gmail.com>
---
  meta/classes/buildhistory.bbclass |  6 +-
  meta/classes/metadata_scm.bbclass | 18 ++
  2 files changed, 23 insertions(+), 1 deletion(-)

diff --git a/meta/classes/buildhistory.bbclass
b/meta/classes/buildhistory.bbclass index b6b4324..1b0ae0e 100644
--- a/meta/classes/buildhistory.bbclass
+++ b/meta/classes/buildhistory.bbclass
@@ -615,9 +615,13 @@ def buildhistory_get_build_id(d):

  def buildhistory_get_metadata_revs(d):
  # We want an easily machine-readable format here, so
get_layers_branch_rev isn't quite what we want +import subprocess
  layers = (d.getVar("BBLAYERS", True) or "").split()
-medadata_revs = ["%-17s = %s:%s" % (os.path.relpath(i,
d.getVar('BBLAYERS_FETCH_DIR', True)), \ +medadata_revs = ["%s\tlayer:
%s\n\tbranch: %s\n\tremote: %s\n\tHEAD:   %s\n" % ( \ +
base_get_metadata_git_remote(i, None), \
+os.path.relpath(i, d.getVar('BBLAYERS_FETCH_DIR', True)), \
  base_get_metadata_git_branch(i, None).strip(), \
+base_get_metadata_git_remote_branch(i, None).strip(), \
  base_get_metadata_git_revision(i, None)) \
  for i in layers]
  return '\n'.join(medadata_revs)
diff --git a/meta/classes/metadata_scm.bbclass
b/meta/classes/metadata_scm.bbclass index 0f7f423..31a2c54 100644
--- a/meta/classes/metadata_scm.bbclass
+++ b/meta/classes/metadata_scm.bbclass
@@ -73,6 +73,15 @@ def base_get_metadata_git_branch(path, d):
  rev = ''
  return rev.strip()

+def base_get_metadata_git_remote_branch(path, d):
+import bb.process
+
+try:
+rev, _ = bb.process.run('git rev-parse --abbrev-ref
--symbolic-full-name @{u}', cwd=path) +except
bb.process.ExecutionError:
+rev = '(HEAD does not point to a remote branch)'
+return rev.strip()
+
  def base_get_metadata_git_revision(path, d):
  import bb.process

@@ -81,3 +90,12 @@ def base_get_metadata_git_revision(path, d):
  except bb.process.ExecutionError:
  rev = ''
  return rev.strip()
+
+def base_get_metadata_git_remote(path, d):
+import bb.process
+
+try:
+lines, _ = bb.process.run('git remote -v', cwd=path)
+except bb.process.ExecutionError:
+return ''
+return lines


As I mentioned in my other reply, metadata-revs was intended to be consumed by
scripts rather than humans, so I'd rather not change its format unless
absolutely necessary.



No problem, I had guessed that might be the case.

Would you (or anyone) be open to the possibility of the buildhistory 
task creating a second file that would contain this information?


I had been thinking about doing something like this for a long time. 
Having the two "meta" listings is what finally prompted me to actually 
do something about it. The fact that Ross pointed out that it was really 
the result of my own mistake is a little bit secondary to what I'm 
trying to accomplish.


I like to keep my build artifacts for a very long time. But I find when 
I'm looking through my old artifacts that I wish I had also kept the 
various configurations that led to that artifact's creation. ["Wait... I 
successfully built something for MACHINE XYZ back in June, how did I do 
that?"] So, along with the artifacts, I've also been keeping local.conf, 
auto.conf, bblayers.conf... and metadata-revs.


However, as I've pointed out, there are lots of clones around. Have you
taken a look at github recently? There are dozens of clones + tweaks to
many of the repositories we all know and love: beaglebone, odroid,
raspberrypi, browser. Sometimes it's one of these clones that works out
better for a given situation (MACHINE, board...) than the canonical. For 
example, if I want to add chromium to my DragonBoard410c build, I need 
to use Linaro's clone of meta-browser and not the canonical OSSystems' one.


The information currently provided by buildhistory/metadata-revs doesn't 
provide the level of detail required to distinguish between these two 
situations. In six months I would look at what I've built today, grab 
git://github.com/OSSystems/meta-browser.git, and then say: "how come 
there's no commit 5c00d0114c5963a178cb33f6d06181c588c03ae0?". It's not 
like there's any requirement to make the names of all layers universally 
unique.


That's the problem I'm trying to solve: how can I easily keep all the
information required to repro

Re: [OE-core] [PATCH] metadata-revs: provide more information

[Trevor Woerner]

Hi Paul,

On 03/13/16 15:26, Paul Eggleton wrote:

On Sat, 12 Mar 2016 21:35:29 Trevor Woerner wrote:

Provide many more details concerning the repositories that are used in a
particular build: the remote information, the layer, the local branch, the
remote branch the local branch tracks (if any), and the HEAD commit.

Signed-off-by: Trevor Woerner <twoer...@gmail.com>
---
  meta/classes/buildhistory.bbclass |  6 +-
  meta/classes/metadata_scm.bbclass | 18 ++
  2 files changed, 23 insertions(+), 1 deletion(-)

diff --git a/meta/classes/buildhistory.bbclass
b/meta/classes/buildhistory.bbclass index b6b4324..1b0ae0e 100644
--- a/meta/classes/buildhistory.bbclass
+++ b/meta/classes/buildhistory.bbclass
@@ -615,9 +615,13 @@ def buildhistory_get_build_id(d):

  def buildhistory_get_metadata_revs(d):
  # We want an easily machine-readable format here, so
get_layers_branch_rev isn't quite what we want +import subprocess
  layers = (d.getVar("BBLAYERS", True) or "").split()
-medadata_revs = ["%-17s = %s:%s" % (os.path.relpath(i,
d.getVar('BBLAYERS_FETCH_DIR', True)), \ +medadata_revs = ["%s\tlayer:
%s\n\tbranch: %s\n\tremote: %s\n\tHEAD:   %s\n" % ( \ +
base_get_metadata_git_remote(i, None), \
+os.path.relpath(i, d.getVar('BBLAYERS_FETCH_DIR', True)), \
  base_get_metadata_git_branch(i, None).strip(), \
+base_get_metadata_git_remote_branch(i, None).strip(), \
  base_get_metadata_git_revision(i, None)) \
  for i in layers]
  return '\n'.join(medadata_revs)
diff --git a/meta/classes/metadata_scm.bbclass
b/meta/classes/metadata_scm.bbclass index 0f7f423..31a2c54 100644
--- a/meta/classes/metadata_scm.bbclass
+++ b/meta/classes/metadata_scm.bbclass
@@ -73,6 +73,15 @@ def base_get_metadata_git_branch(path, d):
  rev = ''
  return rev.strip()

+def base_get_metadata_git_remote_branch(path, d):
+import bb.process
+
+try:
+rev, _ = bb.process.run('git rev-parse --abbrev-ref
--symbolic-full-name @{u}', cwd=path) +except
bb.process.ExecutionError:
+rev = '(HEAD does not point to a remote branch)'
+return rev.strip()
+
  def base_get_metadata_git_revision(path, d):
  import bb.process

@@ -81,3 +90,12 @@ def base_get_metadata_git_revision(path, d):
  except bb.process.ExecutionError:
  rev = ''
  return rev.strip()
+
+def base_get_metadata_git_remote(path, d):
+import bb.process
+
+try:
+lines, _ = bb.process.run('git remote -v', cwd=path)
+except bb.process.ExecutionError:
+return ''
+return lines

As I mentioned in my other reply, metadata-revs was intended to be consumed by
scripts rather than humans, so I'd rather not change its format unless
absolutely necessary.


No problem, I had guessed that might be the case.

Would you (or anyone) be open to the possibility of the buildhistory 
task creating a second file that would contain this information?


I had been thinking about doing something like this for a long time. 
Having the two "meta" listings is what finally prompted me to actually 
do something about it. The fact that Ross pointed out that it was really 
the result of my own mistake is a little bit secondary to what I'm 
trying to accomplish.


I like to keep my build artifacts for a very long time. But I find when 
I'm looking through my old artifacts that I wish I had also kept the 
various configurations that led to that artifact's creation. ["Wait... I 
successfully built something for MACHINE XYZ back in June, how did I do 
that?"] So along with the artifacts I've also been keeping local.conf, 
auto.conf, bblayers.conf... and metadata-revs.


However, as I've pointed out, there are lots of clones around. Have you 
taken a look at github recently? There are dozens of clones + tweaks to 
many of the repositories we all know and love: beaglebone, odroid, 
raspberrypi, browser. Sometimes it's one of these clones that works out 
better for a given situation (MACHINE, board...) than the canonical. For 
example, if I want to add chromium to my DragonBoard410c build, I need 
to use Linaro's clone of meta-browser and not the canonical OSSystems' one.


The information currently provided by buildhistory/metadata-revs doesn't 
provide the level of detail required to distinguish between these two 
situations. In six months I would look at what I've built today, grab 
git://github.com/OSSystems/meta-browser.git, and then say: "how come 
there's no commit 5c00d0114c5963a178cb33f6d06181c588c03ae0?". It's not 
like there's any requirement to make the names of all layers universally 
unique.


That's the problem I'm trying to solve: how can I easily keep all the 
information required to reproduce this build, exactly. The whole "two 
meta's" thing was just a speed bump.

--
___
Openembedded-core mailing list
O

[OE-core] [PATCH] metadata-revs: provide more information

[Trevor Woerner]

Provide many more details concerning the repositories that are used in a
particular build: the remote information, the layer, the local branch, the
remote branch the local branch tracks (if any), and the HEAD commit.

Signed-off-by: Trevor Woerner <twoer...@gmail.com>
---
 meta/classes/buildhistory.bbclass |  6 +-
 meta/classes/metadata_scm.bbclass | 18 ++
 2 files changed, 23 insertions(+), 1 deletion(-)

diff --git a/meta/classes/buildhistory.bbclass 
b/meta/classes/buildhistory.bbclass
index b6b4324..1b0ae0e 100644
--- a/meta/classes/buildhistory.bbclass
+++ b/meta/classes/buildhistory.bbclass
@@ -615,9 +615,13 @@ def buildhistory_get_build_id(d):
 
 def buildhistory_get_metadata_revs(d):
 # We want an easily machine-readable format here, so get_layers_branch_rev 
isn't quite what we want
+import subprocess
 layers = (d.getVar("BBLAYERS", True) or "").split()
-medadata_revs = ["%-17s = %s:%s" % (os.path.relpath(i, 
d.getVar('BBLAYERS_FETCH_DIR', True)), \
+medadata_revs = ["%s\tlayer:  %s\n\tbranch: %s\n\tremote: %s\n\tHEAD:   
%s\n" % ( \
+base_get_metadata_git_remote(i, None), \
+os.path.relpath(i, d.getVar('BBLAYERS_FETCH_DIR', True)), \
 base_get_metadata_git_branch(i, None).strip(), \
+base_get_metadata_git_remote_branch(i, None).strip(), \
 base_get_metadata_git_revision(i, None)) \
 for i in layers]
 return '\n'.join(medadata_revs)
diff --git a/meta/classes/metadata_scm.bbclass 
b/meta/classes/metadata_scm.bbclass
index 0f7f423..31a2c54 100644
--- a/meta/classes/metadata_scm.bbclass
+++ b/meta/classes/metadata_scm.bbclass
@@ -73,6 +73,15 @@ def base_get_metadata_git_branch(path, d):
 rev = ''
 return rev.strip()
 
+def base_get_metadata_git_remote_branch(path, d):
+import bb.process
+
+try:
+rev, _ = bb.process.run('git rev-parse --abbrev-ref 
--symbolic-full-name @{u}', cwd=path)
+except bb.process.ExecutionError:
+rev = '(HEAD does not point to a remote branch)'
+return rev.strip()
+
 def base_get_metadata_git_revision(path, d):
 import bb.process
 
@@ -81,3 +90,12 @@ def base_get_metadata_git_revision(path, d):
 except bb.process.ExecutionError:
 rev = ''
 return rev.strip()
+
+def base_get_metadata_git_remote(path, d):
+import bb.process
+
+try:
+lines, _ = bb.process.run('git remote -v', cwd=path)
+except bb.process.ExecutionError:
+return ''
+return lines
-- 
2.7.0.rc3

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

Re: [OE-core] [PATCH] buildhistory.bbclass: metadata-revs show repo parent

[Trevor Woerner]

Here is how my latest incarnation looks with a "normal" build:

origin  git://git.openembedded.org/openembedded-core.git (fetch)
origin  git://git.openembedded.org/openembedded-core.git (push)
layer:  openembedded-core/meta
branch: 
contrib/twoerner/buildhistory-metatdata-revs-full-repository-remote

remote: (HEAD does not point to a remote branch)
HEAD:   9ad6e0cf8e1e7d0301ee98b55095294bd2b1c508

origin  git://git.openembedded.org/meta-openembedded (fetch)
origin  git://git.openembedded.org/meta-openembedded (push)
layer:  meta-openembedded/meta-oe
branch: master
remote: origin/master
HEAD:   a1e135a48add7575682bf53db5e02e753580

origin  git://git.openembedded.org/meta-openembedded (fetch)
origin  git://git.openembedded.org/meta-openembedded (push)
layer:  meta-openembedded/meta-gnome
branch: master
remote: origin/master
HEAD:   a1e135a48add7575682bf53db5e02e753580

origin  git://github.com/96boards/meta-rpb.git (fetch)
origin  git://github.com/96boards/meta-rpb.git (push)
layer:  meta-rpb
branch: master
remote: origin/master
HEAD:   203903ca6f4e8df09bef6ea3c6e899d07eca8df9

origin  https://github.com/96boards/meta-96boards.git (fetch)
origin  https://github.com/96boards/meta-96boards.git (push)
layer:  meta-96boards
branch: master
remote: origin/master
HEAD:   2be59f0d381b5ec173d7fc24f3ae14aaf47b8649

origin  https://github.com/ndechesne/meta-qcom.git (fetch)
origin  https://github.com/ndechesne/meta-qcom.git (push)
layer:  meta-qcom
branch: master
remote: origin/master
HEAD:   32fcda819acb8ec485d9ab05108d554f807bf75d

origin  git://github.com/OSSystems/meta-browser.git (fetch)
origin  git://github.com/OSSystems/meta-browser.git (push)
layer:  meta-browser
branch: master
remote: origin/master
HEAD:   a3789a4168fcd42f1cdf5b5febe2c779a9467919

origin  git://git.linaro.org/openembedded/meta-linaro.git (fetch)
origin  git://git.linaro.org/openembedded/meta-linaro.git (push)
layer:  meta-linaro/meta-linaro-toolchain
branch: master
remote: origin/master
HEAD:   367f784b831938dc508b7d472342d2d0d6ed9769

origin  git://git.yoctoproject.org/poky (fetch)
origin  git://git.yoctoproject.org/poky (push)
layer:  meta-poky/meta
branch: master
remote: origin/master
HEAD:   37b61b059031e3c272a929b834e12fd83f46598c

origin  git://git.yoctoproject.org/poky (fetch)
origin  git://git.yoctoproject.org/poky (push)
layer:  meta-poky/meta-poky
branch: master
remote: origin/master
HEAD:   37b61b059031e3c272a929b834e12fd83f46598c


--
here is how it looks with a build where the repositories are managed by 
the 'repo' tool:


github  https://github.com/openembedded/openembedded-core (fetch)
github  https://github.com/openembedded/openembedded-core (push)
layer:  meta
branch: contrib/twoerner/buildhistory-patches
remote: (HEAD does not point to a remote branch)
HEAD:   a77ff8f9b203fdfbd04fabc94613face86e52af5

github  https://github.com/openembedded/meta-openembedded (fetch)
github  https://github.com/openembedded/meta-openembedded (push)
layer:  ../meta-openembedded/meta-oe
branch: HEAD
remote: (HEAD does not point to a remote branch)
HEAD:   dc5634968b270dde250690609f0015f881db81f2

github  https://github.com/openembedded/meta-openembedded (fetch)
github  https://github.com/openembedded/meta-openembedded (push)
layer:  ../meta-openembedded/meta-gnome
branch: HEAD
remote: (HEAD does not point to a remote branch)
HEAD:   dc5634968b270dde250690609f0015f881db81f2

github  https://github.com/96boards/meta-rpb (fetch)
github  https://github.com/96boards/meta-rpb (push)
layer:  ../meta-rpb
branch: HEAD
remote: (HEAD does not point to a remote branch)
HEAD:   203903ca6f4e8df09bef6ea3c6e899d07eca8df9

github  https://github.com/96boards/meta-96boards (fetch)
github  https://github.com/96boards/meta-96boards (push)
layer:  ../meta-96boards
branch: HEAD
remote: (HEAD does not point to a remote branch)
HEAD:   2be59f0d381b5ec173d7fc24f3ae14aaf47b8649

linaro  http://git.linaro.org/openembedded/meta-linaro (fetch)
linaro  http://git.linaro.org/openembedded/meta-linaro (push)
layer:  ../meta-linaro/meta-linaro-toolchain
branch: HEAD
remote: (HEAD does not point to a remote branch)
HEAD:   395ca11e22c26bd0c26ea1078722628ba6aa2332

github  https://github.com/ndechesne/meta-qcom (fetch)
github  https://github.com/ndechesne/meta-qcom (push)
layer:  ../meta-qcom
branch: HEAD
remote: (HEAD does not point to a remote branch)
HEAD:   

Re: [OE-core] [PATCH] buildhistory.bbclass: metadata-revs show repo parent

[Trevor Woerner]

On 03/12/16 16:54, Burton, Ross wrote:


On 12 March 2016 at 04:28, Trevor Woerner <twoer...@gmail.com 
<mailto:twoer...@gmail.com>> wrote:


openembedded-core/meta =
master:00d3fd571a8d261d065b43f5cf3076a381843984
meta-openembedded/meta-oe =
master:a1e135a48add7575682bf53db5e02e753580
meta-openembedded/meta-gnome =
master:a1e135a48add7575682bf53db5e02e753580
meta-rpb  =
master:203903ca6f4e8df09bef6ea3c6e899d07eca8df9
meta-96boards =
master:2be59f0d381b5ec173d7fc24f3ae14aaf47b8649
meta-qcom =
master:32fcda819acb8ec485d9ab05108d554f807bf75d
meta-browser  =
master:a3789a4168fcd42f1cdf5b5febe2c779a9467919
meta-linaro/meta-linaro-toolchain =
master:367f784b831938dc508b7d472342d2d0d6ed9769
meta-poky/meta=
master:37b61b059031e3c272a929b834e12fd83f46598c
meta-poky/meta-poky =
master:37b61b059031e3c272a929b834e12fd83f46598c


Why are you pulling oe-core/meta and poky/meta into the same build 
considering they're literally the same layer?  You should either drop 
oe-core/meta or poky/meta from your bblayers.


Ok, thanks; good point.



However the output showing the full remote URLs seems a sensible 
improvement to me.




My hesitation is whether we want to replace the existing 
buildhistory/metadata-revs with my "improvements" or whether I should 
just create a second file with the updates. I don't want to break 
anyone's process should they have come to rely on that file being as it is.

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

Re: [OE-core] [PATCH] buildhistory.bbclass: metadata-revs show repo parent

[Trevor Woerner]

On 03/12/16 06:55, Khem Raj wrote:

On Sat, Mar 12, 2016 at 1:33 PM, Trevor Woerner <twoer...@gmail.com> wrote:

To me, the purpose of buildhistory's metadata-revs is to enable someone else
(or myself in the future) to recreate a specific build, that's why I always
save this file with any build artifacts. Simply saying "meta" isn't good
enough because it doesn't specify which repository's "meta". So the purpose
of this patch is to try to clarify which repositories we're talking about.


Before:
 meta  = master:00d3fd571a8d261d065b43f5cf3076a381843984
 meta-oe   = master:a1e135a48add7575682bf53db5e02e753580
 meta-gnome= master:a1e135a48add7575682bf53db5e02e753580
 meta-rpb  = master:203903ca6f4e8df09bef6ea3c6e899d07eca8df9
 meta-96boards = master:2be59f0d381b5ec173d7fc24f3ae14aaf47b8649
 meta-qcom = master:32fcda819acb8ec485d9ab05108d554f807bf75d
 meta-browser  = master:a3789a4168fcd42f1cdf5b5febe2c779a9467919
 meta-linaro-toolchain =
master:367f784b831938dc508b7d472342d2d0d6ed9769
 meta  = master:37b61b059031e3c272a929b834e12fd83f46598c
 meta-poky = master:37b61b059031e3c272a929b834e12fd83f46598c

After:
 openembedded-core/meta =
master:00d3fd571a8d261d065b43f5cf3076a381843984
 meta-openembedded/meta-oe =
master:a1e135a48add7575682bf53db5e02e753580
 meta-openembedded/meta-gnome =
master:a1e135a48add7575682bf53db5e02e753580
 meta-rpb  = master:203903ca6f4e8df09bef6ea3c6e899d07eca8df9
 meta-96boards = master:2be59f0d381b5ec173d7fc24f3ae14aaf47b8649
 meta-qcom = master:32fcda819acb8ec485d9ab05108d554f807bf75d
 meta-browser  = master:a3789a4168fcd42f1cdf5b5febe2c779a9467919
 meta-linaro/meta-linaro-toolchain =
master:367f784b831938dc508b7d472342d2d0d6ed9769
 meta-poky/meta= master:37b61b059031e3c272a929b834e12fd83f46598c
 meta-poky/meta-poky = master:37b61b059031e3c272a929b834e12fd83f46598c


I have a second patch, now, that will generate the following output, which I
think is even better:

 git://git.openembedded.org/openembedded-core.git
 openembedded-core/meta = master:00d3fd571a8d261d065b43f5cf3076a381843984

 git://git.openembedded.org/meta-openembedded
 meta-openembedded/meta-oe =
master:a1e135a48add7575682bf53db5e02e753580

 git://git.openembedded.org/meta-openembedded
 meta-openembedded/meta-gnome =
master:a1e135a48add7575682bf53db5e02e753580

 git://github.com/96boards/meta-rpb.git
 meta-rpb  = master:203903ca6f4e8df09bef6ea3c6e899d07eca8df9

 https://github.com/96boards/meta-96boards.git
 meta-96boards = master:2be59f0d381b5ec173d7fc24f3ae14aaf47b8649

 https://github.com/ndechesne/meta-qcom.git
 meta-qcom = master:32fcda819acb8ec485d9ab05108d554f807bf75d

 git://github.com/OSSystems/meta-browser.git
 meta-browser  = master:a3789a4168fcd42f1cdf5b5febe2c779a9467919

 git://git.linaro.org/openembedded/meta-linaro.git
 meta-linaro/meta-linaro-toolchain =
master:367f784b831938dc508b7d472342d2d0d6ed9769

 git://git.yoctoproject.org/poky
 meta-poky/meta= master:37b61b059031e3c272a929b834e12fd83f46598c

 git://git.yoctoproject.org/poky
 meta-poky/meta-poky = master:37b61b059031e3c272a929b834e12fd83f46598c

Frankly, there are too many forks and clones. There are too many
meta-beaglebone or meta-odroid or meta-raspberrypi repositories. If six
months from now I want to recreate a build I've done today, I'll need to
know the repository, where it's from, and which commit was checked out. My
latest patch provides that information.

Is this better?

what happens if one has a local checkout forked from upstream branch ?
it reports that one, so buildhistory is expecting you to control the repos
e.g. when using tools like repo, it gets utterly confused since its meant
to track local checkout SHAs not remote ones, may be your change
can establish a better origin tracking. it would be interesting to see
how it works with repo and when I have more than 1 remotes in a single
repo


Here's how it handled a build that I have where the repositories are 
handled by the repo tool:


https://github.com/openembedded/openembedded-core
meta  = 
contrib/twoerner/buildhistory-patches:953046fa31617a0c53f66faacf3fa9ef88375dee


https://github.com/openembedded/meta-openembedded
../meta-openembedded/meta-oe = HEAD:dc5634968b270dde250690609f0015f881db81f2

https://github.com/openembedded/meta-openembedded
../meta-openembedded/meta-gnome = 
HEAD:dc5634968b270dde250690609f0015f881db81f2


https://github.com/96boards/meta-rpb
../meta-rpb   = HEAD:203903ca6f4e8df09bef6ea3c6e899d07eca8df9

https://github.com/96boards/meta-96boards
../meta-96boards  = HEAD:2be59f0d381b5ec173d7fc24f3ae14aaf47b8649

http://git.linaro.org/openembedded/meta-linaro
../meta-linaro/met

Re: [OE-core] [PATCH] buildhistory.bbclass: metadata-revs show repo parent

[Trevor Woerner]

To me, the purpose of buildhistory's metadata-revs is to enable someone 
else (or myself in the future) to recreate a specific build, that's why 
I always save this file with any build artifacts. Simply saying "meta" 
isn't good enough because it doesn't specify which repository's "meta". 
So the purpose of this patch is to try to clarify which repositories 
we're talking about.



Before:
meta  = master:00d3fd571a8d261d065b43f5cf3076a381843984
meta-oe   = master:a1e135a48add7575682bf53db5e02e753580
meta-gnome= master:a1e135a48add7575682bf53db5e02e753580
meta-rpb  = master:203903ca6f4e8df09bef6ea3c6e899d07eca8df9
meta-96boards = master:2be59f0d381b5ec173d7fc24f3ae14aaf47b8649
meta-qcom = master:32fcda819acb8ec485d9ab05108d554f807bf75d
meta-browser  = master:a3789a4168fcd42f1cdf5b5febe2c779a9467919
meta-linaro-toolchain = 
master:367f784b831938dc508b7d472342d2d0d6ed9769

meta  = master:37b61b059031e3c272a929b834e12fd83f46598c
meta-poky = master:37b61b059031e3c272a929b834e12fd83f46598c

After:
openembedded-core/meta = 
master:00d3fd571a8d261d065b43f5cf3076a381843984
meta-openembedded/meta-oe = 
master:a1e135a48add7575682bf53db5e02e753580
meta-openembedded/meta-gnome = 
master:a1e135a48add7575682bf53db5e02e753580

meta-rpb  = master:203903ca6f4e8df09bef6ea3c6e899d07eca8df9
meta-96boards = master:2be59f0d381b5ec173d7fc24f3ae14aaf47b8649
meta-qcom = master:32fcda819acb8ec485d9ab05108d554f807bf75d
meta-browser  = master:a3789a4168fcd42f1cdf5b5febe2c779a9467919
meta-linaro/meta-linaro-toolchain = 
master:367f784b831938dc508b7d472342d2d0d6ed9769

meta-poky/meta= master:37b61b059031e3c272a929b834e12fd83f46598c
meta-poky/meta-poky = master:37b61b059031e3c272a929b834e12fd83f46598c


I have a second patch, now, that will generate the following output, 
which I think is even better:


git://git.openembedded.org/openembedded-core.git
openembedded-core/meta = 
master:00d3fd571a8d261d065b43f5cf3076a381843984


git://git.openembedded.org/meta-openembedded
meta-openembedded/meta-oe = 
master:a1e135a48add7575682bf53db5e02e753580


git://git.openembedded.org/meta-openembedded
meta-openembedded/meta-gnome = 
master:a1e135a48add7575682bf53db5e02e753580


git://github.com/96boards/meta-rpb.git
meta-rpb  = master:203903ca6f4e8df09bef6ea3c6e899d07eca8df9

https://github.com/96boards/meta-96boards.git
meta-96boards = master:2be59f0d381b5ec173d7fc24f3ae14aaf47b8649

https://github.com/ndechesne/meta-qcom.git
meta-qcom = master:32fcda819acb8ec485d9ab05108d554f807bf75d

git://github.com/OSSystems/meta-browser.git
meta-browser  = master:a3789a4168fcd42f1cdf5b5febe2c779a9467919

git://git.linaro.org/openembedded/meta-linaro.git
meta-linaro/meta-linaro-toolchain = 
master:367f784b831938dc508b7d472342d2d0d6ed9769


git://git.yoctoproject.org/poky
meta-poky/meta= master:37b61b059031e3c272a929b834e12fd83f46598c

git://git.yoctoproject.org/poky
meta-poky/meta-poky = master:37b61b059031e3c272a929b834e12fd83f46598c

Frankly, there are too many forks and clones. There are too many 
meta-beaglebone or meta-odroid or meta-raspberrypi repositories. If six 
months from now I want to recreate a build I've done today, I'll need to 
know the repository, where it's from, and which commit was checked out. 
My latest patch provides that information.


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

Re: [OE-core] [PATCH] buildhistory.bbclass: metadata-revs show repo parent

[Trevor Woerner]

On 03/11/16 22:59, Khem Raj wrote:



On Mar 12, 2016 9:50 AM, "Trevor Woerner" <twoer...@gmail.com 
<mailto:twoer...@gmail.com>> wrote:

>
> Currently my build shows two "meta" repositories: one from meta-poky 
and one

> from openembedded-core. Have the code which prints the repositories into
> metadata-revs show the parent directories when repositories with 
multiple

> sub-layers are used.

Meta-poky is a leaf layer. So how is it offering conflicting meta layer ?



There's no conflict, I'm just trying to generate output the 
differentiates amongst leaf layers in its output.


Before:
meta  = master:00d3fd571a8d261d065b43f5cf3076a381843984
meta-oe   = master:a1e135a48add7575682bf53db5e02e753580
meta-gnome= master:a1e135a48add7575682bf53db5e02e753580
meta-rpb  = master:203903ca6f4e8df09bef6ea3c6e899d07eca8df9
meta-96boards = master:2be59f0d381b5ec173d7fc24f3ae14aaf47b8649
meta-qcom = master:32fcda819acb8ec485d9ab05108d554f807bf75d
meta-browser  = master:a3789a4168fcd42f1cdf5b5febe2c779a9467919
meta-linaro-toolchain = master:367f784b831938dc508b7d472342d2d0d6ed9769
meta  = master:37b61b059031e3c272a929b834e12fd83f46598c
meta-poky = master:37b61b059031e3c272a929b834e12fd83f46598c

After:
openembedded-core/meta = 
master:00d3fd571a8d261d065b43f5cf3076a381843984
meta-openembedded/meta-oe = 
master:a1e135a48add7575682bf53db5e02e753580
meta-openembedded/meta-gnome = 
master:a1e135a48add7575682bf53db5e02e753580

meta-rpb  = master:203903ca6f4e8df09bef6ea3c6e899d07eca8df9
meta-96boards = master:2be59f0d381b5ec173d7fc24f3ae14aaf47b8649
meta-qcom = master:32fcda819acb8ec485d9ab05108d554f807bf75d
meta-browser  = master:a3789a4168fcd42f1cdf5b5febe2c779a9467919
meta-linaro/meta-linaro-toolchain = 
master:367f784b831938dc508b7d472342d2d0d6ed9769

meta-poky/meta= master:37b61b059031e3c272a929b834e12fd83f46598c
meta-poky/meta-poky = master:37b61b059031e3c272a929b834e12fd83f46598c

So you see how it prints the parent layer for any leaf layers, which is 
more descriptive (and better?).







>
> Signed-off-by: Trevor Woerner <twoer...@gmail.com 
<mailto:twoer...@gmail.com>>

> ---
>  meta/classes/buildhistory.bbclass | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/meta/classes/buildhistory.bbclass 
b/meta/classes/buildhistory.bbclass

> index fac7fed..b6b4324 100644
> --- a/meta/classes/buildhistory.bbclass
> +++ b/meta/classes/buildhistory.bbclass
> @@ -616,7 +616,7 @@ def buildhistory_get_build_id(d):
>  def buildhistory_get_metadata_revs(d):
>  # We want an easily machine-readable format here, so 
get_layers_branch_rev isn't quite what we want

>  layers = (d.getVar("BBLAYERS", True) or "").split()
> -medadata_revs = ["%-17s = %s:%s" % (os.path.basename(i), \
> +medadata_revs = ["%-17s = %s:%s" % (os.path.relpath(i, 
d.getVar('BBLAYERS_FETCH_DIR', True)), \

>  base_get_metadata_git_branch(i, None).strip(), \
>  base_get_metadata_git_revision(i, None)) \
>  for i in layers]
> --
> 2.7.0.rc3
>
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org 
<mailto:Openembedded-core@lists.openembedded.org>

> http://lists.openembedded.org/mailman/listinfo/openembedded-core



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

Re: [OE-core] [PATCH][jethro][RFC 1/2] libsdl: expand PACKAGECONFIG and enable native builds

[Trevor Woerner]

On 03/11/16 18:16, Richard Purdie wrote:

On Fri, 2016-03-11 at 16:36 -0500, Trevor Woerner wrote:

Hi Ross,

On 03/11/16 15:49, Burton, Ross wrote:

On 11 March 2016 at 20:20, Trevor Woerner <twoer...@gmail.com
<mailto:twoer...@gmail.com>> wrote:

 ERROR: Nothing PROVIDES 'virtual/nativesdk-nativesdk-libx11'
(but
 virtual:nativesdk:/z/dragon410c-repo/dragon410c-tw
-jethro/layers/openembedded-core/meta/recipes
-graphics/libsdl/libsdl_1.2.15.bb
 <http://libsdl_1.2.15.bb> DEPENDS on or otherwise requires it).
 Close matches:


That's an awesome comment.  Clearly my testing wasn't optimal,
there's
another patch required.

Can you verify that
cherry-picking 55ca1fb8f0e81ff739b3c46897e43356d1f760c3 solves
this?

Yes, verified. Cherry-picking 55ca1fb8 solves the problem.

Thanks! :-)

I just merged the fix to the branch, thanks for testing.



Thank _you_ people for being so fast to respond to the issues your users 
find!

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

[OE-core] [PATCH] buildhistory.bbclass: metadata-revs show repo parent

[Trevor Woerner]

Currently my build shows two "meta" repositories: one from meta-poky and one
from openembedded-core. Have the code which prints the repositories into
metadata-revs show the parent directories when repositories with multiple
sub-layers are used.

Signed-off-by: Trevor Woerner <twoer...@gmail.com>
---
 meta/classes/buildhistory.bbclass | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/classes/buildhistory.bbclass 
b/meta/classes/buildhistory.bbclass
index fac7fed..b6b4324 100644
--- a/meta/classes/buildhistory.bbclass
+++ b/meta/classes/buildhistory.bbclass
@@ -616,7 +616,7 @@ def buildhistory_get_build_id(d):
 def buildhistory_get_metadata_revs(d):
 # We want an easily machine-readable format here, so get_layers_branch_rev 
isn't quite what we want
 layers = (d.getVar("BBLAYERS", True) or "").split()
-medadata_revs = ["%-17s = %s:%s" % (os.path.basename(i), \
+medadata_revs = ["%-17s = %s:%s" % (os.path.relpath(i, 
d.getVar('BBLAYERS_FETCH_DIR', True)), \
 base_get_metadata_git_branch(i, None).strip(), \
 base_get_metadata_git_revision(i, None)) \
 for i in layers]
-- 
2.7.0.rc3

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

Re: [OE-core] [PATCH][jethro][RFC 1/2] libsdl: expand PACKAGECONFIG and enable native builds

[Trevor Woerner]

Hi Ross,

On 03/11/16 15:49, Burton, Ross wrote:


On 11 March 2016 at 20:20, Trevor Woerner <twoer...@gmail.com 
<mailto:twoer...@gmail.com>> wrote:


ERROR: Nothing PROVIDES 'virtual/nativesdk-nativesdk-libx11' (but

virtual:nativesdk:/z/dragon410c-repo/dragon410c-tw-jethro/layers/openembedded-core/meta/recipes-graphics/libsdl/libsdl_1.2.15.bb
<http://libsdl_1.2.15.bb> DEPENDS on or otherwise requires it).
Close matches:


That's an awesome comment.  Clearly my testing wasn't optimal, there's 
another patch required.


Can you verify that 
cherry-picking 55ca1fb8f0e81ff739b3c46897e43356d1f760c3 solves this?


Yes, verified. Cherry-picking 55ca1fb8 solves the problem.

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

Re: [OE-core] [PATCH][jethro][RFC 1/2] libsdl: expand PACKAGECONFIG and enable native builds

[Trevor Woerner]

This patch causes my jethro build to now fail with:

ERROR: Nothing PROVIDES 'virtual/nativesdk-nativesdk-libx11' (but 
virtual:nativesdk:/z/dragon410c-repo/dragon410c-tw-jethro/layers/openembedded-core/meta/recipes-graphics/libsdl/libsdl_1.2.15.bb 
DEPENDS on or otherwise requires it). Close matches:

  virtual/nativesdk-libx11
  virtual/nativesdk-libc
  virtual/nativesdk-db



On 02/29/16 11:02, Ross Burton wrote:

Use PACKAGECONFIG instead of using logic in DEPENDS and EXTRA_OECONF, adding new
options for PulseAudio, tslib, DirectFB, OpenGL and X11.  Pass
--disable-x11-shared so that it links to the X libraries instead of using
dlopen().

Disable tslib by default as the kernel event input subsystem is generally used.

SDL's OpenGL support requires X11 so check for both x11 and opengl, and merge
the dependencies.

Finally enable native builds, with a minimal PACKAGECONFIG that will build from
oe-core for native and nativesdk.

(From OE-Core rev: 3d6c31c3a4ff34376e17005a981bb55fc6f7a38f)

Signed-off-by: Ross Burton 
Signed-off-by: Richard Purdie 
---
  meta/recipes-graphics/libsdl/libsdl_1.2.15.bb | 35 ++-
  1 file changed, 18 insertions(+), 17 deletions(-)

diff --git a/meta/recipes-graphics/libsdl/libsdl_1.2.15.bb 
b/meta/recipes-graphics/libsdl/libsdl_1.2.15.bb
index c0d5c6a..1cf3c39 100644
--- a/meta/recipes-graphics/libsdl/libsdl_1.2.15.bb
+++ b/meta/recipes-graphics/libsdl/libsdl_1.2.15.bb
@@ -12,13 +12,6 @@ LIC_FILES_CHKSUM = 
"file://COPYING;md5=27818cd7fd83877a8e3ef82b82798ef4"
  
  PROVIDES = "virtual/libsdl"
  
-DEPENDS = "${@bb.utils.contains('DISTRO_FEATURES', 'directfb', 'directfb', '', d)} \

-   ${@bb.utils.contains('DISTRO_FEATURES', 'opengl', 'virtual/libgl', 
'', d)} \
-   ${@bb.utils.contains('DISTRO_FEATURES', 'x11', 'virtual/libx11 
libxext libxrandr libxrender', '', d)} \
-   ${@bb.utils.contains('DISTRO_FEATURES', 'x11 opengl', 'libglu', '', 
d)} \
-   tslib"
-DEPENDS_class-nativesdk = "${@bb.utils.contains('DISTRO_FEATURES', 'x11', 
'virtual/nativesdk-libx11 nativesdk-libxrandr nativesdk-libxrender nativesdk-libxext', 
'', d)}"
-
  PR = "r3"
  
  SRC_URI = "http://www.libsdl.org/release/SDL-${PV}.tar.gz \

@@ -38,21 +31,29 @@ inherit autotools lib_package binconfig-disabled pkgconfig
  
  EXTRA_OECONF = "--disable-static --enable-cdrom --enable-threads --enable-timers \

  --enable-file --disable-oss --disable-esd --disable-arts \
---disable-diskaudio --disable-nas --disable-esd-shared 
--disable-esdtest \
+--disable-diskaudio --disable-nas \
  --disable-mintaudio --disable-nasm --disable-video-dga \
  --disable-video-fbcon --disable-video-ps2gs 
--disable-video-ps3 \
  --disable-xbios --disable-gem --disable-video-dummy \
---enable-input-events --enable-input-tslib --enable-pthreads \
-${@bb.utils.contains('DISTRO_FEATURES', 'directfb', 
'--enable-video-directfb', '--disable-video-directfb', d)} \
-${@bb.utils.contains('DISTRO_FEATURES', 'opengl', 
'--enable-video-opengl', '--disable-video-opengl', d)} \
-${@bb.utils.contains('DISTRO_FEATURES', 'x11', 
'--enable-video-x11', '--disable-video-x11', d)} \
+--enable-input-events --enable-pthreads \
  --disable-video-svga \
  --disable-video-picogui --disable-video-qtopia 
--enable-sdl-dlopen \
---disable-rpath \
---disable-pulseaudio"
+--disable-rpath"
+
+PACKAGECONFIG ??= "${@bb.utils.contains('DISTRO_FEATURES', 'alsa', 'alsa', '', 
d)} \
+   ${@bb.utils.contains('DISTRO_FEATURES', 'pulseaudio', 
'pulseaudio', '', d)} \
+   ${@bb.utils.contains('DISTRO_FEATURES', 'directfb', 
'directfb', '', d)} \
+   ${@bb.utils.contains('DISTRO_FEATURES', 'x11 opengl', 
'opengl', '', d)} \
+   ${@bb.utils.contains('DISTRO_FEATURES', 'x11', 'x11', '', 
d)}"
+PACKAGECONFIG_class-native = "x11"
+PACKAGECONFIG_class-nativesdk = "${@bb.utils.contains('DISTRO_FEATURES', 'x11', 
'x11', '', d)}"
  
-PACKAGECONFIG ??= "${@bb.utils.contains('DISTRO_FEATURES', 'alsa', 'alsa', '', d)}"

-PACKAGECONFIG[alsa] = "--enable-alsa 
--disable-alsatest,--disable-alsa,alsa-lib,"
+PACKAGECONFIG[alsa] = "--enable-alsa 
--disable-alsatest,--disable-alsa,alsa-lib"
+PACKAGECONFIG[pulseaudio] = 
"--enable-pulseaudio,--disable-pulseaudio,pulseaudio"
+PACKAGECONFIG[tslib] = "--enable-input-tslib, --disable-input-tslib, tslib"
+PACKAGECONFIG[directfb] = "--enable-video-directfb, --disable-video-directfb, 
directfb"
+PACKAGECONFIG[opengl] = "--enable-video-opengl, --disable-video-opengl, 
virtual/libgl libglu"
+PACKAGECONFIG[x11] = "--enable-video-x11 --disable-x11-shared, --disable-video-x11, 
virtual/libx11 libxext libxrandr libxrender"
  
  

Re: [OE-core] State of bitbake world, Failed tasks 2016-03-09

[Trevor Woerner]

On 03/10/16 06:53, Martin Jansa wrote:

I'll look at cef3 and chromium issue, my recent patch for meta-browser
fixed the build for armv7a MACHINEs, so it probably needs to be extended
a bit to cover warnings in x86 and then duplicate the same to cef3.
This issue is there for so long, slowing down the builds significantly
(and causing logs to be much bigger) - I don't use these recipes but I
hate the failures even more.


Working with the chromium recipe is painful! Each build takes _hours_, 
of just this one recipe alone, even on beefy build hardware. There are 
several PACKAGECONFIG options which affect the build (component build, 
lost context, side painting). There are multiple MACHINEs. You can 
perform a 'Release' or a 'Debug' build. Plus there are two rendering 
systems to support (x11 and wayland). Simply switching between x11 and 
wayland isn't just a matter of setting some build flags, you have to add 
another entire repository to your build from which you have to apply 
dozens of huge patches in order to add an Ozone layer underneath 
chromium so it can talk to wayland/weston.


The matrix of builds to perform and test explodes, not to mention the 
number of days it would take to build all these permutations.


I think one way to help contain this situation would be to split the 
chromium recipe into two: one for x11 and one for wayland. Another thing 
we should consider is wether or not all those permutations are really 
necessary. Is anyone actively using/needing Debug builds? Do we really 
need a component build?

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

[OE-core] [PATCH] tune-cortexa17.inc: apply changes similar to a15

[Trevor Woerner]

Apply the same sort of changes to the Cortex-A17 tune as were done in commit
35392025f3236f5e5393f9cf0857732da9a2e503.

Signed-off-by: Trevor Woerner <twoer...@gmail.com>
---
 meta/conf/machine/include/tune-cortexa17.inc | 52 ++--
 1 file changed, 26 insertions(+), 26 deletions(-)

diff --git a/meta/conf/machine/include/tune-cortexa17.inc 
b/meta/conf/machine/include/tune-cortexa17.inc
index ad92e0d..d08b002 100644
--- a/meta/conf/machine/include/tune-cortexa17.inc
+++ b/meta/conf/machine/include/tune-cortexa17.inc
@@ -1,6 +1,6 @@
-DEFAULTTUNE ?= "armv7a-neon"
+DEFAULTTUNE ?= "armv7ve-neon"
 
-require conf/machine/include/arm/arch-armv7a.inc
+require conf/machine/include/arm/arch-armv7ve.inc
 
 TUNEVALID[cortexa17] = "Enable Cortex-A17 specific processor optimizations"
 TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'cortexa17', ' 
-mcpu=cortex-a17', '', d)}"
@@ -13,18 +13,18 @@ ARMPKGARCH_tune-cortexa17-neon= "cortexa17"
 ARMPKGARCH_tune-cortexa17t-neon   = "cortexa17"
 ARMPKGARCH_tune-cortexa17-neon-vfpv4  = "cortexa17"
 ARMPKGARCH_tune-cortexa17t-neon-vfpv4 = "cortexa17"
-TUNE_FEATURES_tune-cortexa17 = "${TUNE_FEATURES_tune-armv7a}   
  cortexa17"
-TUNE_FEATURES_tune-cortexa17t= "${TUNE_FEATURES_tune-armv7at}  
  cortexa17"
-TUNE_FEATURES_tune-cortexa17-neon= "${TUNE_FEATURES_tune-armv7a-neon}  
  cortexa17"
-TUNE_FEATURES_tune-cortexa17t-neon   = "${TUNE_FEATURES_tune-armv7at-neon} 
  cortexa17"
-TUNE_FEATURES_tune-cortexa17-neon-vfpv4  = 
"${TUNE_FEATURES_tune-armv7a-neon-vfpv4}  cortexa17"
-TUNE_FEATURES_tune-cortexa17t-neon-vfpv4 = 
"${TUNE_FEATURES_tune-armv7at-neon-vfpv4} cortexa17"
-PACKAGE_EXTRA_ARCHS_tune-cortexa17 = 
"${PACKAGE_EXTRA_ARCHS_tune-armv7a}  cortexa17-vfp"
-PACKAGE_EXTRA_ARCHS_tune-cortexa17t= 
"${PACKAGE_EXTRA_ARCHS_tune-armv7at} cortexa17-vfp cortexa17t2-vfp"
-PACKAGE_EXTRA_ARCHS_tune-cortexa17-neon= 
"${PACKAGE_EXTRA_ARCHS_tune-armv7a-neon}  cortexa17-vfp cortexa17-neon"
-PACKAGE_EXTRA_ARCHS_tune-cortexa17t-neon   = 
"${PACKAGE_EXTRA_ARCHS_tune-armv7at-neon} cortexa17-vfp cortexa17-neon 
cortexa17t2-vfp cortexa17t2-neon"
-PACKAGE_EXTRA_ARCHS_tune-cortexa17-neon-vfpv4  = 
"${PACKAGE_EXTRA_ARCHS_tune-armv7a-neon-vfpv4}  cortexa17-vfp cortexa17-neon 
cortexa17-neon-vfpv4"
-PACKAGE_EXTRA_ARCHS_tune-cortexa17t-neon-vfpv4 = 
"${PACKAGE_EXTRA_ARCHS_tune-armv7at-neon-vfpv4} cortexa17-vfp cortexa17-neon 
cortexa17-neon-vfpv4 cortexa17t2-vfp cortexa17t2-neon cortexa17t2-neon-vfpv4"
+TUNE_FEATURES_tune-cortexa17 = "${TUNE_FEATURES_tune-armv7ve}  
   cortexa17"
+TUNE_FEATURES_tune-cortexa17t= "${TUNE_FEATURES_tune-armv7vet} 
   cortexa17"
+TUNE_FEATURES_tune-cortexa17-neon= "${TUNE_FEATURES_tune-armv7ve-neon} 
   cortexa17"
+TUNE_FEATURES_tune-cortexa17t-neon   = 
"${TUNE_FEATURES_tune-armv7vet-neon}   cortexa17"
+TUNE_FEATURES_tune-cortexa17-neon-vfpv4  = 
"${TUNE_FEATURES_tune-armv7ve-neon-vfpv4}  cortexa17"
+TUNE_FEATURES_tune-cortexa17t-neon-vfpv4 = 
"${TUNE_FEATURES_tune-armv7vet-neon-vfpv4} cortexa17"
+PACKAGE_EXTRA_ARCHS_tune-cortexa17 = 
"${PACKAGE_EXTRA_ARCHS_tune-armv7ve}  cortexa17-vfp"
+PACKAGE_EXTRA_ARCHS_tune-cortexa17t= 
"${PACKAGE_EXTRA_ARCHS_tune-armv7vet} cortexa17-vfp cortexa17t2-vfp"
+PACKAGE_EXTRA_ARCHS_tune-cortexa17-neon= 
"${PACKAGE_EXTRA_ARCHS_tune-armv7ve-neon}  cortexa17-vfp cortexa17-neon"
+PACKAGE_EXTRA_ARCHS_tune-cortexa17t-neon   = 
"${PACKAGE_EXTRA_ARCHS_tune-armv7vet-neon} cortexa17-vfp cortexa17-neon 
cortexa17t2-vfp cortexa17t2-neon"
+PACKAGE_EXTRA_ARCHS_tune-cortexa17-neon-vfpv4  = 
"${PACKAGE_EXTRA_ARCHS_tune-armv7ve-neon-vfpv4}  cortexa17-vfp cortexa17-neon 
cortexa17-neon-vfpv4"
+PACKAGE_EXTRA_ARCHS_tune-cortexa17t-neon-vfpv4 = 
"${PACKAGE_EXTRA_ARCHS_tune-armv7vet-neon-vfpv4} cortexa17-vfp cortexa17-neon 
cortexa17-neon-vfpv4 cortexa17t2-vfp cortexa17t2-neon cortexa17t2-neon-vfpv4"
 
 # HF Tunes
 AVAILTUNES += "cortexa17hf cortexa17thf cortexa17hf-neon cortexa17thf-neon 
cortexa17hf-neon-vfpv4 cortexa17thf-neon-vfpv4"
@@ -34,15 +34,15 @@ ARMPKGARCH_tune-cortexa17hf-neon= "cortexa17"
 ARMPKGARCH_tune-cortexa17thf-neon   = "cortexa17"
 ARMPKGARCH_tune-cortexa17hf-neon-vfpv4  = "cortexa17"
 ARMPKGARCH_tune-cortexa17thf-neon-vfpv4 = "cortexa17"
-TUNE_FEATURES_tune-cortexa17hf = "${TUNE_FEATURES_tune-armv7ahf}   
  cortexa17"
-TUNE_FEATURES_tune-cortexa17thf= "${TUNE_FEATURES_tune-armv7athf}  

[OE-core] [meta-oe][PATCH] tune-cortexa17.inc: apply changes similar to a15

[Trevor Woerner]

Apply the same sort of changes to the Cortex-A17 tune as were done in commit
35392025f3236f5e5393f9cf0857732da9a2e503.

Signed-off-by: Trevor Woerner <twoer...@gmail.com>
---
 meta/conf/machine/include/tune-cortexa17.inc | 52 ++--
 1 file changed, 26 insertions(+), 26 deletions(-)

diff --git a/meta/conf/machine/include/tune-cortexa17.inc 
b/meta/conf/machine/include/tune-cortexa17.inc
index ad92e0d..d08b002 100644
--- a/meta/conf/machine/include/tune-cortexa17.inc
+++ b/meta/conf/machine/include/tune-cortexa17.inc
@@ -1,6 +1,6 @@
-DEFAULTTUNE ?= "armv7a-neon"
+DEFAULTTUNE ?= "armv7ve-neon"
 
-require conf/machine/include/arm/arch-armv7a.inc
+require conf/machine/include/arm/arch-armv7ve.inc
 
 TUNEVALID[cortexa17] = "Enable Cortex-A17 specific processor optimizations"
 TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'cortexa17', ' 
-mcpu=cortex-a17', '', d)}"
@@ -13,18 +13,18 @@ ARMPKGARCH_tune-cortexa17-neon= "cortexa17"
 ARMPKGARCH_tune-cortexa17t-neon   = "cortexa17"
 ARMPKGARCH_tune-cortexa17-neon-vfpv4  = "cortexa17"
 ARMPKGARCH_tune-cortexa17t-neon-vfpv4 = "cortexa17"
-TUNE_FEATURES_tune-cortexa17 = "${TUNE_FEATURES_tune-armv7a}   
  cortexa17"
-TUNE_FEATURES_tune-cortexa17t= "${TUNE_FEATURES_tune-armv7at}  
  cortexa17"
-TUNE_FEATURES_tune-cortexa17-neon= "${TUNE_FEATURES_tune-armv7a-neon}  
  cortexa17"
-TUNE_FEATURES_tune-cortexa17t-neon   = "${TUNE_FEATURES_tune-armv7at-neon} 
  cortexa17"
-TUNE_FEATURES_tune-cortexa17-neon-vfpv4  = 
"${TUNE_FEATURES_tune-armv7a-neon-vfpv4}  cortexa17"
-TUNE_FEATURES_tune-cortexa17t-neon-vfpv4 = 
"${TUNE_FEATURES_tune-armv7at-neon-vfpv4} cortexa17"
-PACKAGE_EXTRA_ARCHS_tune-cortexa17 = 
"${PACKAGE_EXTRA_ARCHS_tune-armv7a}  cortexa17-vfp"
-PACKAGE_EXTRA_ARCHS_tune-cortexa17t= 
"${PACKAGE_EXTRA_ARCHS_tune-armv7at} cortexa17-vfp cortexa17t2-vfp"
-PACKAGE_EXTRA_ARCHS_tune-cortexa17-neon= 
"${PACKAGE_EXTRA_ARCHS_tune-armv7a-neon}  cortexa17-vfp cortexa17-neon"
-PACKAGE_EXTRA_ARCHS_tune-cortexa17t-neon   = 
"${PACKAGE_EXTRA_ARCHS_tune-armv7at-neon} cortexa17-vfp cortexa17-neon 
cortexa17t2-vfp cortexa17t2-neon"
-PACKAGE_EXTRA_ARCHS_tune-cortexa17-neon-vfpv4  = 
"${PACKAGE_EXTRA_ARCHS_tune-armv7a-neon-vfpv4}  cortexa17-vfp cortexa17-neon 
cortexa17-neon-vfpv4"
-PACKAGE_EXTRA_ARCHS_tune-cortexa17t-neon-vfpv4 = 
"${PACKAGE_EXTRA_ARCHS_tune-armv7at-neon-vfpv4} cortexa17-vfp cortexa17-neon 
cortexa17-neon-vfpv4 cortexa17t2-vfp cortexa17t2-neon cortexa17t2-neon-vfpv4"
+TUNE_FEATURES_tune-cortexa17 = "${TUNE_FEATURES_tune-armv7ve}  
   cortexa17"
+TUNE_FEATURES_tune-cortexa17t= "${TUNE_FEATURES_tune-armv7vet} 
   cortexa17"
+TUNE_FEATURES_tune-cortexa17-neon= "${TUNE_FEATURES_tune-armv7ve-neon} 
   cortexa17"
+TUNE_FEATURES_tune-cortexa17t-neon   = 
"${TUNE_FEATURES_tune-armv7vet-neon}   cortexa17"
+TUNE_FEATURES_tune-cortexa17-neon-vfpv4  = 
"${TUNE_FEATURES_tune-armv7ve-neon-vfpv4}  cortexa17"
+TUNE_FEATURES_tune-cortexa17t-neon-vfpv4 = 
"${TUNE_FEATURES_tune-armv7vet-neon-vfpv4} cortexa17"
+PACKAGE_EXTRA_ARCHS_tune-cortexa17 = 
"${PACKAGE_EXTRA_ARCHS_tune-armv7ve}  cortexa17-vfp"
+PACKAGE_EXTRA_ARCHS_tune-cortexa17t= 
"${PACKAGE_EXTRA_ARCHS_tune-armv7vet} cortexa17-vfp cortexa17t2-vfp"
+PACKAGE_EXTRA_ARCHS_tune-cortexa17-neon= 
"${PACKAGE_EXTRA_ARCHS_tune-armv7ve-neon}  cortexa17-vfp cortexa17-neon"
+PACKAGE_EXTRA_ARCHS_tune-cortexa17t-neon   = 
"${PACKAGE_EXTRA_ARCHS_tune-armv7vet-neon} cortexa17-vfp cortexa17-neon 
cortexa17t2-vfp cortexa17t2-neon"
+PACKAGE_EXTRA_ARCHS_tune-cortexa17-neon-vfpv4  = 
"${PACKAGE_EXTRA_ARCHS_tune-armv7ve-neon-vfpv4}  cortexa17-vfp cortexa17-neon 
cortexa17-neon-vfpv4"
+PACKAGE_EXTRA_ARCHS_tune-cortexa17t-neon-vfpv4 = 
"${PACKAGE_EXTRA_ARCHS_tune-armv7vet-neon-vfpv4} cortexa17-vfp cortexa17-neon 
cortexa17-neon-vfpv4 cortexa17t2-vfp cortexa17t2-neon cortexa17t2-neon-vfpv4"
 
 # HF Tunes
 AVAILTUNES += "cortexa17hf cortexa17thf cortexa17hf-neon cortexa17thf-neon 
cortexa17hf-neon-vfpv4 cortexa17thf-neon-vfpv4"
@@ -34,15 +34,15 @@ ARMPKGARCH_tune-cortexa17hf-neon= "cortexa17"
 ARMPKGARCH_tune-cortexa17thf-neon   = "cortexa17"
 ARMPKGARCH_tune-cortexa17hf-neon-vfpv4  = "cortexa17"
 ARMPKGARCH_tune-cortexa17thf-neon-vfpv4 = "cortexa17"
-TUNE_FEATURES_tune-cortexa17hf = "${TUNE_FEATURES_tune-armv7ahf}   
  cortexa17"
-TUNE_FEATURES_tune-cortexa17thf= "${TUNE_FEATURES_tune-armv7athf}  

Re: [OE-core] [PATCH] npm.bbclass: Add npm class to match fetcher

[Trevor Woerner]

On 02/28/16 18:13, Richard Purdie wrote:

On Sun, 2016-02-28 at 12:36 -0500, Trevor Woerner wrote:

Thanks!

I guess I don't have enough "plumbing" quite yet. I have all the
master branches of everything I need and I cherry picked Brendan's
npm.bbclass but I still get:
Ah sorry. I needed bitbake's master-next.

There was a patch missing, bitbake master should be good now.


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

Re: [OE-core] [PATCH] npm.bbclass: Add npm class to match fetcher

[Trevor Woerner]

On 02/28/16 12:09, Trevor Woerner wrote:

On 02/28/16 03:32, Richard Purdie wrote:

On Sat, 2016-02-27 at 19:53 -0500, Trevor Woerner wrote:

On 02/25/16 10:06, brendan.le.f...@intel.com wrote:

npm class supports the npm fetcher, helping doing the basic
compile/install
stages of an npm package

Any chance you might have an npm recipe example? Maybe something like
express?

Not express but there are some in:

https://github.com/arfoll/meta-brendan-nodepkgs/tree/master/recipes-node


Thanks!

I guess I don't have enough "plumbing" quite yet. I have all the 
master branches of everything I need and I cherry picked Brendan's 
npm.bbclass but I still get:


Ah sorry. I needed bitbake's master-next.
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] npm.bbclass: Add npm class to match fetcher

[Trevor Woerner]

On 02/28/16 03:32, Richard Purdie wrote:

On Sat, 2016-02-27 at 19:53 -0500, Trevor Woerner wrote:

On 02/25/16 10:06, brendan.le.f...@intel.com wrote:

npm class supports the npm fetcher, helping doing the basic
compile/install
stages of an npm package

Any chance you might have an npm recipe example? Maybe something like
express?

Not express but there are some in:

https://github.com/arfoll/meta-brendan-nodepkgs/tree/master/recipes-node


Thanks!

I guess I don't have enough "plumbing" quite yet. I have all the master 
branches of everything I need and I cherry picked Brendan's npm.bbclass 
but I still get:


$ bitbake forever

ERROR: ExpansionError during parsing 
/z/layerindex-master/layers/meta-brendan-nodepkgs/recipes-node/once/once_1.3.3.bb: 
Failure expanding variable do_fetch[file-checksums], expression was 
${@bb.fetch.get_checksum_file_list(d)} ${@get_lic_checksum_file_list(d)} 
which triggered exception NoMethodError: Could not find a fetcher which 
supports the URL: 'npm://registry.npmjs.org;name=once;version=1.3.3'


I'm not sure if this error is complaining about a fetcher issue (which I 
can't figure out because bitbake does have the commits with support for 
npm://) or a license/checksum error.

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

Re: [OE-core] [PATCH] npm.bbclass: Add npm class to match fetcher

[Trevor Woerner]

On 02/25/16 10:06, brendan.le.f...@intel.com wrote:

npm class supports the npm fetcher, helping doing the basic compile/install
stages of an npm package


Any chance you might have an npm recipe example? Maybe something like 
express?

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

Re: [OE-core] [PATCH 00/10] Integrate swupd software updater

[Trevor Woerner]

Ideally the work done here and the work done on meta-swupdate[1] would 
be somehow merged so people creating images/distros would only have to 
learn and integrate one software update solution, instead of having to 
evaluate and choose between the two (or more?).



[1] https://github.com/sbabic/meta-swupdate
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] oecommit ml

[Trevor Woerner]

It's great to see the OE Commit mailing list is being updated again, thanks! :-)
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] noticeably longer build (link?) times with binutils 2.26

[Trevor Woerner]

On 02/11/16 14:20, Martin Jansa wrote:

Did you add ld-is-gold to DISTRO_FEATURES?


Yes, it's the only way I know of to build an image with gold instead of 
bfd. And no other thing that gets built has any problems finding and 
running the linker.


I'll post my chromium recipe shortly, although it's not that much 
different from the upstream version 40 (other than having stripped out 
all the wayland-specific stuff).

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

Re: [OE-core] noticeably longer build (link?) times with binutils 2.26

[Trevor Woerner]

On 02/09/16 23:37, Khem Raj wrote:

IIRC gold has its own notions to enable gold
so you need to enable that


On Feb 9, 2016, at 8:18 PM, Trevor Woerner <twoer...@gmail.com> wrote:

I've tried every combination I can think of and no matter what I try, if gold 
is the linker the chromium build always errors out with:

collect2: fatal error: cannot find 'ld'


Building with gold does cut the build time of the chromium component 
back down.


binutils 2.25, bfd:  00:47:51, 00:44:24, 00:44:25
binutils 2.26, bfd:  02:07:45, 02:09:31, 02:02:42

binutils 2.26, gold: 00:43:49, 00:45:18, 00:42:51


But the only way I could get it to work was to manually perform the 
following steps:

$ cd /sysroots//usr/bin
$ ln -s /ld.gold ld.gold

where:
   = x86_64-linux
   = x86_64-poky-linux

to give:
$ cd /sysroots/x86_64-linux
$ ln -s x86_64-poky-linux/x86_64-poky-linux-ld.gold ld.gold

Maybe I can play with the recipe a bit more to get this to work 
"automatically"; maybe by setting the LD environment variable 
differently or something.


But, as I said before, the last time I tried booting a gold-linked image 
on the minnow grub2 refused to work :-(

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

Re: [OE-core] noticeably longer build (link?) times with binutils 2.26

[Trevor Woerner]

On 02/09/16 05:00, Burton, Ross wrote:


On 9 February 2016 at 02:56, Trevor Woerner <twoer...@gmail.com 
<mailto:twoer...@gmail.com>> wrote:


MACHINE  = "qemux86-64"

Essentially: minnowboard max (turbot, specifically)


As an aside, if you're actually building for the MinnowMax then the 
meta-intel BSP will be a lot better.




The images I build for my actual board do use the meta-intel BSP and set 
MACHINE to "intel-corei7-64".


This massive explosion in build time for chromium coincided with me 
adding a new disk to my build machine and moving my Jenkins builds over 
to the new disk. At first I assumed the problem might be related to the 
new disk so I was performing build speed tests on both the old and new 
disks. For this I setup 2 new builds (one on each disk) and set MACHINE 
to qemux86-64 by default and had forgot about it. But you bring up a 
good point, I should be using the same MACHINE (although my Jenkins 
instance is still using the correct MACHINE as is seeing the huge 
increase in build times too).

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

Re: [OE-core] noticeably longer build (link?) times with binutils 2.26

[Trevor Woerner]

I've tried every combination I can think of and no matter what I try, if 
gold is the linker the chromium build always errors out with:


collect2: fatal error: cannot find 'ld'
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] noticeably longer build (link?) times with binutils 2.26

[Trevor Woerner]

On 02/08/16 19:25, Mark Hatle wrote:

Which arch/tune are you targeting?


Build Configuration:
BB_VERSION= "1.28.0"
BUILD_SYS = "x86_64-linux"
NATIVELSBSTRING   = "openSUSE-project-13.2"
TARGET_SYS= "x86_64-poky-linux"
MACHINE   = "qemux86-64"
DISTRO= "poky"
DISTRO_VERSION= "2.0+snapshot-20160208"
TUNE_FEATURES = "m64 core2"
TARGET_FPU= ""


Essentially: minnowboard max (turbot, specifically)


It's possible you hit one of those cases, or it may simply be that much slower
for some reason.  But worse then double the time is really terrible.


Yes, I had started to assume Jenkins had gone "off the deep end" ;-)
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] noticeably longer build (link?) times with binutils 2.26

[Trevor Woerner]

On 02/08/16 21:25, Khem Raj wrote:

On Mon, Feb 8, 2016 at 3:20 PM, Trevor Woerner <twoer...@gmail.com> wrote:

This is more of a "FYI", but I've noticed that the build time of my chromium
recipe has gone from ~45 minutes to ~2h15m when the only thing that changes
is to move openembedded-core from the commit just before upgrading binutils
to version 2.26 ([fd75637] native.bbclass: Set CXXFLAGS from BUILD_CXXFLAGS
not BUILD_CFLAGS) to the one immediately after ([86ade2c] binutils: Upgrade
to 2.26).

Is it using gold linker ? if not can you try both bfd and gold


A week or so ago, as part of something else (but before the binutils 
update to 2.26), I tried performing a clean build using the gold linker. 
Unfortunately that image was not able to boot:


https://lists.yoctoproject.org/pipermail/meta-intel/2016-January/003697.html
(but there were no replies)

It dies somewhere between the EFI bootloader and grub2 (or perhaps just 
after grub starts). There's no grub output.


I'll try doing the build with the gold linker, but the results of that 
build might not be useful to me.

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

[OE-core] noticeably longer build (link?) times with binutils 2.26

[Trevor Woerner]

This is more of a "FYI", but I've noticed that the build time of my 
chromium recipe has gone from ~45 minutes to ~2h15m when the only thing 
that changes is to move openembedded-core from the commit just before 
upgrading binutils to version 2.26 ([fd75637] native.bbclass: Set 
CXXFLAGS from BUILD_CXXFLAGS not BUILD_CFLAGS) to the one immediately 
after ([86ade2c] binutils: Upgrade to 2.26).


Oddly enough I don't see this same behaviour when building, for example, 
core-image-minimal, so I have no idea what makes chromium so special 
and, therefore, whether other recipes might be similarly affected.


Also, it seems as though a lot of the added time is coming from the 
linking stage, but I don't have (or know how to get) hard numbers for 
that. Is there a way to get build times for each task within one recipe?


I've repeated this test 6 times (build just before binutils-2.26, build 
just after binutils-2.26) and the results are always within a couple 
minutes of each other. So I doubt this is some random occurrence.

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

Re: [OE-core] binutils upgrade to 2.26 failure - unsupported reloc 42 against global symbol __gmon_start__

[Trevor Woerner]

On 02/03/16 14:56, Khem Raj wrote:

On Feb 3, 2016, at 11:29 AM, Trevor Woerner <twoer...@gmail.com> wrote:

My chromium build is now failing due to:

commit 86ade2cc2553c942d9526c5323a11ae151653505
binutils: Upgrade to 2.26

| FAILED: x86_64-oe-linux-gcc  -m64 -march=corei7 -mtune=corei7 -mfpmath=sse 
-msse4.2 --sysroot=/z/chromium-49/build/tmp-glibc/sysroots/intel-corei7-64 
-Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed -Wl,-z,now -Wl,-z,relro 
-Wl,-z,defs -pthread -Wl,-z,noexecstack -fPIC 
-B/z/chromium-49/build/tmp-glibc/work/corei7-64-oe-linux/chromium/49.0.2612.0-r0/chromium-49.0.2612.0/third_party/binutils/Linux_x64/Release/bin
 -Wl,--disable-new-dtags -m64 -Wl,-O1 -Wl,--as-needed -Wl,--gc-sections -o 
chrome_sandbox -Wl,--start-group 
obj/sandbox/linux/suid/chrome_sandbox.process_util_linux.o 
obj/sandbox/linux/suid/chrome_sandbox.sandbox.o -Wl,--end-group
| 
/z/chromium-49/build/tmp-glibc/work/corei7-64-oe-linux/chromium/49.0.2612.0-r0/chromium-49.0.2612.0/third_party/binutils/Linux_x64/Release/bin/ld:
 error: 
/z/chromium-49/build/tmp-glibc/sysroots/intel-corei7-64/usr/lib/../lib/crti.o: 
unsupported reloc 42 against global symbol __gmon_start__
| ../sysdeps/x86_64/crti.S:66: error: unsupported reloc 42

Any suggestions on how to approach this?

do a clean build. Its mixing objects


Unfortunately this *is* with completely clean builds; I'm deleting 
everything except conf/ before each try. I just finished testing with 
ld-is-gold and it fails too in exactly the same way.


I'll make stuff available for you to test after I try a build with 
50.0.2636.0

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

Re: [OE-core] binutils upgrade to 2.26 failure - unsupported reloc 42 against global symbol __gmon_start__

[Trevor Woerner]

On 02/03/16 22:08, Khem Raj wrote:



On Feb 3, 2016, at 7:06 PM, Trevor Woerner <twoer...@gmail.com> wrote:

On 02/03/16 15:32, Martin Jansa wrote:

This could be caused by chromium using own bundled binutils where the version 
doesn't match, I've solved it in our recipe by:
+GYP_DEFINES_append = " linux_use_bundled_gold=0"
+GYP_DEFINES_append = " linux_use_bundled_binutils=0"


w00t!! awesome. works for me :-)

So it looks like we both have working chromium recipes, yet the upstream one 
doesn't work. What version are you building? For what arch (which archs)? 
x11/wayland?


please submit your patch for meta-browser


Any patch I submit is guaranteed to be rejected. It only supports x11 
and has only been tested on x86_64. If nothing else it would have to be 
named chromium-x11_.bb, or something like that. I've actually 
removed the wayland/ozone stuff from my recipe.


Considering each build of chromium takes me 2.5 hours (just for chromium 
alone!) it makes it hard to care about environments I'm not using.


The only way chromium builds for wayland is when another project (ozone) 
is added to the mix. But, in my tests so far, not every release of 
chromium builds successfully with every version of ozone. So although 
building for x11 is easy and works for just about each release, building 
for wayland is much more hit-and-miss (and has less chance of success).




I have a working recipe for 50.0.2636.0, but I'm only interested in x86_64 and 
x11. wayland+ozone is a whole other mess ;-)

At some point it'll probably be easier if we build chromium with llvm-clang, 
the same as google is doing. Is that possible?


you can try using meta-clang


Okay. So if I have an image and everything in that image is built with 
gcc except for chromium, meta-clang will know what it needs to add to 
the image so that one clang-built package can run?

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

Re: [OE-core] binutils upgrade to 2.26 failure - unsupported reloc 42 against global symbol __gmon_start__

[Trevor Woerner]

On 02/03/16 15:32, Martin Jansa wrote:
This could be caused by chromium using own bundled binutils where the 
version doesn't match, I've solved it in our recipe by:

+GYP_DEFINES_append = " linux_use_bundled_gold=0"
+GYP_DEFINES_append = " linux_use_bundled_binutils=0"


w00t!! awesome. works for me :-)

So it looks like we both have working chromium recipes, yet the upstream 
one doesn't work. What version are you building? For what arch (which 
archs)? x11/wayland?


I have a working recipe for 50.0.2636.0, but I'm only interested in 
x86_64 and x11. wayland+ozone is a whole other mess ;-)


At some point it'll probably be easier if we build chromium with 
llvm-clang, the same as google is doing. Is that possible?

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

[OE-core] binutils upgrade to 2.26 failure - unsupported reloc 42 against global symbol __gmon_start__

[Trevor Woerner]

My chromium build is now failing due to:

commit 86ade2cc2553c942d9526c5323a11ae151653505
binutils: Upgrade to 2.26

| FAILED: x86_64-oe-linux-gcc  -m64 -march=corei7 -mtune=corei7 
-mfpmath=sse -msse4.2 
--sysroot=/z/chromium-49/build/tmp-glibc/sysroots/intel-corei7-64 
-Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed -Wl,-z,now -Wl,-z,relro 
-Wl,-z,defs -pthread -Wl,-z,noexecstack -fPIC 
-B/z/chromium-49/build/tmp-glibc/work/corei7-64-oe-linux/chromium/49.0.2612.0-r0/chromium-49.0.2612.0/third_party/binutils/Linux_x64/Release/bin 
-Wl,--disable-new-dtags -m64 -Wl,-O1 -Wl,--as-needed -Wl,--gc-sections 
-o chrome_sandbox -Wl,--start-group 
obj/sandbox/linux/suid/chrome_sandbox.process_util_linux.o 
obj/sandbox/linux/suid/chrome_sandbox.sandbox.o -Wl,--end-group
| 
/z/chromium-49/build/tmp-glibc/work/corei7-64-oe-linux/chromium/49.0.2612.0-r0/chromium-49.0.2612.0/third_party/binutils/Linux_x64/Release/bin/ld: 
error: 
/z/chromium-49/build/tmp-glibc/sysroots/intel-corei7-64/usr/lib/../lib/crti.o: 
unsupported reloc 42 against global symbol __gmon_start__

| ../sysdeps/x86_64/crti.S:66: error: unsupported reloc 42

Any suggestions on how to approach this?
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 1/2] glibc-initial.inc: use relative path to run configure

[Trevor Woerner]

On 01/11/16 00:11, Robert Yang wrote:
> Avoid potential build path in output files.
>
> [YOCTO #8894]
>
> Signed-off-by: Robert Yang 
> ---
>  meta/recipes-core/glibc/glibc-initial.inc |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/meta/recipes-core/glibc/glibc-initial.inc 
> b/meta/recipes-core/glibc/glibc-initial.inc
> index 8e81f09..cb2f8dd 100644
> --- a/meta/recipes-core/glibc/glibc-initial.inc
> +++ b/meta/recipes-core/glibc/glibc-initial.inc
> @@ -11,7 +11,7 @@ TOOLCHAIN_OPTIONS = " --sysroot=${STAGING_DIR_TCBOOTSTRAP}"
>  do_configure () {
>   (cd ${S} && gnu-configize) || die "failure in running gnu-configize"
>   find ${S} -name "configure" | xargs touch
> - ${S}/configure --host=${TARGET_SYS} --build=${BUILD_SYS} \
> + ../git/configure --host=${TARGET_SYS} --build=${BUILD_SYS} \

Although I haven't tested it, this _looks_ like it might fail quite
readily. I'm sure there are some recipes that play tricks with ${S}, and
what about recipes that don't pull their sources from git?

Maybe something like: (cd ${S} && ./configure ...) would be better?

>   --prefix=/usr \
>   --without-cvs --disable-sanity-checks \
>   --with-headers=${STAGING_DIR_TARGET}${includedir} \

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

Re: [OE-core] [PATCH 00/63] Consolidated pull

[Trevor Woerner]

On 01/07/16 11:06, Martin Jansa wrote:
> On Thu, Jan 07, 2016 at 11:00:31AM -0500, Trevor Woerner wrote:
>> With this applied bitbake can't parse meta-openembedded because
>>
>> meta-openembedded/meta-oe/recipes-devtools/python/python-pyqt_4.11.3.bb:25:
>> Could not inherit file classes/qmake2.bbclass
>>
>> unless the user adds git://git.yoctoproject.org/meta-qt4 to their layers.
>>
>> Should this recipe be also moved to meta-qt4?
> See openembedded-devel changes I've just sent or master-next.
>

Ok, thanks. I was in the process of making a list :-)
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] sstate: change "stamp is not reachable, removing manifests" message from info to debug

[Trevor Woerner]

On 01/05/16 07:32, Ross Burton wrote:
> This code path has proven to work, so change the log level from info to debug 
> so
> it doesn't spam the log in normal use.

I liked having this as part of the regular processing. If I only update
my upstream repositories once a week (for example) my next "bitbake ..."
would show which packages had upgrades. It was a cheap way of doing an
image diff, if you will.

In order to keep those messages now I would have to enable debug, which
will generate quite a lot more information.

Yes, I know I could get the "image diff" functionality by enabling
buildhistory and going that route, but as I said above this was sort of
a "cheap" image diff for free ;-)
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [meta-oe][PATCH] mkefidisk.sh: add boot log on console

[Trevor Woerner]

On 01/04/16 11:20, Burton, Ross wrote:
>
> On 31 December 2015 at 22:07, Trevor Woerner <twoer...@gmail.com
> <mailto:twoer...@gmail.com>> wrote:
>
> ping?
>
>
> Sorry, slipped through.  These are staged in ross/mut as of now.

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

Re: [OE-core] State of bitbake world, Failed tasks 2016-01-01

[Trevor Woerner]

On 01/02/16 13:19, Martin Jansa wrote:
>
> == Tested changes (not included in master yet) - meta-openembedded ==
...
> 7020a19 nodejs: cleanup and update
...
>
> == Failed tasks 2016-01-01 ==
...
>
> === qemuarm (1) ===
> * /meta-openembedded/meta-oe/recipes-devtools/nodejs/nodejs_4.2.2.bb 
> , do_compile
>

Can it really be considered a failed build when the recipe explicitly
excludes qemuarm (armv5) from the compatible machine list?
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [meta-oe][PATCH] mkefidisk.sh: add boot log on console

[Trevor Woerner]

ping?

On 11/28/15 09:29, Trevor Woerner wrote:
> Hooking up a serial console is a "developer mode", the chances are pretty good
> developers are interested in watching the kernel boot log on the console so
> they can spot any problems or diagnose any failed boots (e.g. can't find root
> fs).
>
> Signed-off-by: Trevor Woerner <twoer...@gmail.com>
> ---
>  scripts/contrib/mkefidisk.sh | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/scripts/contrib/mkefidisk.sh b/scripts/contrib/mkefidisk.sh
> index cd4de05..23c18cb 100755
> --- a/scripts/contrib/mkefidisk.sh
> +++ b/scripts/contrib/mkefidisk.sh
> @@ -402,7 +402,7 @@ if [ -e "$GRUB_CFG" ]; then
>   sed -i "s/ LABEL=[^ ]*/ /" $GRUB_CFG
>  
>   sed -i "s@ root=[^ ]*@ @" $GRUB_CFG
> - sed -i "s@vmlinuz @vmlinuz root=$TARGET_ROOTFS ro rootwait quiet @" 
> $GRUB_CFG
> + sed -i "s@vmlinuz @vmlinuz root=$TARGET_ROOTFS ro rootwait 
> console=ttyS0 console=tty0 @" $GRUB_CFG
>  fi
>  
>  # Look for a gummiboot installation
> @@ -419,7 +419,7 @@ if [ -d "$GUMMI_ENTRIES" ]; then
>  
>   sed -i "/initrd /d" $GUMMI_CFG
>   sed -i "s@ root=[^ ]*@ @" $GUMMI_CFG
> - sed -i "s@options *LABEL=boot @options LABEL=Boot root=$TARGET_ROOTFS 
> ro rootwait quiet @" $GUMMI_CFG
> + sed -i "s@options *LABEL=boot @options LABEL=Boot root=$TARGET_ROOTFS 
> ro rootwait console=ttyS0 console=tty0 @" $GUMMI_CFG
>  fi
>  
>  # Ensure we have at least one EFI bootloader configured

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

Re: [OE-core] [PATCH] mkefidisk.sh: add startup script for automated boot

[Trevor Woerner]

ping?

On 11/28/15 09:43, Trevor Woerner wrote:
> Regardless of which image is built using which layers, try to ensure the image
> on the SD device being prepared is the one that is booted automatically when
> the board is powered.
>
> Signed-off-by: Trevor Woerner <twoer...@gmail.com>
> ---
>  scripts/contrib/mkefidisk.sh | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/scripts/contrib/mkefidisk.sh b/scripts/contrib/mkefidisk.sh
> index 23c18cb..333284f 100755
> --- a/scripts/contrib/mkefidisk.sh
> +++ b/scripts/contrib/mkefidisk.sh
> @@ -438,6 +438,9 @@ if [ -d $ROOTFS_MNT/etc/udev/ ] ; then
>   echo "$TARGET_DEVICE" >> $ROOTFS_MNT/etc/udev/mount.blacklist
>  fi
>  
> +# Add startup.nsh script for automated boot
> +echo "fs0:\EFI\BOOT\bootx64.efi" > $BOOTFS_MNT/startup.nsh
> +
>  
>  # Call cleanup to unmount devices and images and remove the TMPDIR
>  cleanup

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

Re: [OE-core] [meta-oe][PATCH v3 1/1] nodejs: cleanup and update

[Trevor Woerner]

Oops, sent to wrong list. resending...
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [meta-oe][PATCH v3 1/1] nodejs: cleanup and update

[Trevor Woerner]

Remove old nodejs_0.4.12 and update nodejs_0.12.7 to the latest stable
nodejs_4.2.3.

Nodejs is picky about which architectures it supports. The supported arch
mapping required some updating to bring it up to date with the current nodejs
code. Add COMPATIBLE_MACHINE entries so it only builds for the supported
architectures.

It appears the nodejs project removed support for ARMv5 somewhere around V8
3.22 or 3.23. Also, gcc 5 no longer supports -mfpu=vfpv2 (which is what the
nodejs build thinks it should be using for ARMv5).
See https://github.com/nodejs/node/issues/3061

Signed-off-by: Trevor Woerner <twoer...@gmail.com>
---
 .../nodejs/nodejs/enable-armv5e-build.patch| 22 --
 .../nodejs/nodejs4/libev-cross-cc_0.4.12.patch | 13 --
 meta-oe/recipes-devtools/nodejs/nodejs4_0.4.12.bb  | 49 --
 .../nodejs/{nodejs_0.12.7.bb => nodejs_4.2.3.bb}   | 23 ++
 4 files changed, 16 insertions(+), 91 deletions(-)
 delete mode 100644 
meta-oe/recipes-devtools/nodejs/nodejs/enable-armv5e-build.patch
 delete mode 100644 
meta-oe/recipes-devtools/nodejs/nodejs4/libev-cross-cc_0.4.12.patch
 delete mode 100644 meta-oe/recipes-devtools/nodejs/nodejs4_0.4.12.bb
 rename meta-oe/recipes-devtools/nodejs/{nodejs_0.12.7.bb => nodejs_4.2.3.bb} 
(81%)

diff --git a/meta-oe/recipes-devtools/nodejs/nodejs/enable-armv5e-build.patch 
b/meta-oe/recipes-devtools/nodejs/nodejs/enable-armv5e-build.patch
deleted file mode 100644
index cc7c9ab..000
--- a/meta-oe/recipes-devtools/nodejs/nodejs/enable-armv5e-build.patch
+++ /dev/null
@@ -1,22 +0,0 @@
-Building for qemuarm without thumb enabled is using -march=armv5e which isn't
-recognized here. Fix it by adding __ARM_ARCH_5E__.
-
-v0.12.2 branch of node doesn't seem to be affected, because it's using
-different version of v8
-
-Upstream-Status: Pending
-
-Signed-off-by: Martin Jansa <martin.ja...@gmail.com>
-
-diff -uNr node-v0.12.2/deps/v8/src/base/atomicops_internals_arm_gcc.h 
node-v0.12.2-fix/deps/v8/src/base/atomicops_internals_arm_gcc.h
 node-v0.12.2/deps/v8/src/base/atomicops_internals_arm_gcc.h
2015-04-01 00:13:01.0 +0200
-+++ node-v0.12.2-fix/deps/v8/src/base/atomicops_internals_arm_gcc.h
2015-04-28 14:30:43.119509207 +0200
-@@ -156,7 +156,7 @@
- 
- // This tests against any known ARMv5 variant.
- #elif defined(__ARM_ARCH_5__) || defined(__ARM_ARCH_5T__) || \
--  defined(__ARM_ARCH_5TE__) || defined(__ARM_ARCH_5TEJ__)
-+  defined(__ARM_ARCH_5E__) || defined(__ARM_ARCH_5TE__) || 
defined(__ARM_ARCH_5TEJ__)
- 
- // The kernel also provides a helper function to perform an atomic
- // compare-and-swap operation at the hard-wired address 0x0fc0.
diff --git 
a/meta-oe/recipes-devtools/nodejs/nodejs4/libev-cross-cc_0.4.12.patch 
b/meta-oe/recipes-devtools/nodejs/nodejs4/libev-cross-cc_0.4.12.patch
deleted file mode 100644
index 2b9838f..000
--- a/meta-oe/recipes-devtools/nodejs/nodejs4/libev-cross-cc_0.4.12.patch
+++ /dev/null
@@ -1,13 +0,0 @@
-diff --git a/deps/libev/wscript b/deps/libev/wscript
-index 4f6c9a8..1796749 100644
 a/deps/libev/wscript
-+++ b/deps/libev/wscript
-@@ -58,7 +58,7 @@ def configure(conf):
-   return 0;
-   }
-   """
--  conf.check_cc(fragment=code, define_name="HAVE_CLOCK_SYSCALL", execute=True,
-+  conf.check_cc(fragment=code, define_name="HAVE_CLOCK_SYSCALL", 
execute=False,
- msg="Checking for SYS_clock_gettime")
- 
-   have_librt = conf.check(lib='rt', uselib_store='RT')
diff --git a/meta-oe/recipes-devtools/nodejs/nodejs4_0.4.12.bb 
b/meta-oe/recipes-devtools/nodejs/nodejs4_0.4.12.bb
deleted file mode 100644
index c73cefc..000
--- a/meta-oe/recipes-devtools/nodejs/nodejs4_0.4.12.bb
+++ /dev/null
@@ -1,49 +0,0 @@
-SUMMARY = "nodeJS Evented I/O for V8 JavaScript"
-HOMEPAGE = "http://nodejs.org;
-LICENSE = "MIT & Zlib"
-LIC_FILES_CHKSUM = "file://LICENSE;md5=d6237f3a840aef5b7880fb4e49eecfe5"
-
-DEPENDS = "openssl"
-
-PNBLACKLIST[nodejs4] ?= "Used only by currently blacklisted cloud9 and fails 
to build for qemuarm with thumb: error: #error For thumb inter-working we 
require an architecture which supports blx"
-
-SRC_URI = " \
-http://nodejs.org/dist/node-v${PV}.tar.gz \
-file://libev-cross-cc_${PV}.patch \
-"
-SRC_URI[md5sum] = "a6375eaa43db5356bf443e25b828ae16"
-SRC_URI[sha256sum] = 
"c01af05b933ad4d2ca39f63cac057f54f032a4d83cff8711e42650ccee24fce4"
-
-S = "${WORKDIR}/node-v${PV}"
-
-# v8 errors out if you have set CCACHE
-CCACHE = ""
-
-do_configure () {
-sed -i -e 's:/usr/lib:${STAGING_LIBDIR}:g' wscript
-sed -i -e 's:/usr/local/lib:${STAGING_LIBDIR}:g' wscript
-./configure --prefix=${prefix} --without-snapshot
-}
-
-do_compile () {
-make
-}
-
-do_install () {
-oe_runmake install DESTDIR=${D}
-
-# fix namespace conflicts with 

[OE-core] [meta-oe][PATCH v3 0/1] nodejs cleanup and update

[Trevor Woerner]

My third attempt to update and cleanup the nodejs recipes.

This patch removes the older nodejs recipes and replaces them with a recipe
for nodejs 4.2.3 (the latest stable at this time).

Nodejs is picky about which architectures it supports. Add COMPATIBLE_MACHINE
and cleanup the architecture mapping function to reflect what is currently
supported. Nodejs dropped support for ARMv5 around V8 version 3.22. Also, gcc
no longer supports -mfpu=vfpv2 (which is what the nodejs build thinks it
should be using).

Successfully built for:
  qemuarm, qemuarm64, qemumips, qemumips64, qemuppc, qemuppc64, qemux86,
  qemux86-64, beaglebone, intel-corei7-64, genericx86, genericx86-64

Successfully ran on:
  qemuarm64, qemumips, qemux86, qemux86-64, intel-corei7-64 (turbot)

Failed to run for:
  qemuppc:
unhandled signal 4 at 2ee3bf48 nip 2ee3bf48 lr 2ee3ed70 code 30001
Illegal instruction
  qemuppc64:
I wasn't able to successfully run a qemuppc64 VM

Changes from v2:
  handle qemuarm build failure

Changes from v1:
  don't try to keep and unite the old recipe versions, just replace them with
  the latest stable

Trevor Woerner (1):
  nodejs: cleanup and update

 .../nodejs/nodejs/enable-armv5e-build.patch| 22 --
 .../nodejs/nodejs4/libev-cross-cc_0.4.12.patch | 13 --
 meta-oe/recipes-devtools/nodejs/nodejs4_0.4.12.bb  | 49 --
 .../nodejs/{nodejs_0.12.7.bb => nodejs_4.2.3.bb}   | 23 ++
 4 files changed, 16 insertions(+), 91 deletions(-)
 delete mode 100644 
meta-oe/recipes-devtools/nodejs/nodejs/enable-armv5e-build.patch
 delete mode 100644 
meta-oe/recipes-devtools/nodejs/nodejs4/libev-cross-cc_0.4.12.patch
 delete mode 100644 meta-oe/recipes-devtools/nodejs/nodejs4_0.4.12.bb
 rename meta-oe/recipes-devtools/nodejs/{nodejs_0.12.7.bb => nodejs_4.2.3.bb} 
(81%)

-- 
2.6.0.rc3

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

[OE-core] qemuarm update

[Trevor Woerner]

Would it make sense, would it be possible, for the qemuarm machine to
emulate ARMv7a instead of ARMv5?
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] State of bitbake world, Failed tasks 2015-12-17

[Trevor Woerner]

On 12/18/15 06:25, Martin Jansa wrote:
> === qemuarm (1) ===
> * /meta-openembedded/meta-oe/recipes-devtools/nodejs/nodejs_4.2.2.bb, 
> do_compile

I'm having a look at this one.
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] Patchwork & patch handling improvements

[Trevor Woerner]

On 11/26/15 16:00, Paul Eggleton wrote:
> I'm also 
> trying to ensure that the patch validation is generic enough so it can live 
> in 
> OE-Core, and thus we can easily update and refine it over time in line with 
> the 
> code itself as well as encourage submitters to use the script on their own 
> changes before sending.

This all sounds like an improvement and is therefore a step in the right
direction :-)

A while back I had the idea of "porting" the kernel's "checkpatch.pl" to
The Yocto Project (it was around the same time that I was trying to
float the whole "Maintainers File" idea too, since I was also trying to
re-purpose "get-maintainer.pl" as well). About one minute into that
effort I realized the existing *.bb files were all over the place in
terms of the order of statements and the order of the blocks of
statements. At that time I found one recipe style guide from OE, and
another one from The Yocto Project, each of which described a slightly
different preference. So I asked on the mailing list and quickly
discovered that both groups prefer a different style.

I'm not saying this job isn't worth doing, but I am pointing out there's
the potential for feathers to be ruffled on both sides if someone tries
to produce a definitive style guide for recipe files and then enforces
it in an automated way. Since it is the OpenEmbedded Project's job to
provide the recipes for The Yocto Project, I'm guessing this question
needs to be decided by them? If that sounds reasonable, then maybe The
Yocto Project needs to acquiesce to OE's decision?

Instead of cross-posting, maybe this would be a good email for the new
architecture list (CC'ed)?
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [meta-oe][PATCH] mkefidisk.sh: add boot log on console

[Trevor Woerner]

Hooking up a serial console is a "developer mode", the chances are pretty good
developers are interested in watching the kernel boot log on the console so
they can spot any problems or diagnose any failed boots (e.g. can't find root
fs).

Signed-off-by: Trevor Woerner <twoer...@gmail.com>
---
 scripts/contrib/mkefidisk.sh | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/scripts/contrib/mkefidisk.sh b/scripts/contrib/mkefidisk.sh
index cd4de05..23c18cb 100755
--- a/scripts/contrib/mkefidisk.sh
+++ b/scripts/contrib/mkefidisk.sh
@@ -402,7 +402,7 @@ if [ -e "$GRUB_CFG" ]; then
sed -i "s/ LABEL=[^ ]*/ /" $GRUB_CFG
 
sed -i "s@ root=[^ ]*@ @" $GRUB_CFG
-   sed -i "s@vmlinuz @vmlinuz root=$TARGET_ROOTFS ro rootwait quiet @" 
$GRUB_CFG
+   sed -i "s@vmlinuz @vmlinuz root=$TARGET_ROOTFS ro rootwait 
console=ttyS0 console=tty0 @" $GRUB_CFG
 fi
 
 # Look for a gummiboot installation
@@ -419,7 +419,7 @@ if [ -d "$GUMMI_ENTRIES" ]; then
 
sed -i "/initrd /d" $GUMMI_CFG
sed -i "s@ root=[^ ]*@ @" $GUMMI_CFG
-   sed -i "s@options *LABEL=boot @options LABEL=Boot root=$TARGET_ROOTFS 
ro rootwait quiet @" $GUMMI_CFG
+   sed -i "s@options *LABEL=boot @options LABEL=Boot root=$TARGET_ROOTFS 
ro rootwait console=ttyS0 console=tty0 @" $GUMMI_CFG
 fi
 
 # Ensure we have at least one EFI bootloader configured
-- 
2.6.3.368.gf34be46

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

[OE-core] [PATCH] mkefidisk.sh: add startup script for automated boot

[Trevor Woerner]

Regardless of which image is built using which layers, try to ensure the image
on the SD device being prepared is the one that is booted automatically when
the board is powered.

Signed-off-by: Trevor Woerner <twoer...@gmail.com>
---
 scripts/contrib/mkefidisk.sh | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/scripts/contrib/mkefidisk.sh b/scripts/contrib/mkefidisk.sh
index 23c18cb..333284f 100755
--- a/scripts/contrib/mkefidisk.sh
+++ b/scripts/contrib/mkefidisk.sh
@@ -438,6 +438,9 @@ if [ -d $ROOTFS_MNT/etc/udev/ ] ; then
echo "$TARGET_DEVICE" >> $ROOTFS_MNT/etc/udev/mount.blacklist
 fi
 
+# Add startup.nsh script for automated boot
+echo "fs0:\EFI\BOOT\bootx64.efi" > $BOOTFS_MNT/startup.nsh
+
 
 # Call cleanup to unmount devices and images and remove the TMPDIR
 cleanup
-- 
2.6.3.368.gf34be46

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

[OE-core] oecommit ml

[Trevor Woerner]

It seems I missed some announcement. At first I thought I had been
unsubscribed from the openembedded-commits mailing list (since I haven't
received any emails on that list since about the end of September). So I
looked up http://lists.openembedded.org/pipermail/openembedded-commits/
and it seems to have gone quiet about that time too.

I liked being able to watch the commits to see what was going in, and to
check if my patches were added (before sending "ping"s, without having
to "git pull" and search). Is there a new workflow for seeing what's
going in?
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] How to handle mesa customization in BSP layers

[Trevor Woerner]

On 10/20/15 05:37, Koen Kooi wrote:
>> Op 20 okt. 2015, om 11:32 heeft Nicolas Dechesne 
>>  het volgende geschreven:
>>
>>
>> The issue is that mesa is arch specific, not machine specific. So if
>> you start mixing machines from the same arch, we are getting
>> unexpected/wrong rebuilds.
> In this specific case I think we should enable freedreno for armv7/armv8 in 
> OE-core, but the problem remains for other recipes like this.

Are you suggesting that every armv7 device should have their mesa tuned
for freedreno and freedreno added to their filesystem? That seems quite
overly-broad!

On the surface[1] it would seem as though the decisions as to how one
builds mesa and which graphics solution to install is more similar to
the decision as to which DEFAULTTUNE to use, rather than which
architecture is involved?







[1] which is my way of saying "I don't have the experience of actually
having done this, unlike you people" ;-)
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] libksba: fix pkgconfig patch

[Trevor Woerner]

Add '$' to fix a patch which adds pkgconfig support to libksba.

Signed-off-by: Trevor Woerner <twoer...@gmail.com>
---
 meta/recipes-support/libksba/libksba/ksba-add-pkgconfig-support.patch | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git 
a/meta/recipes-support/libksba/libksba/ksba-add-pkgconfig-support.patch 
b/meta/recipes-support/libksba/libksba/ksba-add-pkgconfig-support.patch
index b5886c5..d28dfd9 100644
--- a/meta/recipes-support/libksba/libksba/ksba-add-pkgconfig-support.patch
+++ b/meta/recipes-support/libksba/libksba/ksba-add-pkgconfig-support.patch
@@ -51,7 +51,7 @@ Index: libksba-1.3.0/ksba.pc.in
 +Requires:
 +Version: @VERSION@
 +Libs: -L${libdir} -lksba
-+Libs.private: -L{libdir} -lgpg-error
++Libs.private: -L${libdir} -lgpg-error
 +Cflags: -I${includedir}
 +
 Index: libksba-1.3.0/src/ksba.m4
-- 
2.5.0.234.gefc8a62

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

[OE-core] packageconfig for non-autotooled project

[Trevor Woerner]

Hello,

libepoxy needs its EGL support to have a packageconfig (*.pc) file but
the EGL I want to use in my project
(meta-sunxi/recipes-graphics/libgles/sunxi-mali_git.bb, which points to
gitsm://github.com/linux-sunxi/sunxi-mali.git) isn't autotooled. There
are a couple ways around this problem, but if there is an example of
generating a .pc file for a non-autotooled project already, I'd be
grateful if someone could point me to it :-)

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

Re: [OE-core] packageconfig for non-autotooled project

[Trevor Woerner]

Hey Khem,

On 09/21/15 13:03, Khem Raj wrote:
>
> Look at the patches I have posted for raspberry pi layer
>

Found them. Awesome, thanks! :-)
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 02/16] slang: Fix namespace conflict vis-a-vis posix_close

[Trevor Woerner]

On 09/10/15 07:21, Alexander Kanavin wrote:
> On 09/09/2015 07:02 PM, Khem Raj wrote:
>
>> So I encourage you to formulate a policy and make a proposal to
>> community and get everyone on board in changing
>> the policy OE wide.
>
>
> Actually, first we need some kind of tool that keeps track of custom
> patches and their upstream-statuses and minimizes the amount of manual
> work.
>
> Then we can formulate a policy on top of that: for example, if a patch
> has been 'Pending' for 3 months, the person who added it gets a
> reminder to update the status; if the patch has been 'Pending' for 6
> months and the patch person has been unresponsive, no more patches are
> accepted from that person until he does the upstreaming of the ones he
> already got into oe-core. Something like that.

With so many maintainers on so many different layers/etc we would need
some sort of billboard somewhere listing the names of people currently
on the "naughty" list ;-)
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core