Christopher Lemmer Webber writes:
> That's fair.
>
> I have a personal project that requires that I use a newer version of
> Node (at least version 11). So if anyone has a recipe on how to get
> Node running, even the wrong way per Guix standards, maybe useful to
> post to this bug in the meanwh
Marius Bakke writes:
> Christopher Lemmer Webber writes:
>
>> Daniel Gerber writes:
>>
>>> Hi,
>>>
>>> 2019-02-20, Jelle Licht:
Daniel Gerber writes:
> [snip]
> What about statically linking llhttp's C "sources" included in
> node? Building v11.10.0 succeeds with this:
Christopher Lemmer Webber writes:
> Daniel Gerber writes:
>
>> Hi,
>>
>> 2019-02-20, Jelle Licht:
>>> Daniel Gerber writes:
>>>
[snip]
What about statically linking llhttp's C "sources" included in
node? Building v11.10.0 succeeds with this:
>>>
>>> You could do this, of cours
Daniel Gerber writes:
> Hi,
>
> 2019-02-20, Jelle Licht:
>> Daniel Gerber writes:
>>
>>> [snip]
>>> What about statically linking llhttp's C "sources" included in
>>> node? Building v11.10.0 succeeds with this:
>>
>> You could do this, of course, but afaics this is not acceptable for
>> inclu
Hi,
2019-02-20, Jelle Licht:
Daniel Gerber writes:
[snip]
What about statically linking llhttp's C "sources" included in
node? Building v11.10.0 succeeds with this:
You could do this, of course, but afaics this is not acceptable
for
inclusion in Guix proper.
I don't really see any wa
Daniel Gerber writes:
> [snip]
> What about statically linking llhttp's C "sources" included in
> node? Building v11.10.0 succeeds with this:
>
You could do this, of course, but afaics this is not acceptable for
inclusion in Guix proper.
I don't really see any way forward between convinci
I mean, it builds after also updating libuv:
--- gnu/packages/libevent.scm.orig 2019-02-13 10:04:31.913458810 +0100
+++ gnu/packages/libevent.scm 2019-02-19 13:30:49.496780516 +0100
@@ -124,14 +124,14 @@
(define-public libuv
(package
(name "libuv")
-(version "1.24.0")
+(version "
2019-02-18, Jelle Licht:
It seems that llhttp includes a build step for generating
C-files using TypeScript, making it a non-starter for proper
packaging in Guix.
See https://github.com/nodejs/llhttp/issues/14 for more details,
but sadly no solution.
What about statically linking llhttp
On Mon, 18 Feb 2019 21:50:41 +0100
Jelle Licht wrote:
> See https://github.com/nodejs/llhttp/issues/14 for more details, but
> sadly no solution.
Thanks for looking into these things, really sounds sad. It would be
nice if the JavaScript/node.js people would care more about
bootstrapping from so
Daniel Gerber writes:
> Notes on v11.10.0:
> - it does support openssl@1.1.1
> - it ships with libuv 1.26.0 (1.24.0 in guix)
> - some previously bundled deps are absent from tarball
> - NODE_EXPERIMENTAL_HTTP is a no-op / always defined
>
> There is an issue with the alternative http parser, `l
Trying to build the current upstream version, 11.10.0...
diff --git a/gnu/packages/node.scm b/gnu/packages/node.scm
index a0221601d..9d35765eb 100644
--- a/gnu/packages/node.scm
+++ b/gnu/packages/node.scm
@@ -45,26 +45,17 @@
(define-public node
(package
(name "node")
-(version "9.11
11 matches
Mail list logo
