[OE-core] npm thoughts

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

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

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 wr

Re: [OE-core] OEDAM - Portland 2017

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"

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

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

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.

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

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

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

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

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

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

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

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 v

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

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

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

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.

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

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

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

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 r

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

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

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

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?

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

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:

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

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 cycl

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

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! --

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

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

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

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.

Re: [OE-core] State of bitbake world 2016-08-24

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:

Re: [OE-core] State of bitbake world 2016-08-24

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

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

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

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

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

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

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

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

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 f

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

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/gst

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

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 > >

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

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

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

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,

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

: > 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

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

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

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

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

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:

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

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

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

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.gi

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

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

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

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

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:

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

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

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

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 > >

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

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.

Re: [OE-core] Yocto Project Status WW17

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"? > > > e

Re: [OE-core] Yocto Project Status WW17

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

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

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

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

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

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

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,

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

(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

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

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

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

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/c

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

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:

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

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-openembe

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

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

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

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

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

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. Ha

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

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 PROVI

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

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

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

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-j

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

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

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

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

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

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(

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

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(

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

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

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

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

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

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

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

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? -- ___

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

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]

Re: [OE-core] oecommit ml

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

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

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

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

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

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 buil

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

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

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

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=

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

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 o

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

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

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

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

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

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_

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

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

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

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

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

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

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

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

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

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

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

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

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

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 >

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

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. c

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

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 <

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

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

-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

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

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

[OE-core] qemuarm update

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

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

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

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

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

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

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

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 chan

[OE-core] oecommit ml

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

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

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 >>

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

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/l

[OE-core] packageconfig for non-autotooled project

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,

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

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

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

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

<    1   2   3   4   5   >