nodejs January 2016

nodejs@lists.fedoraproject.org

6 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

nodejs-packaging
by Tom Hughes 31 Jan '16

31 Jan '16

I've been working on a few updates for the nodejs-packaging tools which I plan to build in rawhide in the next few days. The first change is to add a --move switch to %nodejs_fixdep which allows a dependency to be moved to a different section while preserving it's version. So, for example: %nodejs_fixdep --dev --move nan Will move the nan dependency to devDependencies - this is actually a real use case because we only need it for build but it will normally be in the main dependencies so that that npm can build a binary module when installing it. You can also move things to/from optionalDependencies in the same way. The second change is to add a --optional switch to %nodejs_symlink_deps to allow optional dependencies to be included. The final planned changed, and the one that may be controversial, is to start generating Suggests dependencies for anything listed as optional in the package.json file. There is actually a use case for that (BZ#1290781) and I personally think it's the right thing to do anyway, but I'm interested to hear what other people think before I go ahead with that. Tom -- Tom Hughes (tom(a)compton.nu) http://compton.nu/

2 3

npm deps broken in Rawhide
by Stephen Gallagher 18 Jan '16

18 Jan '16

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Tom, sometime over the weekend you built nodejs-osenv in Rawhide rather than the f24-nodejs4 tag; this broke the ability to install the older npm package on Rawhide (and is breaking other projects' builds, such as Cockpit). Can you look into whether npm can actually run with the new oserv and update the dep with %nodejs_fixdep if it can? Jared and I are going to continue working to finish the update to the new npm today, but if it continues to take extra time, we need to try to unbreak Rawhide concurrently. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlac+ogACgkQeiVVYja6o6OlaACgkOo2Blsm8/Lu0hVl09kZeSef 6DwAoI46GQ+SD47vNvZdrloES1xpb6sr =5w/I -----END PGP SIGNATURE-----

2 3

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

Re: pnemade pushed to nodejs-deep-extend (el6). "Specify exclusively arch list as per nodejs packaging guidelines"
by Tom Hughes 13 Jan '16

13 Jan '16

On 13/01/16 11:43, notifications(a)fedoraproject.org wrote: > From 393558883ad677a3e3b6dcb74ce42a189d712576 Mon Sep 17 00:00:00 2001 > From: Parag Nemade <pnemade(a)redhat.com> > Date: Wed, 13 Jan 2016 10:43:33 +0530 > Subject: Specify exclusively arch list as per nodejs packaging guidelines > > --- > nodejs-deep-extend.spec | 7 +++++-- > 1 file changed, 5 insertions(+), 2 deletions(-) > > diff --git a/nodejs-deep-extend.spec b/nodejs-deep-extend.spec > index e34ec94..dbe09a0 100644 > --- a/nodejs-deep-extend.spec > +++ b/nodejs-deep-extend.spec > @@ -5,14 +5,14 @@ > > Name: nodejs-%{module_name} > Version: 0.3.2 > -Release: 1%{?dist} > +Release: 2%{?dist} > Summary: Recursive object extending > > License: MIT > URL: https://github.com/unclechu/node-deep-extend > Source0: http://registry.npmjs.org/%{module_name}/-/%{module_name}-%{version}.tgz > BuildArch: noarch > -ExclusiveArch: %{nodejs_arches} noarch > +ExclusiveArch: %{ix86} x86_64 %{arm} noarch This is the exact opposite of what the guidelines say surely? The whole point of adding the nodejs_arches macro was to avoid having the list of supported architectures embedded in all the spec files, so that they could be extended in future without changing every spec. Tom -- Tom Hughes (tom(a)compton.nu) http://compton.nu/

3 8

Check dependants before pushing to stable
by Troy Dawson 13 Jan '16

13 Jan '16

Hi, I need to do a security update for a nodejs package, nodejs-ws to be specific. The fix was to update to the latest package, and didn't give any other alternatives. So, I've got my package made, in bohdi, and tomorrow will be when the week's wait is up. Here's the problem, and I think many of us nodejs packages have hit it. You update a package, every test you try works, great. You push it to stable, and the next morning you get a pile of emails stating that you broke all sorts of dependencies. Not that your new package can't install, but other packages that depended on your package can no longer install. How can I check for dependent issues before I push to stable? This must be a fairly common thing for Fedora but I can't seem to find documentation for it. Everything I find talks about your new package being able to install, not the other way around. Troy

3 3

Review request
by Tom Hughes 01 Jan '16

01 Jan '16

Could somebody have a look at reviewing 1274512 please, only I just accidentally pushed a nodejs-tape update that requires it... Tom -- Tom Hughes (tom(a)compton.nu) http://compton.nu/

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

nodejs January 2016