From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christopher Lemmer Webber Subject: bug#34526: Updating node.js Date: Sat, 16 Nov 2019 15:28:30 -0500 Message-ID: <871ru7h8gh.fsf@dustycloud.org> References: <87d0npb1tx.fsf@atufi.org> <877edw6cta.fsf@fsfe.org> <87h8cz20ic.fsf@atufi.org> <877edud0ha.fsf@fsfe.org> <87va1doz0z.fsf@atufi.org> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:470:142:3::10]:52274) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iW4gp-0000Ej-Kr for bug-guix@gnu.org; Sat, 16 Nov 2019 15:29:04 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iW4go-0000mY-Ll for bug-guix@gnu.org; Sat, 16 Nov 2019 15:29:03 -0500 Received: from debbugs.gnu.org ([209.51.188.43]:59165) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1iW4go-0000mQ-JQ for bug-guix@gnu.org; Sat, 16 Nov 2019 15:29:02 -0500 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1iW4go-0004nO-FR for bug-guix@gnu.org; Sat, 16 Nov 2019 15:29:02 -0500 Sender: "Debbugs-submit" Resent-Message-ID: In-reply-to: <87va1doz0z.fsf@atufi.org> List-Id: Bug reports for GNU Guix List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-guix-bounces+gcggb-bug-guix=m.gmane.org@gnu.org Sender: "bug-Guix" To: 34526@debbugs.gnu.org Cc: jlicht@fsfe.org 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 >> inclusion in Guix proper. >> >> I don't really see any way forward between convincing the fine node >> folks to see the 'error of their ways', or to implement a >> ABI-compatible >> replacement for llhttp that we can actually bootstrap. > > Although I would prefer the convincing-the-fine-node-folks solution, > here are two more ways to avoid dropping node with the EOL of 8.x(LTS) > at the end of 2019. > > - Remove llhttp and keep only the "legacy" http-parser, or > > - Accept to bootstrap it -- I mean use intermediary self-compiling > steps, like ccl, golang, java, or haskell do. > The build-time dependencies are: node@11.x -> llhttp -> ts-node -> > typescript -> self (typescript), plus quite a few npm packages. > It seems that node@8.x or 9.x should be a native-input to later > versions, but I do not know enough of Guile / Guix packaging to do it > myself anytime soon. Hello, Went through the process of trying to update node myself, not having remembered this bug. Ran into the same issue. The bug was closed; I doubt we are going to convince the Node folks. Quite a few high-importance projects rely on Node at this point, and we are running an out of date Node which I suspect probably has quite a few insecurities. Our version of Node: v10.16.0 LTS Node: v12.13.0 Latest Node: v13.1.0 One way or another, we will probably need to update. Both Chromium and Icecat depend on Node at this point. I'm not sure if either of them use Node in any active way that an insecruity could manifest or if it's "just for packaging" but I think there's good reason to be nervous about being so out of date.