nodejs December 2015

nodejs@lists.fedoraproject.org

7 participants
8 discussions

Source0 for nodejs modules
by Piotr Popieluch 04 Dec '18

04 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

Builds failing on EPEL7 ppc builders
by Piotr Popieluch 15 Jan '16

15 Jan '16

Hi. Since about one week I have many failed builds of nodejs-packages on EPEL7. The failed builds happen on ppc builders, the builds fail with: EBUG util.py:393: Getting requirements for nodejs-grunt-contrib-internal-0.4.9-4.el7.src DEBUG util.py:393: --> nodejs-packaging-7-1.el7.noarch DEBUG util.py:393: Error: Package: nodejs-packaging-7-1.el7.noarch (build) DEBUG util.py:393: Requires: nodejs(engine) >= 0.10.12 DEBUG util.py:393: You could try using --skip-broken to work around the problem DEBUG util.py:393: You could try running: rpm -Va --nofiles --nodigest https://koji.fedoraproject.org/koji/taskinfo?taskID=12048804 Which makes sense as nodejs is not available on PPC. Do we need to set a BuildArch? Why did this not happen before last week? Piotr

4 10

nodejs-tap update
by Zuzana Svetlikova 21 Dec '15

21 Dec '15

Hi everyone! I, and you probably as well, noticed, that a lot of packages use tap module for testing. The version packaged in fedora is quite outdated and obviously needs an update. My question is, is it a good idea to multiversion this package or should we just update to latest version? I can see developers use 2.x and 1.x version, sometimes even 0.x, 1.x and 2.x dependencies are mostly the same packages in the same versions. Thanks Zuzka

3 2

Quick status update on update npm packaging
by Jared K. Smith 17 Dec '15

17 Dec '15

I've been working like a mad-man the past few days to try to get the dependencies for an updated npm package in better shape. Thank you to all who have already helped by doing package reviews and keeping me honest, and for pitching in with packaging the outstanding dependencies as well. Unfortunately, there's still a stack of outstanding package reviews -- I think I submitted around 20 new packages for review today. I think I've got them all documented on our wiki page at https://fedoraproject.org/wiki/Node.js/npm_update_status (If not, it's a wiki page, so feel free to update/edit/etc.) I'll be back at this tomorrow -- and hopefully I can knock out the remaining dependencies that still haven't been packaged. I'll also keep stabbing at the updates to existing packages that are needed. -- Jared Smith

1 0

lodash
by Tom Hughes 14 Dec '15

14 Dec '15

I've been putting my mind to trying to figure out the mess of craziness that is lodash with the aim up updating it... There are basically two upstream repos I believe: https://github.com/lodash/lodash-cli - the build tool https://github.com/lodash - the actual source Currently have three source packages: nodejs-lodash-cli - generates nodejs-lodash-cli nodejs-lodash - generates nodejs-lodash nodejs-lodash-node - generates many packages It's very dubious to what extent the sources those packages are using are the genuine root source though. The basic story upstream is that the main lodash repo has a build script that can generate a lodash.js single file build and the lodash tool in the lodash-cli repo can then generate all sorts of different builds of lodash from that. Except that lodash-cli is a node program that does require("lodash") but the may the lodash npm is build is to use the lodash command line tool so that's all a bit circular. My feeling is that we should move to a single source package that uses both the upstream repos as sources. The strategy would then be something like this: cd lodash node lib/main/build.js [generates dist/lodash.js] cd ../lodash-cli mkdir node_modules ln -s ../../lodash/dist/lodash.js node_modules lodash modularize modern exports=node -o nodejs-lodash and then a serious of further lodash commands to generate the different builds. It could then spit out a number of different RPMs corresponding to the many different versions that the lodash project publish to the npm registry and also some js- versions if we wanted. My gut feeling is we should all three current source packages and create a new one just called lodash that can spit out whatever node and non-node ones we need but we could also repurpose the existing nodejs-lodash package as the source. So, what do people think? Tom -- Tom Hughes (tom(a)compton.nu) http://compton.nu/

4 10

sntp
by Tom Hughes 14 Dec '15

14 Dec '15

So we have a load more broken dependencies because sntp 2.x has been pushed in rawhide but it requires nodejs 4.x. It seems it really does require 4.x as it uses various "harmony" features, some of which don't even work under node 0.10 even with -harmony. Piotr - did you intend to build it in the side tag? or did you just not realise it needed node 4? Tom -- Tom Hughes (tom(a)compton.nu) http://compton.nu/

5 16

Plans for Node.js
by Zuzana Svetlikova 07 Dec '15

07 Dec '15

Are there any actual plans for Node.js stack in fedora? Are we going to update everything and hope that nothing breaks (much)? Is there any way of knowing beforehand if update will break some other packages (because I don't know of any, so please enlighten me)? What about updating v8, nodejs and npm? Are we going for LTS and npm@2 or directly to v5.x and npm@3? I'm sorry for so many questions, I'd just like to have some answers so I know on what I should focus. Thanks

7 38

Usefulness of the node_g debug build?
by Stephen Gallagher 03 Dec '15

03 Dec '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Should we continue building the node_g binary for the -devel package? First of all, this build is broken on pretty much everything except i686/x86_64. Second, it looks like it's not actually being built with the right arguments anyway (it wants to build with -O0 but it's actually getting overridden by the default -O2 argument anyway). Do we know if this is actually used anywhere at all? If not, I'm recommending we scrap it. If it is, I'd like someone who isn't me to look into getting it built properly on all architectures. If I get no volunteers for the latter in the next week or so, I will default to scrapping it and shipping only the optimized runtime. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlZgSrMACgkQeiVVYja6o6MieACgh66cJ5V1a0R5hPn5q1prxwje R5oAn1Uli++Z9TN5F4DGTNdkKZ0gVHnl =WOm9 -----END PGP SIGNATURE-----

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

nodejs December 2015