On Tue, Aug 16, 2016 at 05:41:28PM +0100, Christopher Lord wrote:
>I've been using npm.bbclass with various node projects we're working on
>in the Connected Devices team at Mozilla, and had some
>questions/comments about behaviour (note that I'm basing this off of
>ostro master, whi
From: Brendan Le Foll
npm takes a target_arch flag which needs to be set to do some gyp compilations
correctly. It also doesn't use the same mapping as OE for target arch so a
small function is required to make the mapping work. Function is taken from
meta-nodejs
Signed-off-by: Brendan Le
On Thu, May 05, 2016 at 07:10:43PM +1200, Paul Eggleton wrote:
> Note also that devtool add / recipetool create are capable of creating pretty
> complete recipes for npm packages where licenses are also correctly set per
> package (so you get them in the image manifest). I'd strongly recommend us
On Wed, May 04, 2016 at 02:01:40PM -0300, Fabio Berton wrote:
>Yes, it helps.
>Now I see my error... I need to use
>SRC_URI = "npm://[1]registry.npmjs.org;name=${PN};version=${PV}"
>My recipe it's getting sources from github and not from registry.
>Thanks!
No problem. FYI I hav
n and I tried with all versions available on meta-nodejs and
>meta-oe version, that has patch to enable --no-registry.
>I'll try with nodejs version that you're using.
>
>On Wed, May 4, 2016 at 11:38 AM, Brendan Le Foll
><[3]brendan.le.f...@intel.com> wrote:
On Tue, May 03, 2016 at 01:24:49PM -0300, Fabio Berton wrote:
>Hi all!
>I'm trying to install some recipes that use npm class and I have two
>questions.
>1 - Why use S = "${WORKDIR}/npmpkg"? This not work for me.
That's surprising the fetcher basically extracts it that way so the
c
From: Brendan Le Foll
Package names cannot contain underscores yet some npm modules use them as part
of the name, replace them with hyphens in the package name.
Signed-off-by: Brendan Le Foll
---
meta/classes/npm.bbclass | 6 --
meta/lib/oe/package.py | 2 +-
2 files changed, 5
From: Brendan Le Foll
Typically in a node/npm compiled modules the module is named .node. This is a
binary module without a wrapper so it can actually be relatively large if
unstripped.
Signed-off-by: Brendan Le Foll
---
meta/classes/package.bbclass | 2 +-
1 file changed, 1 insertion(+), 1
From: Brendan Le Foll
Typically in a node/npm compiled modules the module is named .node. This is a
binary module without a wrapper so it can actually be relatively large if
unstripped.
Signed-off-by: Brendan Le Foll
---
meta/classes/package.bbclass | 2 +-
1 file changed, 1 insertion(+), 1
From: Brendan Le Foll
npm class supports the npm fetcher, helping doing the basic compile/install
stages of an npm package
Signed-off-by: Brendan Le Foll
---
meta/classes/npm.bbclass | 25 +
1 file changed, 25 insertions(+)
create mode 100644 meta/classes/npm.bbclass
From: Brendan Le Foll
Signed-off-by: Brendan Le Foll
---
scripts/lib/devtool/package.py | 61 ++
1 file changed, 61 insertions(+)
create mode 100644 scripts/lib/devtool/package.py
diff --git a/scripts/lib/devtool/package.py b/scripts/lib/devtool
From: Brendan Le Foll
Signed-off-by: Brendan Le Foll
---
scripts/lib/devtool/package.py | 62 ++
1 file changed, 62 insertions(+)
create mode 100644 scripts/lib/devtool/package.py
diff --git a/scripts/lib/devtool/package.py b/scripts/lib/devtool
On Thu, Aug 27, 2015 at 03:19:01PM +0100, Paul Eggleton wrote:
> Hi Brendan,
>
> > 'bitbake -e %s | grep IMAGE_PKGTYPE' % (args.recipename), watch=False) +
> > except bb.process.ExecutionError as e:
> > +logger.error('Unable to get IMAGE_PKGTYPE for image')
> > +return e.exitcod
You can now set SDKEXTPATH which will change the default extensible SDK install
path, as feedback from Christopher and change the error message as suggest by
Randy.
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://li
From: Brendan Le Foll
Signed-off-by: Brendan Le Foll
---
meta/files/toolchain-shar-extract.sh | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/meta/files/toolchain-shar-extract.sh
b/meta/files/toolchain-shar-extract.sh
index 41b3f2c..edf26f6 100644
--- a/meta/files
From: Brendan Le Foll
Extensible SDK cannot be installed as root so by default offer to install it in
user's home directory under distro/distro_version replacing the normal SDK
version '+' char with a '_' as that's a restricted character for bitbake
Signed-off-
From: Brendan Le Foll
There are some characters that cannot appear in the installation path, so we
need to check for these
Signed-off-by: Brendan Le Foll
---
meta/files/toolchain-shar-extract.sh | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/meta/files/toolchain
On Wed, Aug 19, 2015 at 06:52:49PM +0100, Christopher Larson wrote:
>On Wed, Aug 19, 2015 at 6:32 AM, <[1]brendan.le.f...@intel.com> wrote:
>
> From: Brendan Le Foll <[2]brendan.le.f...@intel.com>
>Extensible SDK cannot be installed as root so by default off
From: Brendan Le Foll
Signed-off-by: Brendan Le Foll
---
scripts/lib/devtool/package.py | 63 ++
1 file changed, 63 insertions(+)
create mode 100644 scripts/lib/devtool/package.py
diff --git a/scripts/lib/devtool/package.py b/scripts/lib/devtool
This makes the default SDK install path a bit more usable and fixes YP Bug 6744
- https://bugzilla.yoctoproject.org/show_bug.cgi?id=6744 by validating
submitted paths do not contain ' @+'
--
___
Openembedded-core mailing list
Openembedded-core@lists.o
From: Brendan Le Foll
Extensible SDK cannot be installed as root so by default offer to install it in
user's home directory under distro/distro_version replacing the normal SDK
version '+' char with a '_' as that's a restricted character for bitbake
Signed-off-
From: Brendan Le Foll
There are some characters that cannot appear in the installation path, so we
need to check for these
Signed-off-by: Brendan Le Foll
---
meta/files/toolchain-shar-extract.sh | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/meta/files/toolchain
From: Brendan Le Foll
Signed-off-by: Brendan Le Foll
---
meta/files/toolchain-shar-extract.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/files/toolchain-shar-extract.sh
b/meta/files/toolchain-shar-extract.sh
index c4c2a70..d8e714a 100644
--- a/meta/files
From: Brendan Le Foll
x32 builds where broken due to patch rebase not having been done correctly for
this patch
Signed-off-by: Brendan Le Foll
---
.../openssl/openssl/openssl_fix_for_x32.patch | 30 ++
1 file changed, 30 insertions(+)
diff --git
a/meta/recipes
From: Brendan Le Foll
I made a mistake rebasing the patch, this is a fix
Brendan Le Foll (1):
openssl: Fix x32 openssl patch which was not building
.../openssl/openssl/openssl_fix_for_x32.patch | 30 ++
1 file changed, 30 insertions(+)
--
2.3.5
From: Brendan Le Foll
x32 builds where broken due to patch rebase not having been done correctly for
this patch
Signed-off-by: Brendan Le Foll
---
.../openssl/openssl/openssl_fix_for_x32.patch | 30 ++
1 file changed, 30 insertions(+)
diff --git
a/meta/recipes
On Wed, Mar 25, 2015 at 07:32:20AM -0700, akuster808 wrote:
> On 3/25/15 6:15 AM, brendan.le.f...@intel.com wrote:
>
> Thank you for your support on Dizzy.
>
> If it isn't too mush trouble, is it possible to get the CVE's list are
> are being addressed by this update?
Here are the CVEs that ar
From: Brendan Le Foll
Security update, some patches modified to apply correctly mostly due to
upstream changing indentation/styling
* configure-targets.patch updated
* fix-cipher-des-ede3-cfb1.patch updated
* openssl-avoid-NULL-pointer-dereference-in-EVP_DigestInit_ex.patch updated
* openssl
From: Brendan Le Foll
Due to recent security fixes it's advisable to update to the latest openssl
version. I propose an update to 1.0.1m rather than simply patching the
individual CVEs which is much more time consuming/error prone
This is exactly the same patch as for daisy since they
From: Brendan Le Foll
Due to recent security fixes it's advisable to update to the latest openssl
version. I propose an update to 1.0.1m rather than simply patching the
individual CVEs which is much more time consuming/error prone
Brendan Le Foll (1):
openssl: Upgrade to 1.0.1m
.../op
From: Brendan Le Foll
Security update, some patches modified to apply correctly mostly due to
upstream changing indentation/styling
* configure-targets.patch updated
* fix-cipher-des-ede3-cfb1.patch updated
* openssl-avoid-NULL-pointer-dereference-in-EVP_DigestInit_ex.patch updated
* openssl
From: Brendan Le Foll
Does the same thing but now uses PACKAGECONFIG as discussed on this ML
Brendan Le Foll (1):
openssl: disable SSLv3 by default
meta/recipes-connectivity/openssl/openssl.inc | 3 +++
1 file changed, 3 insertions(+)
--
2.2.1
From: Brendan Le Foll
Because of the SSLv3 POODLE vulnerability, it's preferred to simply disable
SSLv3 even if patched with the TLS_FALLBACK_SCSV
Signed-off-by: Brendan Le Foll
---
meta/recipes-connectivity/openssl/openssl.inc | 3 +++
1 file changed, 3 insertions(+)
diff --git a
On Mon, Feb 16, 2015 at 03:35:32PM +0100, Sven Ebenfeld wrote:
> Am 16.02.2015 um 14:51 schrieb Brendan Le Foll:
> >
> > No real reason, was trying to keep it as simple as possible whilst
> > making it clear it was not a good idea to re-enable it. I can make it
> > a P
On Mon, Feb 16, 2015 at 02:10:03PM +0100, Martin Jansa wrote:
> On Mon, Feb 16, 2015 at 11:18:29AM +, brendan.le.f...@intel.com wrote:
> > From: Brendan Le Foll
> >
> > Because of the SSLv3 POODLE vulnerability, it's preferred to simply disable
> >
From: Brendan Le Foll
SSLv3 should be disabled because of POODLE, this patch disables it completely
Brendan Le Foll (1):
openssl: disable SSLv3 by default
meta/recipes-connectivity/openssl/openssl.inc | 4
1 file changed, 4 insertions(+)
--
2.2.1
From: Brendan Le Foll
Because of the SSLv3 POODLE vulnerability, it's preferred to simply disable
SSLv3 even if patched with the TLS_FALLBACK_SCSV
Signed-off-by: Brendan Le Foll
---
meta/recipes-connectivity/openssl/openssl.inc | 4
1 file changed, 4 insertions(+)
diff --git a
From: Martin Jansa
* until now all recipes were respecting VIRTUAL-RUNTIME_initscripts
variable but commit bba835fed88c3bd5bb5bd58962034aef57c408d8
hardcoded "initscripts" runtime dependency
Signed-off-by: Martin Jansa
Signed-off-by: Saul Wold
Signed-off-by: Brendan Le Foll
I'm trying to understand the logic behind the uclibc recipes, it seems
it is using fairly random points in history of git master and not the
0.9.33 point releases that have been made.
What is the logic behind that and why not use the upstream release
builds as a starting point?
Thanks,
Brendan
--
39 matches
Mail list logo
