Source0 for nodejs modules
by Piotr Popieluch
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#Usi...
5 years
Builds failing on EPEL7 ppc builders
by Piotr Popieluch
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
7 years, 10 months
nodejs-tap update
by Zuzana Svetlikova
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
7 years, 11 months
Quick status update on update npm packaging
by Jared K. Smith
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
7 years, 11 months
lodash
by Tom Hughes
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/
7 years, 11 months
sntp
by Tom Hughes
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/
7 years, 11 months
Plans for Node.js
by Zuzana Svetlikova
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 years, 12 months
Usefulness of the node_g debug build?
by Stephen Gallagher
-----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-----
8 years
