nodejs September 2016

nodejs@lists.fedoraproject.org

4 participants
7 discussions

Source0 for nodejs modules
by Piotr Popieluch 03 Dec '18

03 Dec '18

The the Node.js guidelines say about Source0 [1]: "The canonical method for shipping most node modules is tarballs from the npm registry" and "This method [PP: tarbals from npm] should be preferred to using checkouts from git or automatically generated tarballs from GitHub." But I think that in following cases it would be better to use sources from the upstream project: 1) When the license is not included in NPM but is in upstream project. o Because we are not supposed to ship the license separate from the sources. 2) When the tests are not included. o In this case we need to download the sources from NPM and from upstream project, which seems redundant and a waste of work. 3) When NPM content is generated and source files are not in NPM. o This would mean to download sources from NPM and upstream project, delete the NPM sources in prep and generate the files again. Are there good reason to enforce the use of NPM sources which I am missing? What is your opinion? I would like to suggest to ad those three exceptions to the guidelines. Piotr [1]: https://fedoraproject.org/wiki/Packaging:Node.js?rd=Node.js/Packagers#Using…

4 5

EPEL 7 Node.js Uplift
by Stephen Gallagher 28 Sep '16

28 Sep '16

I updated the Bodhi update in EPEL to the latest 6.7.0 security release last night. I just want to remind people that there remain only three days until EOL of 0.10.x, so I think we really need to make the cut-over today or tomorrow by providing karma to push the update to stable. It takes at least a day to make it to most mirrors. I wish we had a bit more time for this, but security updates seem to be coming at an accelerated pace lately. I missed Jim Perrin's original note about a Fedora Magazine post for EPEL and CentOS to link to (sorry about that, Jim), but I'll see if I can get something written up and published today. It's probably "too little, too late", but I'll at least provide the justification. Part of the reason I support making the cutover immediately is because the high-severity security updates from last night *also* impact 0.10.x and we don't have a meaningful way to deliver 0.10.47 to EPEL 7 right now (since the 6.7.0 package is in epel-testing). We either need to cut over to 6.7.0 or else withdraw that update, push the 0.10.47 update, wait for it to go stable and then reintroduce 6.7.0. This seems like a large amount of effort for very little benefit. (Apologies for stream-of-consciousness; I'm thinking this through as I type) I do see one alternative if we want to provide a little more time in testing for 6.x... we could do the above 0.10.47 release by pulling 6.x, *rush* that in by karma-cheating[*], put 6.7.0 back in updates testing and hold off on the cutover for X days or the next security release, whichever comes first. That's fairly convoluted and I'm not personally willing to do the work for it, but if someone wants to take over I'm game. [*] Setting karma requirements to 1 and having one of us hand-wave it.

1 0

Newbie question . . fetch_kindle.js
by Philip Rhoades 18 Sep '16

18 Sep '16

People, This looks like a very low volume list so I guess if there is no response I should try the main Fedora user list . . Anyway, I am trying to get this working: https://gist.github.com/yangchenyun/a1c123935d82f5e25d57 on F25 x86_64 and I am getting a sqlite3 error so I did: dnf install nodejs-sqlite3 with no improvement - I did try: npm install sqlite3 --build-from-source but got a whole lot of errors and in any case, I would like to stick to just RPMs if I can . . Suggestions? Thanks, Phil.

2 2

NodeJS on Fedora Rawhide
by Robert Van Voorhees 16 Sep '16

16 Sep '16

Hey guys, anyone notice that updating to Node 6.5 is pulling in a whole lot more stuff now than it used to? I'm trying to make the move from 6.3 to 6.5, and it's forcing updates to gnome-shell, uninstalling Firefox, and a whole range of weird behavior. Does it have something to do with upgrading v8, or one of the other dependencies?

2 7

Strategy for Node.js upgrade in EPEL 7
by Stephen Gallagher 13 Sep '16

13 Sep '16

Yesterday, I built the latest upstream version of Node.js for EPEL 7 (this version will be supported until 2019-04-01) I have added it to the buildroot overrides so that anyone can rebuild their npm modules at will. This *is* an API/ABI-breaking upgrade, so some modules will fail to function on this version. We don't know ahead of time which ones will do so, except for binary modules. I am electing *not* to build in a side-tag for this. Many of the noarch packages will just work (or they won't, and a rebuild wouldn't help us detect this). I am therefore putting out a request to anyone using nodejs-* packages in EPEL to please install nodejs from epel-testing[2] and help us find any issues before October. If you maintain a nodejs-* package in EPEL, please test that it continues to work with Node.js 6.x. If it does not, please update it and build it in Koji. If the update is compatible with 0.10.x, feel free to submit it to Bodhi; if it is not (or you simply want to push them all together), please notify me directly I will add it to the Bodhi update for nodejs so that it goes stable at the same time as the interpreter. Due to upstream terminating support for 0.10.x on 2016-10-01, we *will* be cutting over to 6.x on or around that date, so this testing request is time-sensitive. [1] There's a long story behind this, but the short version is that the bundling style of npm makes it basically impossible to maintain, as even bugfix releases result in a huge tangled mess of dependencies. It is infeasible to keep up with bugfix and security updates. Node.js upstream is highly responsible and responsive about security issues, so we considered it an acceptable risk to bundle npm with the main package. [2] https://copr.fedorainfracloud.org/coprs/g/nodejs-sig/nodejs-epel/ also has it, if your epel-testing mirrors don't have it yet.

1 1

Re: nodejs update
by Stephen Gallagher 12 Sep '16

12 Sep '16

On 08/11/2016 07:43 AM, Stephen Gallagher wrote: > On 08/11/2016 05:16 AM, Zuzana Svetlikova wrote: >> Hi! >> >> As some of you may know, nodejs package that is present in >> EPEL is pretty outdated. The current v0.10 that we have will >> go EOL in October and npm (package manager) is already not >> maintained. >> >> Currently, upstreams' plan is to have two versions of Long >> Term Support (LTS) at once, one in active development and one >> in maintenance mode. >> Currently active is v4, which is switching to maintenance in >> April and v6 which is switching to LTS in October. >> This is also reason why we would like to skip v4, although >> both will get security updates. Nodejs v6 also comes with >> newer npm and v8 (which might best be bundled, as it is in >> Fedora and Software Collections) (v8 might concern ruby and >> database maintainers, but old v8 package still remains in >> the repo). >> >> There was also an idea to have both LTS versions in repo, >> but we're not quite sure, how we'd do it and if it's even a >> good idea. >> >> Also, another thing is, if it is worth of updating every year >> to new LTS or update only after the current one goes EOL. >> According to guidelines, I'd say it's the latter, but it's >> not exactly how node development works and some feedback from >> users on this would be nice, because I have none. >> >> >> tl;dr Need to update nodejs, but can't decide if v4 or v6, >> v4: will update sooner, shorter support (2018-04-01) >> v6: longer support (2019-04-01), *might* break more things, >> won't be in stable sooner than mid-October if everything >> goes well > > FYI, I think this tl;dr missed explaining why v6 won't be in stable until > mid-October. What Zuzana and I discussed on another list is that the Node.js v6 > schedule has it going into LTS mode on the same day that 0.10.x reaches EOL. > However, v6 is already out and available. The major thing that changes at that > point is just that from then on, they commit to adding no more major features > (as I understand it). This is the best moment for us to switch over to it. > > However, in the meantime we will probably want to be carrying 6.x in > updates-testing for at least a month prior to declaring it stable (with > autokarma disabled) with wide announcements about the impending upgrade. This > will be safe to do since Node.js 6.x has already reached a point where no > backwards-incompatible changes are allowed in, so we can start the migration > process early. > OK, as we stated before, we really need to get Node.js 6.x into the updates-testing repository soon. We mentioned that we wanted it to sit there for at least a month before we cut over, and "at least a month" means "by next week" since the cut over is planned for 2016-10-01. I'm putting together a COPR right now as a first pass at this upgrade: https://copr.fedorainfracloud.org/coprs/g/nodejs-sig/nodejs-epel/ I've run into the following blocker issues: * We cannot jump to 6.x in EPEL 6 easily at this time, because upstream strictly requires GCC 4.8 or later and we only have 4.4 in EPEL 6. It might be possible to resolve this with SCLs, but I am no expert there. Zuzana? * Node.js 4.x and 6.x both *strictly* require functionality from OpenSSL 1.0.2 and cannot run (or indeed build) against OpenSSL 1.0.1. Currently, both EPEL 6 and EPEL 7 have 1.0.1 in their buildroots. I am not aware of any solution (SCL or otherwise) for linking EPEL to a newer version of OpenSSL. The OpenSSL 1.0.2 problem is a significant one; we cannot build against the bundled copy of OpenSSL because it includes patented algorithms that are not acceptable for inclusion in Fedora. We also cannot trivially backport Fedora's OpenSSL 1.0.2 packages because EPEL forbids upgrading packages provided by the base RHEL/CentOS repositories. Right now, the only thing I can think of would be for someone to build a parallel-installable OpenSSL 1.0.2 package for EPEL 6 and EPEL 7 (similar to the openssl101e package available for EPEL 5) and patch our specfile to be able to work with that instead. This is a task I'm not anxious to embark upon personally; there is too much overhead in maintaining a fork of OpenSSL to make me comfortable. How shall we proceed?

1 2

Node 6.5.0
by Tom Hughes 12 Sep '16

12 Sep '16

The nodejs 6.5.0 build that is running now breaks v8 abi so binary extensions will need to be rebuilt. I've got my script ready to go and will run it for rawhide and f25 once the f25 build of nodejs completes - ideally we will then need to add those to the same bodhi update as nodejs for f25. Tom -- Tom Hughes (tom(a)compton.nu) http://compton.nu/

2 5

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

nodejs September 2016