On Wed, Jan 22, 2020 at 12:28:02PM -0800, Khem Raj wrote:
> On Tue, Jan 21, 2020 at 8:32 AM Adrian Bunk wrote:
> >
> > On Thu, Jan 16, 2020 at 07:17:20AM -0800, Khem Raj wrote:
> > > On Thu, Jan 16, 2020 at 5:13 AM Adrian Bunk wrote:
> > > >
> > > > On Wed, Jan 15, 2020 at 08:46:09PM -0800, Khem
On Wed, Jan 15, 2020 at 1:46 PM Bruce Ashfield wrote:
>
> On Wed, Jan 15, 2020 at 1:36 PM Bruce Ashfield
> wrote:
> >
> > I already have an entire queue in development for this.
> >
> > So hold onto this series. I'll publish my branch later this week, or early
> > next.
>
> Actually, I'll see
On Fri, Jan 24, 2020 at 5:46 PM Denys Dmytriyenko wrote:
>
> On Fri, Jan 24, 2020 at 05:30:04PM -0500, Jon Mason wrote:
> > On Thu, Jan 23, 2020 at 5:16 PM Denys Dmytriyenko wrote:
> > >
> > > On Thu, Jan 23, 2020 at 04:10:33PM -0600, Joshua Watt wrote:
> > > >
> > > > On 1/23/20 4:05 PM, Denys
On Fri, Jan 24, 2020 at 09:05:09AM -0800, Khem Raj wrote:
> On 1/24/20 3:42 AM, Ross Burton wrote:
> >On 23/01/2020 22:43, Denys Dmytriyenko wrote:
> >>>Such as all the various cortex etc CPU tuning files?
> >>
> >>LOL! :) Of course, since ARM is such an inferior arch to x86.
> >>Otherwise we
>
On Fri, Jan 24, 2020 at 12:05 PM Khem Raj wrote:
>
> On 1/24/20 3:42 AM, Ross Burton wrote:
> > On 23/01/2020 22:43, Denys Dmytriyenko wrote:
> >>> Such as all the various cortex etc CPU tuning files?
> >>
> >> LOL! :) Of course, since ARM is such an inferior arch to x86.
> >> Otherwise we
> >>
On Fri, Jan 24, 2020 at 05:30:04PM -0500, Jon Mason wrote:
> On Thu, Jan 23, 2020 at 5:16 PM Denys Dmytriyenko wrote:
> >
> > On Thu, Jan 23, 2020 at 04:10:33PM -0600, Joshua Watt wrote:
> > >
> > > On 1/23/20 4:05 PM, Denys Dmytriyenko wrote:
> > > >On Thu, Jan 23, 2020 at 04:43:23PM -0500,
On Thu, Jan 23, 2020 at 5:50 PM Richard Purdie
wrote:
>
> On Thu, 2020-01-23 at 22:17 +, Ross Burton wrote:
> > On 23/01/2020 21:43, Bruce Ashfield wrote:
> > > On Thu, Jan 23, 2020 at 4:00 PM Denys Dmytriyenko
> > > wrote:
> > > > From: Denys Dmytriyenko
> > > >
> > > > Many BSPs require
On Thu, Jan 23, 2020 at 5:16 PM Denys Dmytriyenko wrote:
>
> On Thu, Jan 23, 2020 at 04:10:33PM -0600, Joshua Watt wrote:
> >
> > On 1/23/20 4:05 PM, Denys Dmytriyenko wrote:
> > >On Thu, Jan 23, 2020 at 04:43:23PM -0500, Bruce Ashfield wrote:
> > >>On Thu, Jan 23, 2020 at 4:00 PM Denys
On Thu, Jan 23, 2020 at 5:16 PM Bruce Ashfield wrote:
>
> On Thu, Jan 23, 2020 at 5:05 PM Denys Dmytriyenko wrote:
> >
> > On Thu, Jan 23, 2020 at 04:43:23PM -0500, Bruce Ashfield wrote:
> > > On Thu, Jan 23, 2020 at 4:00 PM Denys Dmytriyenko wrote:
> > > >
> > > > From: Denys Dmytriyenko
> >
On Thu, Jan 23, 2020 at 5:05 PM Denys Dmytriyenko wrote:
>
> On Thu, Jan 23, 2020 at 04:43:23PM -0500, Bruce Ashfield wrote:
> > On Thu, Jan 23, 2020 at 4:00 PM Denys Dmytriyenko wrote:
> > >
> > > From: Denys Dmytriyenko
> > >
> > > Many BSPs require ARM Trusted Firmware (also known as Trusted
On Fri, 2020-01-24 at 11:07 +, Ross Burton wrote:
> packagegroup-base-vfat RRECOMMENDS on dosfstools, but this is GPLv3
> so
> may be blacklisted. Respect INCOMPATIBLE_LICENSE and don't recommend
> if
> GPL-3.0 has been blacklisted.
>
> (From OE-Core rev:
On 1/24/20 3:19 PM, Khem Raj wrote:
> On Fri, Jan 24, 2020 at 1:05 PM Jason Wessel
> wrote:
>>
>> On 1/24/20 1:13 PM, Khem Raj wrote:
>>> On 1/24/20 10:19 AM, Christopher Larson wrote:
What makefile change caused this? That behavior doesn't make much sense
given how make processes its
On Fri, Jan 24, 2020 at 1:05 PM Jason Wessel wrote:
>
> On 1/24/20 1:13 PM, Khem Raj wrote:
> > On 1/24/20 10:19 AM, Christopher Larson wrote:
> >> What makefile change caused this? That behavior doesn't make much sense
> >> given how make processes its command-line arguments.
> >>
> >
> > I
On 1/24/20 1:13 PM, Khem Raj wrote:
> On 1/24/20 10:19 AM, Christopher Larson wrote:
>> What makefile change caused this? That behavior doesn't make much sense
>> given how make processes its command-line arguments.
>>
>
> I agree with you here, it could be a rare check where one want to define
On 1/20/20 8:51 AM, Andrey Zhizhikin wrote:
On Mon, Jan 20, 2020 at 4:52 PM Khem Raj wrote:
Hi all
Recently py2 is removed from oe-core, So I did quick patches to get a
world build going. And
here are initial failures, please help out with recipes your can or
care for. Eventually, the
On 1/24/20 10:19 AM, Christopher Larson wrote:
What makefile change caused this? That behavior doesn't make much sense
given how make processes its command-line arguments.
I agree with you here, it could be a rare check where one want to define
what collect progam should be used ( ld or ar
What makefile change caused this? That behavior doesn't make much sense
given how make processes its command-line arguments.
On Thu, Jan 23, 2020 at 3:34 PM Jason Wessel
wrote:
> The 5.x kernels seem to have made a change to the linker command line
> processing.
>
> When trying to build out of
> Hmm, removing the stamp-extra-info lines leaves me with errors like these:
>
> ERROR: mc:mc-name:library-emscripten-1.0+gitAUTOINC+ab6d30c10c-r0
> do_packagedata_setscene: The recipe library-emscripten is
> trying to install files into a shared area when those files already exist.
> Those
This commit adds a devtool build test for npm recipe:
- devtool.DevtoolAddTests.test_devtool_add_npm
Signed-off-by: Jean-Marie LEMETAYER
---
meta/lib/oeqa/selftest/cases/devtool.py | 20
1 file changed, 20 insertions(+)
diff --git
This commit adds a recipetool creation test for npm recipe:
- recipetool.RecipetoolTests.test_recipetool_create_npm
Signed-off-by: Jean-Marie LEMETAYER
---
meta/lib/oeqa/selftest/cases/recipetool.py | 25 ++
1 file changed, 25 insertions(+)
diff --git
As usual the 'LICENSE' and the 'LIC_FILES_CHKSUM' values reflects all
the license files discovered in the source tree (including the
dependencies).
For npm recipes the 'LIC_FILES_CHKSUM' value contains also the status of
the 'package.json' file of every packages as it contains license
When creating a recipe using devtool, a workspace is created to store
the new recipe, the recipe source and some append files. These append
files are used by devtool to build the recipe using externalsrc (to use
the source which are in the workspace). They can also have some
additional actions
The npm_split_package_dirs function was used by the recipetool when
creating npm recipes. This is not the case anymore.
Signed-off-by: Jean-Marie LEMETAYER
---
meta/lib/oe/package.py | 33 -
1 file changed, 33 deletions(-)
diff --git a/meta/lib/oe/package.py
This commit renames the '--fetch-dev' option into '--npm-dev' as it is a
npm only option.
Signed-off-by: Jean-Marie LEMETAYER
---
scripts/lib/devtool/standard.py | 6 +++---
scripts/lib/recipetool/create.py | 8 +++-
2 files changed, 6 insertions(+), 8 deletions(-)
diff --git
This commit removes the 'noverify' parameter which was added to the url
to fix warnings with the shrinkwrap / lockdown file generation. This is
not needed anymore with the new npm fetcher.
Signed-off-by: Jean-Marie LEMETAYER
---
scripts/lib/recipetool/create.py | 2 --
1 file changed, 2
This commit refactors the npm recipe creation handler to use the new npm
behavior. The process is kept as simple as possible and only generates
the shrinkwrap file.
To avoid naming issues the recipe name is now extracted from the npm
package name and not directly mapped.
Signed-off-by:
When building addons, the node-gyp build tool is looking for python. It
is available in the native directory but not directly in the PATH.
This commit configures npm to use the native python executable.
Signed-off-by: Jean-Marie LEMETAYER
---
meta/classes/npm.bbclass | 3 +++
1 file changed, 3
This commit forces to rebuild the prebuild addons which are using
node-gyp-build.
https://www.npmjs.com/package/node-gyp-build
Signed-off-by: Jean-Marie LEMETAYER
---
meta/classes/npm.bbclass | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/meta/classes/npm.bbclass
This commit splits the npm build in three steps:
1. With the new npmsw fetcher, the sources and dependencies of the
package have been fetched and unpacked. As sources can also be
patched, a local cache must be configured to use these modified
sources.
2. Next, the installation process
When building addons, the node headers are needed to be able to compile
properly. Usually they are downloaded by npm but network access in the
do_compile task are unauthorized. Hopefully the local node headers are
available in the native sysroot so lets use them.
Signed-off-by: Jean-Marie
After the do_fetch task, every other tasks must not access the network.
In order to ensure this point every npm command must use the offline
configuration. In addition setting an invalid proxy is used as a safety.
Signed-off-by: Jean-Marie LEMETAYER
---
meta/classes/npm.bbclass | 3 +++
1 file
Hi folks and happy new year,
For readability here is a link if you want the history of this patchset:
http://lists.openembedded.org/pipermail/openembedded-core/2019-December/290298.html
--- V4
The patches can be found here:
On 1/24/20 3:42 AM, Ross Burton wrote:
On 23/01/2020 22:43, Denys Dmytriyenko wrote:
Such as all the various cortex etc CPU tuning files?
LOL! :) Of course, since ARM is such an inferior arch to x86.
Otherwise we
should move everything that is not needed by qemux86 to meta-intel...
JK :)
> > To be honest, I'm not completely sure. I based this class off of
> > native.bbclass and nativesdk.bbclass and they both do it. I have
> > little idea what stamp-extra-info actually does.
>
> My suggestion is not to do that. native and to a lesser extent
> nativesdk are "special" in ways your
On 1/24/20 2:17 AM, Alexander Kanavin wrote:
Unset LD, and do not set ld in cross file from LD as
new version of meson passes that value directly
to -fuse-ld=... which requires one of lld, bfd, gold.
this looks ok
Signed-off-by: Alexander Kanavin
---
meta/classes/meson.bbclass
Apologies for cross posting.
The next zeus dot release is scheduled to be built on Feb 3.
Please submit patches or backport requests to the list(s) by Jan 30th.
Regards,
Armin
--
___
Openembedded-core mailing list
On Fri, 2020-01-24 at 15:26 +, chris.lapla...@agilent.com wrote:
> Hi Richard,
>
> > > I have a few concerns/questions:
> > > [a] Is the basic premise of a custom CLASSOVERRIDE supported by
> > > Yocto? Our situation seems a bit weird, because our emscripten
> > > recipes are still sort of
== Series Details ==
Series: "[meta-oe] nmap: Use py3 in dep..." and 5 more
Revision: 1
URL : https://patchwork.openembedded.org/series/22272/
State : failure
== Summary ==
Thank you for submitting this patch series to OpenEmbedded Core. This is
an automated response. Several tests have been
Signed-off-by: Khem Raj
---
meta-oe/recipes-extended/libimobiledevice/libplist_2.1.0.bb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta-oe/recipes-extended/libimobiledevice/libplist_2.1.0.bb
b/meta-oe/recipes-extended/libimobiledevice/libplist_2.1.0.bb
index
Fix packaging to match py3 module install dir
Signed-off-by: Khem Raj
---
meta-oe/recipes-extended/konkretcmpi/konkretcmpi_0.9.2.bb | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/meta-oe/recipes-extended/konkretcmpi/konkretcmpi_0.9.2.bb
Signed-off-by: Khem Raj
---
meta-oe/recipes-security/nmap/nmap_7.80.bb | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/meta-oe/recipes-security/nmap/nmap_7.80.bb
b/meta-oe/recipes-security/nmap/nmap_7.80.bb
index 2ac600c782..96af17efdf 100644
---
Signed-off-by: Khem Raj
---
meta-gnome/recipes-gnome/gnome-menus/gnome-menus3_3.32.0.bb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta-gnome/recipes-gnome/gnome-menus/gnome-menus3_3.32.0.bb
b/meta-gnome/recipes-gnome/gnome-menus/gnome-menus3_3.32.0.bb
index
Signed-off-by: Khem Raj
---
meta-oe/recipes-dbs/postgresql/postgresql.inc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta-oe/recipes-dbs/postgresql/postgresql.inc
b/meta-oe/recipes-dbs/postgresql/postgresql.inc
index 8ecf2fd3ca..d35711c1e5 100644
---
Signed-off-by: Khem Raj
---
meta-networking/recipes-support/spice/spice_git.bb | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/meta-networking/recipes-support/spice/spice_git.bb
b/meta-networking/recipes-support/spice/spice_git.bb
index ebf4d576e5..9d3a0e6cb5 100644
---
> From: LAPLANTE,CHRIS (Agilent USA)
> Sent: Thursday, January 16, 2020 3:21 PM
> To: Pascal Huerst ; Richard Purdie
> ; openembedded-
> c...@lists.openembedded.org
> Cc: Rich Persaud
> Subject: RE: [OE-core] Looking for a way to build latest tagged releases in
> recipes
>
> > TODO:
> >
> > *
On Fri, Jan 24, 2020 at 01:47:48PM +0100, Alexander Kanavin wrote:
> I have traced the failing tests to missing supplementary shell scripts that
> apparently are newly added, and weren't packaged to the target.
>
> Also, /tmp indeed wasn't big enough.
>
> With those issues addressed (patch is
Hi Richard,
> > I have a few concerns/questions:
> > [a] Is the basic premise of a custom CLASSOVERRIDE supported by
> > Yocto? Our situation seems a bit weird, because our emscripten
> > recipes are still sort of “target” recipes, so I feel a bit funny
> > completely wiping CLASSOVERRIDE.
>
> I
On Fri, 2020-01-24 at 14:04 +, chris.lapla...@agilent.com wrote:
> There are two main goals of this code. First, it sets up dependencies
> between -emscripten recipes. Second, it sets ‘prefix’ to be
> ‘/usr/js/’ so that, for example, a “foo” and “foo-emscripten” recipe
> that both install
From: Henning Schild
The comparison of the stat st_dev is not enough to judge whether
hardlinking will work. One example would be where you try and hardlink
across two bind-mounts of a directory. The st_dev will be the same and
the operation will still fail.
Instead of implementing a check to
Hi all,
For about two years now, we have been using Emscripten together with Yocto, via
an emscripten.bbclass that I wrote. In a nutshell, it works by conducting the
actual build in a Docker container, whose image is where Emscripten is actually
installed. I mount all the necessary
On Jan 24, 2020, at 12:56 PM, Richard Purdie richard.pur...@linuxfoundation.org
wrote:
> On Mon, 2020-01-20 at 11:26 +0100, Jean-Marie LEMETAYER wrote:
>> Hi folks and happy new year,
>>
>> For readability here is a link if you want the history of this patchset:
>>
I have traced the failing tests to missing supplementary shell scripts that
apparently are newly added, and weren't packaged to the target.
Also, /tmp indeed wasn't big enough.
With those issues addressed (patch is coming), I am still having two
failures:
# Failed test
On Mon, 2020-01-20 at 11:26 +0100, Jean-Marie LEMETAYER wrote:
> Hi folks and happy new year,
>
> For readability here is a link if you want the history of this patchset:
> http://lists.openembedded.org/pipermail/openembedded-core/2019-December/290298.html
Thanks for this! I think we're nearly
On 23/01/2020 22:43, Denys Dmytriyenko wrote:
Such as all the various cortex etc CPU tuning files?
LOL! :) Of course, since ARM is such an inferior arch to x86. Otherwise we
should move everything that is not needed by qemux86 to meta-intel... JK :)
I almost pre-empted this comment in my
On Jan 23, 2020, at 8:25 PM, Andre McCurdy armccu...@gmail.com wrote:
> On Thu, Jan 23, 2020 at 7:24 AM Richard Purdie
> wrote:
>> On Thu, 2020-01-23 at 09:59 -0500, Jean-Marie LEMETAYER wrote:
>> > On Jan 23, 2020, at 3:37 PM, Richard Purdie
>> > richard.pur...@linuxfoundation.org wrote:
>> > >
packagegroup-base-vfat RRECOMMENDS on dosfstools, but this is GPLv3 so
may be blacklisted. Respect INCOMPATIBLE_LICENSE and don't recommend if
GPL-3.0 has been blacklisted.
(From OE-Core rev: de780ebf76893db43e1a55c54b0c5fbb7537880c)
Signed-off-by: Ross Burton
Signed-off-by: Richard Purdie
Unset LD, and do not set ld in cross file from LD as
new version of meson passes that value directly
to -fuse-ld=... which requires one of lld, bfd, gold.
Signed-off-by: Alexander Kanavin
---
meta/classes/meson.bbclass | 5 -
meta/recipes-devtools/meson/meson.inc
Hard-coding ld to bfd in meson cross file wasn't necessary after all. I am
not sure what choice meson is going to make when it's not specified, but at
least it should be now possible to change it to something else. I will send
a corrected patch in a second.
Alex
On Fri, 24 Jan 2020 at 10:09,
Right, I'll take a closer look and make it honor the setting.
Alex
On Thu, 23 Jan 2020 at 23:36, Khem Raj wrote:
> On Thu, Jan 23, 2020 at 1:43 PM Alexander Kanavin
> wrote:
> >
> > I once more suggest we deal with all those special cases where linker
> customization is desired later on. New
59 matches
Mail list logo
