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,
From: Brendan Le Foll <brendan.le.f...@intel.com>
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-
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
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
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
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
From: Brendan Le Foll <brendan.le.f...@intel.com>
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 <brendan.le.f...@intel.com>
---
meta/classes/npm.bbclass | 6
From: Brendan Le Foll <brendan.le.f...@intel.com>
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 <brendan.le.f...@intel.com>
---
From: Brendan Le Foll <brendan.le.f...@intel.com>
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 <brendan.le.f...@intel.com>
---
From: Brendan Le Foll <brendan.le.f...@intel.com>
npm class supports the npm fetcher, helping doing the basic compile/install
stages of an npm package
Signed-off-by: Brendan Le Foll <brendan.le.f...@intel.com>
---
meta/classes/npm.bbclass | 25 +
1 file
From: Brendan Le Foll <brendan.le.f...@intel.com>
Signed-off-by: Brendan Le Foll <brendan.le.f...@intel.com>
---
scripts/lib/devtool/package.py | 61 ++
1 file changed, 61 insertions(+)
create mode 100644 scripts/lib/devtool/package.py
From: Brendan Le Foll <brendan.le.f...@intel.com>
Signed-off-by: Brendan Le Foll <brendan.le.f...@intel.com>
---
scripts/lib/devtool/package.py | 62 ++
1 file changed, 62 insertions(+)
create mode 100644 scripts/lib/devtool/package.py
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
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 offer to
install it in
user's
From: Brendan Le Foll brendan.le.f...@intel.com
Signed-off-by: Brendan Le Foll brendan.le.f...@intel.com
---
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
From: Brendan Le Foll brendan.le.f...@intel.com
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 brendan.le.f...@intel.com
There are some characters that cannot appear in the installation path, so we
need to check for these
Signed-off-by: Brendan Le Foll brendan.le.f...@intel.com
---
meta/files/toolchain-shar-extract.sh | 9 ++---
1 file changed, 6 insertions
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
From: Brendan Le Foll brendan.le.f...@intel.com
Signed-off-by: Brendan Le Foll brendan.le.f...@intel.com
---
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
From: Brendan Le Foll brendan.le.f...@intel.com
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 brendan.le.f...@intel.com
There are some characters that cannot appear in the installation path, so we
need to check for these
Signed-off-by: Brendan Le Foll brendan.le.f...@intel.com
---
meta/files/toolchain-shar-extract.sh | 9 ++---
1 file changed, 6 insertions
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
From: Brendan Le Foll brendan.le.f...@intel.com
Signed-off-by: Brendan Le Foll brendan.le.f...@intel.com
---
scripts/lib/devtool/package.py | 63 ++
1 file changed, 63 insertions(+)
create mode 100644 scripts/lib/devtool/package.py
diff --git a/scripts
From: Brendan Le Foll brendan.le.f...@intel.com
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
From: Brendan Le Foll brendan.le.f...@intel.com
x32 builds where broken due to patch rebase not having been done correctly for
this patch
Signed-off-by: Brendan Le Foll brendan.le.f...@intel.com
---
.../openssl/openssl/openssl_fix_for_x32.patch | 30 ++
1 file changed
From: Brendan Le Foll brendan.le.f...@intel.com
x32 builds where broken due to patch rebase not having been done correctly for
this patch
Signed-off-by: Brendan Le Foll brendan.le.f...@intel.com
---
.../openssl/openssl/openssl_fix_for_x32.patch | 30 ++
1 file changed
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 are
From: Brendan Le Foll brendan.le.f...@intel.com
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
From: Brendan Le Foll brendan.le.f...@intel.com
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
From: Brendan Le Foll brendan.le.f...@intel.com
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
From: Brendan Le Foll brendan.le.f...@intel.com
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
From: Brendan Le Foll brendan.le.f...@intel.com
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 brendan.le.f...@intel.com
---
meta/recipes-connectivity/openssl/openssl.inc | 3 +++
1 file
From: Brendan Le Foll brendan.le.f...@intel.com
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
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 brendan.le.f...@intel.com
Because of the SSLv3 POODLE vulnerability, it's preferred to simply disable
SSLv3 even if patched
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 PACKAGECOUNFIG[ssl3] = --no-ssl3
From: Brendan Le Foll brendan.le.f...@intel.com
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 brendan.le.f...@intel.com
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 brendan.le.f...@intel.com
---
meta/recipes-connectivity/openssl/openssl.inc | 4
1
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
38 matches
Mail list logo
