Bug 815018

My firts pkgs need an sponsor

Some informal comments from a quick look at the spec file:

* The BuildRequire of openssl-static is a red flag as you shouldn't be static linking to other packages.

* You are packaging files in /usr/local which is wrong - you probably want to use %configure instead of ./configure so that the prefix is set correctly.

*** Bug 634911 has been marked as a duplicate of this bug. ***

*** Bug 732552 has been marked as a duplicate of this bug. ***

(In reply to comment #2)
> Some informal comments from a quick look at the spec file:
> 
> * The BuildRequire of openssl-static is a red flag as you shouldn't be static
> linking to other packages.
probably I had to change it for openssl-devel?
> 

> * You are packaging files in /usr/local which is wrong - you probably want to
> use %configure instead of ./configure so that the prefix is set correctly.

whats the correct whay? where i need to packaging the files? whats the correct prefix to %configure?

Yes, using openssl-devel instead of openssl-static is the correct way to build against openssl.

The correct prefix is /usr but if you use the %configure macro then that, and lots of other Fedora appropriate settings, will be done for you.

(In reply to comment #6)
> Yes, using openssl-devel instead of openssl-static is the correct way to build
> against openssl.
> 
> The correct prefix is /usr but if you use the %configure macro then that, and
> lots of other Fedora appropriate settings, will be done for you.

Just %configure without any flag?

Many thanks Tom

./configure --build=i686-pc-linux-gnu --host=i686-pc-linux-gnu --program-prefix= --disable-dependency-tracking --prefix=/usr --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc --datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib --libexecdir=/usr/libexec --localstatedir=/var --sharedstatedir=/var/lib --mandir=/usr/share/man --infodir=/usr/share/info

waf-light: error: no such option: --build

how can exclude --build or fix this? what flag i can use for %configure to avoid or fix this error?

That sounds like the configure script might not actually be an autotools configure script?

If it isn't then %configure won't work and you'll have to investigate what options it takes to put things in the right places.

I had to add into the spec this way:

%build
./configure --prefix=/usr
make

Because many of the flags in %configure didnt work, like this:

+ ./configure --build=i686-pc-linux-gnu --host=i686-pc-linux-gnu --program-prefix= --disable-dependency-tracking --prefix=/usr --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc --datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib --libexecdir=/usr/libexec --localstatedir=/var --sharedstatedir=/var/lib --mandir=/usr/share/man --infodir=/usr/share/info --prefix=/usr


waf-light: error: no such option: --build

I buiit a new spec and a new src.rpm I will upload into my fedora people replacing the old ones

I built it again with all the fixed that you suggest.
http://alvesadrian.fedorapeople.org/nodejs.spec
http://alvesadrian.fedorapeople.org/nodejs-0.6.15-1.fc16.src.rpm

How you deal with bundled libs? First two attempts fail on that (see linked duplicates).

which bundled libs? please specify or clearify that.

I dont see any bundle libs there.

https://bugzilla.redhat.com/show_bug.cgi?id=634911#c24

[-] MUST: The License field in the package spec file must match the actual
license.
  - tools/doctool/markdown.js is Released under MIT license and                 
    Copyright 2009-2010 Dominic Baggott and Ash Berli
You do not delete this file. As it is not client-side JavaScript I think we
can't easy bundle it.

  - src/platform_darwin_proctitle.cc, has code taken from the Chromium          
    project copyright Google Inc. and released with the BSD license.

  - tools/closure_linter is copyrighted by The Closure Linter Authors and       
    Google Inc and is released under the Apache license.
Also had not deleted in %prep.

  - doc/sh_main.js, doc/api_assets/sh_main.js,
doc/api_assets/sh_javascript.min.js, doc/sh_javascript.min.js
SHJS - Syntax Highlighting in JavaScript^M                                      
Copyright (C) 2007, 2008 gnombat.net^M                        
License: http://shjs.sourceforge.net/doc/gplv3.html

  - test/internet/testcfg.py
  - test/message/testcfg.py
  - test/pummel/testcfg.py
  - test/simple/testcfg.py
  - tools/cpplint.py
  - tools/js2c.py
  - tools/test.py
  Copyright 2008 the V8 project authors.
  BSD License?

  - tools/doctool
  // Copyright (c) 2009-2010 Dominic Baggott                                    
  // Copyright (c) 2009-2010 Ash Berlin 



There also bundled http-parser and other in directory deps (https://bugzilla.redhat.com/show_bug.cgi?id=732552#c7)

https://bugzilla.redhat.com/show_bug.cgi?id=732552#c31 mention bundled "ev/eio stuff".

As reviewer one of previous request I'm interesting move forward.

Ok i will add this:
License:        MIT/BSD/GPLv3/APACHE

It will fix the issue?

No. Not all so easy unfortunately. Fedora does not permits bundled libs at all - http://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries . Only in some explicitly granted exceptions.

*** Bug 815015 has been marked as a duplicate of this bug. ***

*** Bug 815017 has been marked as a duplicate of this bug. ***

So how can we fix this issue?

what bundle libs? what u mean? i dont see any bundle libs there man.

(In reply to comment #20)
> what bundle libs? what u mean? i dont see any bundle libs there man.

Adrian, take a closer look at the contents of the "deps" directory. I see several libraries there (v8, openssl, etc). Does Node.js link against them?

(In reply to comment #20)
> what bundle libs? what u mean? i dont see any bundle libs there man.
http://fedoraproject.org/wiki/Packaging:Treatment_Of_Bundled_Libraries

(In reply to comment #19)
> So how can we fix this issue?
I think you may start from deleting deps directory in %setup and then try build package.

Cool how i do that? in the %setup?
what flag i need to add to do that? can u help me?

Off course.

Just add
rm -rf deps
just after %setup line.

Then package fail to build. And you may start work to deal with problems to solve it with system libraries.
I can say it may be very hard work in some cases.

It's worth looking at https://bugzilla.redhat.com/show_bug.cgi?id=732552 and probably talking to T.C. Hollingsworth. I suspect you're doing a lot of unnecessary duplication of work, here.

There are several issues here:

* Node bundles a library created by the same upstream called libuv, which basically abstracts networking, filesystem, the event loop, etc. between *nixes and Windows.  That library presently includes bundled copies of libev, libeio, and libc-ares.  All three have out-of-tree patches, so it isn't currently possible to use system versions of these libraries with Node.  AFAIK this is a blocker, so you might as well stop here, but...

* You don't even use the shared libraries upstream does support.  See `./configure --help` and my spec file [1] for info on how to this.  You'll also have to coordinate with Tom Callaway and Thomas Spura on what to do about V8.  Chromium and Node require different versions, though it's possible to build a parallel-installable compat version, as I'm doing for F17 [2].

* There is a file conflict with the /usr/bin/node shipped by the "node" package in Fedora.  I rename everything to "nodejs" to avoid this, and there are several patches in my SRPM [3] that make Node happy with this.

* Node includes a copy of npm, which is also a violation of the bundling policy.  You must build node with `--without-npm` and package npm separately.

[1] http://nodejs.tchol.org/specs/nodejs.spec
[2] http://nodejs.tchol.org/stable/f17/SRPMS/compat-v8-3.6-3.6.6.24-1.fc17.src.rpm
[3] http://nodejs.tchol.org/stable/f16/SRPMS/nodejs-0.6.15-1.fc16.src.rpm

For the record, there used to be a nodejs port onto mozilla libjs ( who is already packaged ) :
https://github.com/zpao/spidernode 

I do not know if that was merged into nodejs, and that would help for libv8 dependency issues.

spidernode is a fork of Node v0.4, which technically makes it packageable because 0.4 didn't have the bundled library issues that 0.6+ does.

Unfortunately, that also makes it unsuitable for most Node users, as the whole world has pretty much moved on to 0.6.  There are lots of libraries that only support 0.6, and it would also require a very old npm.  There are also a lot of native (C++) modules that would be incompatible because they rely on V8 in some way or another.

Besides, V8 isn't the issue.  Upstream supports using a shared libv8 just fine. (In fact, I patched it upstream so it didn't regress to not doing so in the next version.  ;-)

And the spidernode project is stalled.

Regarding bundling, the only interaction I have seen with upstream was rather short, is there a effort to unbundle everything ?

I see :
- openssl
- zlib
- libv8
- npm
- http_parser
- libuv

Openssl, libv8, zlib are ok, they can be built with a systemwide version.

npm can be removed and use a external tarball, so there is only http_parser and libuv.

For libuv, seems all of their changes got pushed to c-ares :
https://github.com/joyent/libuv/pull/374

So maybe this one could be unbundled quite easily.
For libev and libeio, I didn't found much information on the web regarding sending patches upstream, maybe that's something we could try to do to help the unbundling ?

Devs also say they may do release, but not now :
https://github.com/joyent/libuv/issues/354

(In reply to comment #29)
> And the spidernode project is stalled.

Stalled, but not dead apparently.  Brendan Eich said Mozilla intended to update it to 0.6 and was very interested in providing a V8-like API to SpiderMonkey at the last NodeConf.

> Regarding bundling, the only interaction I have seen with upstream was rather
> short, is there a effort to unbundle everything ?
> 
> I see :
> - openssl
> - zlib
> - libv8
> - npm
> - http_parser
> - libuv
> 
> Openssl, libv8, zlib are ok, they can be built with a systemwide version.
> 
> npm can be removed and use a external tarball, so there is only http_parser and
> libuv.

http_parser is already in Fedora:
https://apps.fedoraproject.org/packages/http-parser

libuv ostensibly supports being built as a shared library but last time I tried it it FTBFS.  I haven't really had enough free time to look into what's wrong.

These two aren't a big deal anyway.  FPC would likely grant them an exception since they have the same upstream and aren't intended to be built shared at the moment.

> For libuv, seems all of their changes got pushed to c-ares :
> https://github.com/joyent/libuv/pull/374

Someone's sent a pull request but upstream hasn't accepted it yet.  As soon as it is I'll gladly send them a patch to get shared c-ares working.

> So maybe this one could be unbundled quite easily.
> For libev and libeio, I didn't found much information on the web regarding
> sending patches upstream, maybe that's something we could try to do to help the
> unbundling ?

Patches can be sent to the libev mailing list (they both share the same upstream):
http://lists.schmorp.de/mailman/listinfo/libev

Basically someone needs to send the libuv patches upstream and then update libuv to the latest upstream version (they're several versions behind ATM) just like was done with c-ares above.

If nobody else gets to it I'll finally have some free time to look into all this in earnest over the summer...

T.C. Hollingsworth are interesting on work together on this pkg? we can co-maintained this one if u agree course.

Removing NEEDSPONSOR as it appears that this user is already sponsored.

Upstream latest version 0.8.8.

any progress here?

Adrian, are you still working on this?

Working on that new release

OK; latest version is 0.8.9

For reference, here's my
SPEC: http://www.matthias-runge.de/fedora/nodejs.spec
SRPM: http://www.matthias-runge.de/fedora/nodejs-0.8.9-1.fc17.src.rpm

Currently, there are a few known issues: 
- libuv bundled
- libev bundled
- http_parser partly unbundled, (needs to be linked against systems http_parser)

[mrunge@turing ~]$ ldd /usr/bin/node 
	linux-vdso.so.1 =>  (0x00007fffcecdb000)
	libz.so.1 => /lib64/libz.so.1 (0x0000003428000000)
	libv8.so.3 => /lib64/libv8.so.3 (0x0000003429000000)
	libssl.so.10 => /lib64/libssl.so.10 (0x0000003437400000)
	libcrypto.so.10 => /lib64/libcrypto.so.10 (0x0000003434800000)
	librt.so.1 => /lib64/librt.so.1 (0x0000003427c00000)
	libdl.so.2 => /lib64/libdl.so.2 (0x0000003427400000)
	libstdc++.so.6 => /lib64/libstdc++.so.6 (0x0000003432c00000)
	libm.so.6 => /lib64/libm.so.6 (0x0000003427800000)
	libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x000000342a400000)
	libpthread.so.0 => /lib64/libpthread.so.0 (0x0000003427000000)
	libc.so.6 => /lib64/libc.so.6 (0x0000003426c00000)
	libicui18n.so.48 => /lib64/libicui18n.so.48 (0x0000003448600000)
	libicuuc.so.48 => /lib64/libicuuc.so.48 (0x0000003443a00000)
	libicudata.so.48 => /lib64/libicudata.so.48 (0x0000003445200000)
	libgssapi_krb5.so.2 => /lib64/libgssapi_krb5.so.2 (0x0000003436000000)
	libkrb5.so.3 => /lib64/libkrb5.so.3 (0x0000003436800000)
	libcom_err.so.2 => /lib64/libcom_err.so.2 (0x0000003434c00000)
	libk5crypto.so.3 => /lib64/libk5crypto.so.3 (0x0000003436c00000)
	/lib64/ld-linux-x86-64.so.2 (0x0000003426800000)
	libkrb5support.so.0 => /lib64/libkrb5support.so.0 (0x0000003437000000)
	libkeyutils.so.1 => /lib64/libkeyutils.so.1 (0x0000003435c00000)
	libresolv.so.2 => /lib64/libresolv.so.2 (0x0000003428800000)
	libselinux.so.1 => /lib64/libselinux.so.1 (0x0000003428400000)

Adrian,

since there is substantial interest in this package, please continue or close this review. 
Thanks.

New release with Matthias Runge suggestion:
http://alvesadrian.fedorapeople.org/nodejs.spec
http://alvesadrian.fedorapeople.org/nodejs-0.8.12-1.fc17.src.rpm

Adrian, your "unbundling" attempt did exactly nothing to fix the bundling problem. All you did was point to an external header but still compile and link the internal libraries.

I've done some work upstream and I've gotten some unbundling work taken care for the http_parser and c_ares in the proper way[1].

The upstream maintainer of libuv is working with me right now to allow that library to be linked dynamically as well. Right now, the expectation is that Node.JS 0.9.x will be compatible with Fedora packaging, but we don't anticipate that 0.8.x will be made usable in the immediate future.

Adrian, I appreciate your efforts on this, but if it's alright with you, I'd like to take over the packaging from here. There's still quite a bit left to be done and I'm working closely with upstream to get there.


[1] https://github.com/joyent/node/pull/4183

Stephen, Am sorry but I dont like the idea that you take over my package. We can work together on this am more than glad to add any suggestion but not to take it away from me. All my effort gonna be lost and I gonna continue working on it. Send me all the ideas and mods that u want to apply and I will be glad to do it

(In reply to comment #40)
> Stephen, Am sorry but I dont like the idea that you take over my package. We
> can work together on this am more than glad to add any suggestion but not to
> take it away from me. All my effort gonna be lost and I gonna continue
> working on it. Send me all the ideas and mods that u want to apply and I
> will be glad to do it

With my fedora packager hat on:

Adrian,

with all given respect, I think this package is a number too large for a beginning packager.


Adrian, you tried to package this in a proper way for a half year now; the progress I can see is, that your three proposals provided are basically the same, for three different upstream versions. Apparently you didn't try to solve any of the existing (listed) problems. During this half year, we didn't see progress driven by you. Just hacking together a spec file is just a very small part of the whole packaging thing.


I really urge you to hand over this package review to Stephen. 
He had shown the right way, communicated with upstream and his efforts already showed progress there. 
Adrian, speaking about your lost work. It isn't "your" work and it's not lost; since this is free software, everybody should use and improve it. For my contributions, I'd like to see improvements, nothing is perfect.


With my Red Hat on:
We need this package *sooner* or later packaged in a proper and secure way, and also could use some upstream involvement. Adrian, I currently can't see, how you handle that. 


I'm sorry for these open and harsh words, but I didn't see insight in thoughtful conversation, held in private and also public.

Matthias am not a newbie I built packages for companys in USA since 2006 u can check it on my fedora wiki. Am glad to apply or add any contribution that u have we can co maintain the package please stop pushing me and send me all the contributions that u want to add to the package this didnt help in anything. Ill be waiting for any ur your patches but not more comments like this, If you have doubts about my skill talk with Toshio my mentor!

Could we all take a moment to think of other ways to resolve our problems?  I think that language differences are playing a role in inflating the differences here but that there's also a basic conflict that we should try to address calmly.

Fedora is a Project as well as a Product.  The project aims not just to produce the Fedora distribution but also to teach people how to be better packagers and to foster a collaborative environment for people to make that eventual Fedora distribution the best that it can be.

@adrian - you do have experience with rpm packaging.  But there are many things about packaging for Fedora and working on upstream projects that you may not have experience with.  The free software ecosystem is very large and diverse so this is always going to be the case.  I have been working on the Packaging Guidelines since the beginning of Fedora and there are definitely types of packages that I *would* be a newbie at packaging.  There's no shame in this.

With this package, we're running across some things that you might not have dealt with before. What is a bundled library?  How do I deal with them?  What changes to the upstream code do I have to make to fix those?  Some of those answers are on the http://fedoraproject.org/wiki/Packaging:Treatment_Of_Bundled_Libraries page that has already been linked.  Others are expected to be general knowledge by people who are doing packaging.  Still others require someone to learn the programming language the upstream is written in, become involved with the upstream communities, and submit patches to them to fix issues.

These are big commitments of time and effort.  sgallagh has started investing that time.  Unless you are willing to put in that time and start examining the source code, figuring out what changes have been made, looking for ways to merge those patches upstream, and in general, becoming just as much a member of the upstream community as you are a member of the Fedora community, it would be extremely beneficial for you to do everything in your power to accommodate him. 

@mrunge - In Fedora, we give people the opportunity to succeed or fail and more importantly, the opportunity to learn while they are failing and then correct their mistakes.  We cannot pay people with money for the work that they are willing to do.  Instead we "pay" them by teaching them to be better packagers and helping them to achieve things that they could not do on their own.  In some cases, like this, it may well be faster and more efficient to do the work yourself than to have to teach another person as you're doing that work.  But if we don't take the time to teach we'll gradually marginalize people outside of our "inner circle" and then Fedora will shrink and die.

For those interested, I've opened a review request for the Node.JS dependency libuv: https://bugzilla.redhat.com/show_bug.cgi?id=874689

This review request is from a git snapshot of the latest upstream sources including support for building libuv as a shared library. I will be submitting patches upstream shortly for Node.JS 0.9.3 to support linking with this version of libuv.

I've spent the last couple weeks working with upstream to complete the unbundling process. I can now present to the world a copy of Node.js built entirely against system libraries!

Spec: http://sgallagh.fedorapeople.org/packagereview/nodejs/nodejs.spec
SRPM: http://sgallagh.fedorapeople.org/packagereview/nodejs/nodejs-0.9.3-3.fc18.src.rpm

Built in Koji for Rawhide: http://koji.fedoraproject.org/koji/taskinfo?taskID=4706430


Some notes: I'm not building npm in this tarball. It will be better to open a separate review for the upstream tarballs of npm located at https://github.com/isaacs/npm/tags. This tarball includes with it a number of modules and as such needs the care and feeding that a separate package provides.

Thus, this package contains only the node binary and the manpage for it, properly linked against system libraries.

I'm not an expert in Node.js development. I've only tested that this binary works with some simple tutorial examples I found at www.nodebeginner.org. I'm certainly open to comaintainers helping me out here.

This is great news. So Node.JS 0.10.x will be in the official repositories?

(In reply to comment #46)
> This is great news. So Node.JS 0.10.x will be in the official repositories?

Current released version is v0.8.15, according to http://nodejs.org/

Once this package has been reviewed it'll be pushed into fedoras official repositories. 

If 0.10.x will become part of Fedora's repositories (once, it's released), I'd say, it depends on the fact, if it's packable. 

Until (mainly) Stephens' work, all node.js versions were not permitted to be included into fedora for several reasons, mainly because of bundling libraries, which is strictly prohibited in fedora.

(In reply to comment #45)
> I've spent the last couple weeks working with upstream to complete the
> unbundling process. I can now present to the world a copy of Node.js built
> entirely against system libraries!
> 
> Spec: http://sgallagh.fedorapeople.org/packagereview/nodejs/nodejs.spec
> SRPM:
> http://sgallagh.fedorapeople.org/packagereview/nodejs/nodejs-0.9.3-3.fc18.
> src.rpm
> 
> Built in Koji for Rawhide:
> http://koji.fedoraproject.org/koji/taskinfo?taskID=4706430

Awesome!  The only remaining issue with this packaging I see is the /usr/bin/node conflict with the node package.

> Some notes: I'm not building npm in this tarball. It will be better to open
> a separate review for the upstream tarballs of npm located at
> https://github.com/isaacs/npm/tags. This tarball includes with it a number
> of modules and as such needs the care and feeding that a separate package
> provides.

Those modules should actually be packaged separately.  I'll revive my old npm reviews and create new ones for the newly required modules soon.

> Thus, this package contains only the node binary and the manpage for it,
> properly linked against system libraries.
> 
> I'm not an expert in Node.js development. I've only tested that this binary
> works with some simple tutorial examples I found at www.nodebeginner.org.
> I'm certainly open to comaintainers helping me out here.

I have a general sense of how node software should be shipped in an RPM world and already have automatic RPM dependency generation sorted out.  I'll work on draft packaging guidelines for node packages and submit them to FPC.  I'll also fix up the necessary RPM magic and macros and provide a patch to the new packaging to include them.

(P.S.  I presently maintain http-parser and am working to update the ancient version to the latest and greatest.  Please feel free to request ACLS in pkgdb if you want/need them.)

(In reply to comment #48)
> Awesome!  The only remaining issue with this packaging I see is the
> /usr/bin/node conflict with the node package.

[mrunge@turing ~]$ rpm -qlp node-0.3.2-8.fc15.x86_64.rpm 
/etc/ax25/node.conf
....
/usr/sbin/node
/usr/sbin/nodeusers
....

The node package puts shared data under /usr/share/ax25... so, I don't see a file conflict there, but:

/usr/share/man/man5/node.conf.5.gz
/usr/share/man/man5/node.perms.5.gz
/usr/share/man/man8/node.8.gz

I guess, that's solvable. Current nodejs package has it's man page in man1:
[mrunge@turing ~]$ rpm -ql nodejs
/usr/bin/node
/usr/share/man/man1/node.1.gz

No conflict here, right?

Originally I was considering arguing for allowing Node.js to take over the /usr/bin/node name, since it has a much higher user base than the amateur radio package. However, after looking into other distribution packages, it's become clear that they have all standardized on the 'nodejs' rename. So to remain consistent, I've patched the RPM build to generate output as 'nodejs' instead.

I've also corrected the dependency requirement on http-parser, which needs to be 2.0+.

Spec: http://sgallagh.fedorapeople.org/packagereview/nodejs/nodejs.spec
SRPM: http://sgallagh.fedorapeople.org/packagereview/nodejs/nodejs-0.9.3-4.fc18.src.rpm

Built in Koji for Rawhide: http://koji.fedoraproject.org/koji/taskinfo?taskID=4737762



T.C., thank you for the information about the NPM stuff. I'm also wondering if you would be interested in being a comaintainer on the nodejs package. You seem to have a lot of knowledge on the subject.

Right now my work on the npm packaging is stalled because we need to have the license evaluated. NPM uses a modified MIT license and it's not on the list of acceptable licenses for Fedora. (Nor is it on the unacceptable list) so I'm having the lawyers take a look at it. I'll let you know what they decide on.

(In reply to comment #50)
> Originally I was considering arguing for allowing Node.js to take over the
> /usr/bin/node name, since it has a much higher user base than the amateur
> radio package. However, after looking into other distribution packages, it's
> become clear that they have all standardized on the 'nodejs' rename. So to
> remain consistent, I've patched the RPM build to generate output as 'nodejs'
> instead.

The only issue with this is that a lot of node software uses '#!/usr/bin/env node' and has to be manually patched ATM.  But, now that other distros have the same problem perhaps npm could be patched to mangle shebang lines for stuff that goes in /usr/bin in a general way that's useful to everyone. 

> I've also corrected the dependency requirement on http-parser, which needs
> to be 2.0+.

I finally got an http-parser that passes all tests into updates-testing the other day so that should be ready to go.
 
> T.C., thank you for the information about the NPM stuff. I'm also wondering
> if you would be interested in being a comaintainer on the nodejs package.
> You seem to have a lot of knowledge on the subject.

Sure.  I requested ACLs on libuv too, just in case.

> Right now my work on the npm packaging is stalled because we need to have
> the license evaluated. NPM uses a modified MIT license and it's not on the
> list of acceptable licenses for Fedora. (Nor is it on the unacceptable list)
> so I'm having the lawyers take a look at it. I'll let you know what they
> decide on.

I'll still work on it in the interim.  (Vim has a a similar requirement to the additional requirement in npm's license so I doubt they'll have an issue with it.)

I realized I should probably update this bug with the latest developments. I had a long discussion with upstream regarding the /usr/bin/node name (or rename) and we finally came to the conclusion that renaming to /usr/bin/nodejs would actually cause a significant number of issues with a lot of scripts out in the wild.

I have been in contact with the group owning the ham-radio package 'node' and I am attempting to convince them to rename in Fedora instead, given the relative sizes of their communities. If they do not agree, I think I'm going to take the formal Conflicts: route as described by http://fedoraproject.org/wiki/Packaging:Conflicts#Incompatible_Binary_Files_with_Conflicting_Naming_.28and_stubborn_upstreams.29

tl;dr version of the above: We're going to stick with the /usr/bin/node name for this package.



T.C., I approved your request for libuv comaintainership, and thank you!

As far as the npm stuff, I have yet to receive a formal answer from legal, but the tentative answer I got was this: It's probably a valid free license, but it is NOT GPL-compatible, so we have to watch out for that. They're going to come up with a formal name for the license and add it to https://fedoraproject.org/wiki/Licensing:Main


Also, upstream Node.js is going to be releasing 0.9.4 shortly which has upstreamed all of the shared-library patches in my package, so I'll submit another build for this then (just to simplify things).

(In reply to comment #52)
> 
> I have been in contact with the group owning the ham-radio package 'node'
> and I am attempting to convince them to rename in Fedora instead, given the
> relative sizes of their communities. If they do not agree, I think I'm going
> to take the formal Conflicts: route as described by
> http://fedoraproject.org/wiki/Packaging:
> Conflicts#Incompatible_Binary_Files_with_Conflicting_Naming_.
> 28and_stubborn_upstreams.29
> 
Unfortunately, that doesn't work in this situation because it doesn't satisfy the "as long as there are no clear cases for both packages to be installed simultaneously" requirement.  I can't remember the exact example that prompted that wording but here's a contrived example: "Fedora has a package for udev.  I want to package udev2 which is a forked version.  No Fedora system is going to have two udev stacks installed simultaneously, so it's okay for the two packages to Conflict."

It would seem that these conflicting names falls under: http://fedoraproject.org/wiki/Packaging:Conflicts#Approaching_Upstream

"If neither upstream renames, we would then approach other distributions [...] about renaming that can be done in all distros. [...] Once a decision is made, we would rename the Fedora packages to match."

Since it seems you've looked at other distros and they've settled on renaming to nodejs, that's probably what we'd want to do in Fedora as well.  it might even be better to do that even if the amateur radio package were willing to give up its claim to the name if all other Linux distros are performing the rename already.

How about a compat package?

nodejs would provide /usr/bin/nodejs to match all the other distros. It wouldn't conflict with ham-radio.

compat-nodejs or something could provide a symlink from /usr/bin/nodejs -> /usr/bin/node and conflict with the ham-radio package to help with transitioning older scripts that havent cought up with the distros?

Well, the problem is that the other distributions have split completely down the middle on the issue. Ubuntu was until recently shipping /usr/bin/node, but they switched to /usr/bin/nodejs... and have been suffering serious breakage because of it. Nowadays, nearly all Ubuntu users of Node.js rely on a PPA that provides /usr/bin/node again.

Furthermore, when I approached upstream, they are actively hostile to the renaming and have asserted that they will not make any effort whatsoever to support any issues caused by it. So it's really against our interests to use /usr/bin/nodejs.

I'm still hopeful that the 'node' amateur radio team will agree to rename. They seemed fairly receptive to the idea (please pardon the pun).

<nod>  If distros aren't all on board with renaming and the amateur radio team is amenable to renaming their package/binaries then that will work out fine.

If not, then we'll need to look into renaming something despite hostility from upstream.  We can't please both upstreams in that case :-(

For reference, here's how Debian solved it:

lists.debian.org/debian-devel-announce/2012/07/msg00002.html

Both sides have good reasons for not wanting to rename now. Debian concluded neither side will agree and put steps into place to resolve it fairly by renaming both. I'd suggest doing something very similar.

The entire npm stack appears to be permissively licensed (it contains 2 and 3-clause BSD, MIT, WTFPL, and Apache 2 licensed software), so GPL incompatibility shouldn't be an issue.  The node community in general is rather hostile to copyleft, so I don't think anything else will give us problems.

Unless, of course, GPL software can't even be *distributed* using npm, but that seems ridiculous.

Quick update: the 'node' package has agreed to rename their '/usr/bin/node' binary and manpages. So we'll be good to run with it here.

T.C.: I'm not a lawyer, so I'll leave that to them :)

This is the response I got back from the legal department (better than I had hoped, too):


This is Free and GPL-Compatible. Use:
License: MITNFA


This license has now been added to https://fedoraproject.org/wiki/Licensing:Main

So we're good to go on NPM when this package is finished. I'm just waiting on the 'node' package to complete its rename and the release of Node.js 0.9.4 upstream (which should happen today or tomorrow according to bnoordhuis)

Wouldn't it be the right time to create a feature for F19 for nodejs and npm integration ( let's say that and a few library ? )

I've got a couple ideas for some software to package to make an awesome Node.js Feature for Fedora (i.e. cloud9).  But I'm not sure if we should go crazy advertising this until 0.9.x goes stable.

(In reply to comment #62)
> I've got a couple ideas for some software to package to make an awesome
> Node.js Feature for Fedora (i.e. cloud9).  But I'm not sure if we should go
> crazy advertising this until 0.9.x goes stable.
Hi, 
For me is: when we have one 0.8 ? to install , I work here with 0.6 , I know that is exciting the 0.9 but we (in my opinion) should focus in stable, for now, IMHO.

Yes, we definitely want to get Node.js listed as a feature. I'll work on that next week.

Sergio: Node.js 0.6 and 0.8 will never (and *can* never) appear officially in Fedora. While they called it "stable" upstream, they are built in such a way that can never be packaged in Fedora. 0.9.x made SIGNIFICANT changes under the hood to make it possible to use Node.js with shared libraries instead of bundled libraries. This is the only way it can be accepted into Fedora.

As such, we will be including the 0.9.x development series in Rawhide which should hopefully be declared 1.0.0 in time for Fedora 19's release. (Last time I spoke to upstream, their plan was for this dev branch to become 1.0.x, not 0.10.x)

Right now, 0.9.4 upstream is on a day-to-day slip. It should land any time now (they expected to land it a few days ago). I'll finish this package as soon as it appears.

Given that we have an agreement from the other node package to do their rename, can I get a temporary exception to approve this package with the file-level conflict, knowing that the proper resolution is coming? Or else I can temporarily add the Conflicts: explicitly and remove it once the rename lands.

I'd prefer not to wait any longer to land this, as there are multiple other packages awaiting this one to get in (such as lessjss and ReviewBoard's 1.7 upgrade, which is fairly important because ReviewBoard 1.6 can't run on F18 or F19 due to the newer Django).

Ok, so I'm going to opt for landing 0.9.3 for the moment (as 0.9.4 looks like it may slip until I'm on vacation).

I spoke with Toshio earlier today and we discussed that for reasons of expediency we could bend the conflict rules and I could submit the package for review with an explicit Conflicts: line until the other package fixes it. To that end, I've added a versioned Conflicts: to this version of the package so that it will automatically go away (or force an update of the 'node' package) once they put in their rebuild.

As discussed above, this version of the package reverts back to the default '/usr/bin/node' naming.

Spec: http://sgallagh.fedorapeople.org/packagereview/nodejs/nodejs.spec
SRPM: http://sgallagh.fedorapeople.org/packagereview/nodejs/nodejs-0.9.3-5.fc18.src.rpm
Koji: http://koji.fedoraproject.org/koji/taskinfo?taskID=4787262

So with all this in mind, please review this with the expectation that we're ready to land it!

Some additions:
I'd also like to see node.js in EPEL6

Running rpmlint, I've found a few issues:
nodejs.x86_64: E: non-standard-executable-perm /usr/bin/node 0775L
nodejs-debuginfo.x86_64: E: debuginfo-without-sources
nodejs.src:90: E: hardcoded-library-path in %{_prefix}/lib/dtrace

and licensecheck finds a few different licenses:
Apache (v2.0)
-------------
/var/lib/mock/fedora-rawhide-x86_64/root/builddir/build/BUILD/node-v0.9.3/tools/closure_linter/closure_linter/javascriptstatetracker.py

Unknown or generated
--------------------
/var/lib/mock/fedora-rawhide-x86_64/root/builddir/build/BUILD/node-v0.9.3/tools/osx-productsign.sh

MIT/X11 (BSD like)
------------------
/var/lib/mock/fedora-rawhide-x86_64/root/builddir/build/BUILD/node-v0.9.3/src/slab_allocator.h

BSD (3 clause)
--------------
/var/lib/mock/fedora-rawhide-x86_64/root/builddir/build/BUILD/node-v0.9.3/tools/js2c.py

ISC
---
/var/lib/mock/fedora-rawhide-x86_64/root/builddir/build/BUILD/node-v0.9.3/test/gc/node_modules/weak/src/weakref.cc

BSD (2 clause)
--------------
/var/lib/mock/fedora-rawhide-x86_64/root/builddir/build/BUILD/node-v0.9.3/deps/v8/src/arm/assembler-arm.cc

The latter one can be ignored, IMHO, because we're using our own v8 (and during prep deps/v8 is also cleared out).

(In reply to comment #66)
> Some additions:
> I'd also like to see node.js in EPEL6
> 

So would I, but it's not going to happen. Node.js requires much newer dependencies than we have in EPEL 6. Specifically, we need openssl 1.0.1 or later as well as http_parser 2.0 or later. OpenSSL is a full-stop problem, since that's carried in the core RHEL 6 and there's no way that Red Hat is going to rebase that one. We can try to make requests that they backport the SPDY patches to OpenSSL 1.0.0, but I don't know how successful we would be there.

> Running rpmlint, I've found a few issues:
> nodejs.x86_64: E: non-standard-executable-perm /usr/bin/node 0775L

That's strange. I don't see that when running rpmlint 1.4 on Fedora 18. I checked it against a local build and the one from Koji. Where did you see that?

Regardless, I'm explicitly setting it to 0755 now to be safe.

> nodejs-debuginfo.x86_64: E: debuginfo-without-sources


Oof, this was a bit of a pain in the neck. They have build scripts to build either debug builds with no optimization, or fully optimized builds with no symbols. I've added a patch to deal with this.

> nodejs.src:90: E: hardcoded-library-path in %{_prefix}/lib/dtrace
> 

This is a false-positive. It's intentionally hardcoded in order to ensure that we clear out the one generated (inappropriately) during the build. It's always guaranteed to be in %{prefix}/lib (not %{_libdir}).

> and licensecheck finds a few different licenses:
> Apache (v2.0)
> -------------
> /var/lib/mock/fedora-rawhide-x86_64/root/builddir/build/BUILD/node-v0.9.3/
> tools/closure_linter/closure_linter/javascriptstatetracker.py
> 
> Unknown or generated
> --------------------
> /var/lib/mock/fedora-rawhide-x86_64/root/builddir/build/BUILD/node-v0.9.3/
> tools/osx-productsign.sh
> 
> MIT/X11 (BSD like)
> ------------------
> /var/lib/mock/fedora-rawhide-x86_64/root/builddir/build/BUILD/node-v0.9.3/
> src/slab_allocator.h
> 
> BSD (3 clause)
> --------------
> /var/lib/mock/fedora-rawhide-x86_64/root/builddir/build/BUILD/node-v0.9.3/
> tools/js2c.py
> 
> ISC
> ---
> /var/lib/mock/fedora-rawhide-x86_64/root/builddir/build/BUILD/node-v0.9.3/
> test/gc/node_modules/weak/src/weakref.cc
> 
> BSD (2 clause)
> --------------
> /var/lib/mock/fedora-rawhide-x86_64/root/builddir/build/BUILD/node-v0.9.3/
> deps/v8/src/arm/assembler-arm.cc
> 
> The latter one can be ignored, IMHO, because we're using our own v8 (and
> during prep deps/v8 is also cleared out).

Thanks, I've added all of these. The OSX productsign one I'm assuming is covered under the Node MIT license (and it's not used when building on Linux either). According to the license guidelines, both BSD licenses fall under the "BSD" shortname, so they're both covered.


SPEC: http://sgallagh.fedorapeople.org/packagereview/nodejs/nodejs.spec
SRPM: http://sgallagh.fedorapeople.org/packagereview/nodejs/nodejs-0.9.3-6.fc18.src.rpm
Koji: http://koji.fedoraproject.org/koji/taskinfo?taskID=4790864


Matthias, if you're doing the review, would you mind self-assigning and setting fedora-review?

(In reply to comment #67)
> (In reply to comment #66)
> > Some additions:
> > I'd also like to see node.js in EPEL6
> > 
> 
> So would I, but it's not going to happen. Node.js requires much newer
> dependencies than we have in EPEL 6. Specifically, we need openssl 1.0.1 or
> later as well as http_parser 2.0 or later. OpenSSL is a full-stop problem,
> since that's carried in the core RHEL 6 and there's no way that Red Hat is
> going to rebase that one. We can try to make requests that they backport the
> SPDY patches to OpenSSL 1.0.0, but I don't know how successful we would be
> there.
> 

It would be a real shame not to ever support EPEL6.

Alternately, would it be easier/possible to patch out the SPDY support out of node.js for EPEL6 if that's the only hangup there? I'd be much happier using a slightly less feature-full node.js in production on RHEL6 then I would needing to run an extra Fedora box for a feature I probably won't use.

<SNIP>

+1

what about openssl101.rpm way?

like support for older openssl via openssl098e.rpm in RHEL6

(In reply to comment #68)
> 
> It would be a real shame not to ever support EPEL6.
> 
> Alternately, would it be easier/possible to patch out the SPDY support out
> of node.js for EPEL6 if that's the only hangup there? I'd be much happier
> using a slightly less feature-full node.js in production on RHEL6 then I
> would needing to run an extra Fedora box for a feature I probably won't use.
> 
> <SNIP>
Please be patient, guys. Let's finish this first and then look to other options.

In the meantime, I'll do the review to get node.js into Fedora.

Package Review
==============

Key:
[x] = Pass
[!] = Fail
[-] = Not applicable
[?] = Not evaluated
[ ] = Manual review needed


Issues:
=======
[!]: Package does not generate any conflict.
     Note: Package contains Conflicts: tag(s) needing fix or justification.
See: http://fedoraproject.org/wiki/Packaging/Guidelines#Conflicts
[!]: All build dependencies are listed in BuildRequires, except for any that
     are listed in the exceptions section of Packaging Guidelines.
     Note: These BR are not needed: findutils
See: http://fedoraproject.org/wiki/Packaging/Guidelines#Exceptions_2
[!]: Package consistently uses macro is (instead of hard-coded directory
     names).
     Note: Using both %{buildroot} and $RPM_BUILD_ROOT
See: http://fedoraproject.org/wiki/Packaging/Guidelines#macros


===== MUST items =====

C/C++:
[x]: Header files in -devel subpackage, if present.
[x]: Package does not contain any libtool archives (.la)
[x]: Package does not contain kernel modules.
[x]: Package contains no static executables.
[x]: Rpath absent or only used for internal libs.

Generic:
[x]: Package is licensed with an open-source compatible license and meets
     other legal requirements as defined in the legal section of Packaging
     Guidelines.
[x]: Package successfully compiles and builds into binary rpms on at least one
     supported primary architecture.
[x]: %build honors applicable compiler flags or justifies otherwise.
[!]: All build dependencies are listed in BuildRequires, except for any that
     are listed in the exceptions section of Packaging Guidelines.
     Note: These BR are not needed: findutils
[x]: Package contains no bundled libraries.
[x]: Changelog in prescribed format.
[x]: Package does not run rm -rf %{buildroot} (or $RPM_BUILD_ROOT) at the
     beginning of %install.
     Note: rm -rf %{buildroot} present but not required
[x]: Sources contain only permissible code or content.
[x]: Each %files section contains %defattr if rpm < 4.4
[x]: Macros in Summary, %description expandable at SRPM build time.
[-]: Package contains desktop file if it is a GUI application.
[-]: Development files must be in a -devel package
[x]: Package requires other packages for directories it uses.
[x]: Package uses nothing in %doc for runtime.
[x]: Package is not known to require ExcludeArch.
[x]: Package does not contain duplicates in %files.
[x]: Permissions on files are set properly.
[x]: Package complies to the Packaging Guidelines
[x]: Spec file lacks Packager, Vendor, PreReq tags.
[x]: If (and only if) the source package includes the text of the license(s)
     in its own file, then that file, containing the text of the license(s)
     for the package is included in %doc.
[x]: License field in the package spec file matches the actual license.
     Note: Checking patched sources after %prep for licenses. Licenses found:
     "Apache (v2.0)", "Unknown or generated", "MIT/X11 (BSD like)", "BSD (3
     clause)", "ISC", "BSD (2 clause)". 6 files have unknown license. Detailed
     output of licensecheck in
     /home/mrunge/review/815018-nodejs/licensecheck.txt
[!]: Package consistently uses macro is (instead of hard-coded directory
     names).
     Note: Using both %{buildroot} and $RPM_BUILD_ROOT
[!]: If the package is under multiple licenses, the licensing breakdown must
     be documented in the spec.
[x]: Package is named using only allowed ASCII characters.
[x]: Package is named according to the Package Naming Guidelines.
[!]: Package does not generate any conflict.
     Note: Package contains Conflicts: tag(s) needing fix or justification.
[x]: Package do not use a name that already exist
[x]: Package obeys FHS, except libexecdir and /usr/target.
[-]: If the package is a rename of another package, proper Obsoletes and
     Provides are present.
[x]: Package must own all directories that it creates.
[x]: Package does not own files or directories owned by other packages.
[x]: Package installs properly.
[x]: Package is not relocatable.
[x]: Requires correct, justified where necessary.
[x]: CheckResultdir
[x]: Rpmlint is run on all rpms the build produces.
     Note: There are rpmlint messages (see attachment).
[x]: Sources used to build the package match the upstream source, as provided
     in the spec URL.
[x]: Spec file is legible and written in American English.
[x]: Spec file name must match the spec package %{name}, in the format
     %{name}.spec.
[-]: Package contains systemd file(s) if in need.
[x]: File names are valid UTF-8.
[x]: Useful -debuginfo package or justification otherwise.
[x]: Large documentation must go in a -doc subpackage.
     Note: Documentation size is 153600 bytes in 4 files.
[x]: Packages must not store files under /srv, /opt or /usr/local

===== SHOULD items =====

Generic:
[x]: Reviewer should test that the package builds in mock.
[x]: Buildroot is not present
[!]: Package has no %clean section with rm -rf %{buildroot} (or
     $RPM_BUILD_ROOT)
     Note: %clean present but not required
[x]: If the source package does not include license text(s) as a separate file
     from upstream, the packager SHOULD query upstream to include it.
[x]: Dist tag is present.
[x]: No file requires outside of /etc, /bin, /sbin, /usr/bin, /usr/sbin.
[x]: Final provides and requires are sane (rpm -q --provides and rpm -q
     --requires).
[x]: Package functions as described.
[x]: Latest version is packaged.
[x]: Package does not include license text files separate from upstream.
[x]: Patches link to upstream bugs/comments/lists or are otherwise justified.
[x]: The placement of pkgconfig(.pc) files are correct.
[x]: SourceX tarball generation or download is documented.
[!]: SourceX / PatchY prefixed with %{name}.
     Note: Patch1 (0001-build-allow-linking-against-system-http_parser.patch)
     Source0 (node-v0.9.3.tar.gz) Patch3 (0003-build-allow-linking-against-
     system-libuv.patch) Patch4 (0004-Build-debugging-symbols-by-
     default.patch) Patch2 (0002-build-allow-linking-against-
     system-c-ares.patch)
[x]: SourceX is a working URL.
[-]: Description and summary sections in the package spec file contains
     translations for supported Non-English languages, if available.
[x]: Package should compile and build into binary rpms on all supported
     architectures.
[-]: %check is present and all tests pass.
[x]: Packages should try to preserve timestamps of original installed files.
[x]: Spec use %global instead of %define.

===== EXTRA items =====

Generic:
[x]: Rpmlint is run on all installed packages.
     Note: There are rpmlint messages (see attachment).
[x]: Spec file according to URL is the same as in SRPM.
[x]: Large data in /usr/share should live in a noarch subpackage if package is
     arched.


Rpmlint
-------
Checking: nodejs-debuginfo-0.9.3-6.fc19.x86_64.rpm
          nodejs-0.9.3-6.fc19.x86_64.rpm
          nodejs-0.9.3-6.fc19.src.rpm
nodejs.x86_64: W: spelling-error Summary(en_US) runtime -> run time, run-time, rudiment
nodejs.x86_64: W: spelling-error %description -l en_US js -> dis, ks, j
nodejs.x86_64: W: spelling-error %description -l en_US runtime -> run time, run-time, rudiment
nodejs.x86_64: W: spelling-error %description -l en_US scalable -> salable, callable, calculable
nodejs.src: W: spelling-error Summary(en_US) runtime -> run time, run-time, rudiment
nodejs.src: W: spelling-error %description -l en_US js -> dis, ks, j
nodejs.src: W: spelling-error %description -l en_US runtime -> run time, run-time, rudiment
nodejs.src: W: spelling-error %description -l en_US scalable -> salable, callable, calculable
nodejs.src:77: W: configure-without-libdir-spec
nodejs.src:95: E: hardcoded-library-path in %{_prefix}/lib/dtrace
3 packages and 0 specfiles checked; 1 errors, 9 warnings.


The libdir warning can be ingnored. configure used here is a custom one.

That error can be safely ignored, build process creates %{_prefix}/lib/dtrace, which is being removed. The removal was detected.




Rpmlint (installed packages)
----------------------------
# rpmlint nodejs nodejs-debuginfo
nodejs.x86_64: W: spelling-error Summary(en_US) runtime -> run time, run-time, rudiment
nodejs.x86_64: W: spelling-error %description -l en_US js -> dis, ks, j
nodejs.x86_64: W: spelling-error %description -l en_US runtime -> run time, run-time, rudiment
nodejs.x86_64: W: spelling-error %description -l en_US scalable -> salable, callable, calculable
2 packages and 0 specfiles checked; 0 errors, 4 warnings.
# echo 'rpmlint-done:'



Requires
--------
nodejs-debuginfo-0.9.3-6.fc19.x86_64.rpm (rpmlib, GLIBC filtered):
    

nodejs-0.9.3-6.fc19.x86_64.rpm (rpmlib, GLIBC filtered):
    
    libc.so.6()(64bit)
    libcares.so.2()(64bit)
    libcrypto.so.10()(64bit)
    libcrypto.so.10(libcrypto.so.10)(64bit)
    libgcc_s.so.1()(64bit)
    libhttp_parser.so.2()(64bit)
    libm.so.6()(64bit)
    libpthread.so.0()(64bit)
    libssl.so.10()(64bit)
    libssl.so.10(libssl.so.10)(64bit)
    libstdc++.so.6()(64bit)
    libstdc++.so.6(CXXABI_1.3)(64bit)
    libuv.so.0.9.3()(64bit)
    libv8.so.3()(64bit)
    libz.so.1()(64bit)
    rtld(GNU_HASH)



Provides
--------
nodejs-debuginfo-0.9.3-6.fc19.x86_64.rpm:
    
    nodejs-debuginfo = 0.9.3-6.fc19
    nodejs-debuginfo(x86-64) = 0.9.3-6.fc19

nodejs-0.9.3-6.fc19.x86_64.rpm:
    
    nodejs = 0.9.3-6.fc19
    nodejs(x86-64) = 0.9.3-6.fc19



MD5-sum check
-------------
http://nodejs.org/dist/v0.9.3/node-v0.9.3.tar.gz :
  CHECKSUM(SHA256) this package     : 7e1750cd47d7b8c13c7cf12457b6a528fa2abf8a10b7c9a35c13ed47cebaab41
  CHECKSUM(SHA256) upstream package : 7e1750cd47d7b8c13c7cf12457b6a528fa2abf8a10b7c9a35c13ed47cebaab41


Generated by fedora-review 0.3.1 (b71abc1) last change: 2012-10-16
Buildroot used: fedora-rawhide-x86_64
Command line :/usr/bin/fedora-review -b 815018




- You may remove findutils from BuildRequirements:
https://fedoraproject.org/wiki/Packaging:Guidelines?rd=Packaging/Guidelines#Exceptions_2
- Also you could remove the %clean: section. That also fixes the issue of mixing macros $RPM_BUILD_ROOT and %{buildroot}

Both are minors IMHO and can be fixed during import.

Package approved

Awesome job dudes!

New Package SCM Request
=======================
Package Name: nodejs
Short Description: JavaScript fast build framework
Owners: sgallagh mrunge patches
Branches: f18 el6
InitialCC:

Git done (by process-git-requests).

Built for Rawhide: http://koji.fedoraproject.org/koji/buildinfo?buildID=373436

nodejs-0.9.3-7.fc18,libuv-0.9.3-0.3.git09b0222.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/nodejs-0.9.3-7.fc18,libuv-0.9.3-0.3.git09b0222.fc18

Hi, 
Any particular reason to not build in F17 ? 

Thanks,

Amazing!

This should be marketed!

Fedora has better support for Web development than competing distributions, and this is not very well known. I'm not just referring to node.js, I also like the up-to-date kernels, nginx, Rails 3.2.

I hope this helps.

(In reply to comment #78)
> Amazing!
> 
> This should be marketed!

I just realized that I also think so. This is a huge step forward and worths mentioning in the marketing docs / release info.

I'm actually planning to put together a Fedora 19 Feature Page for this, which I suppose I should do now so I don't forget. That will ensure that it shows up in the release notes.

We still need to package npm to make Node.js fully useful for development, which I'm going to look into with T.C. Hollingsworth as per comment #48

npm review is in bug 891171.  python-bugzilla is chugging along filing reviews for all it's dependencies, which will block that bug.

(In reply to comment #77)
> Any particular reason to not build in F17 ? 

+1
Could we please have F17 too?

And maybe even for F16 - though close to EOL now.

(In reply to comment #82)
> (In reply to comment #77)
> > Any particular reason to not build in F17 ? 
> 
> +1
> Could we please have F17 too?
> 
> And maybe even for F16 - though close to EOL now.

Around comment #30 I got some dependencies of packages that doesn't exist on F17.

I read somewhere in this report , for have nodejs in F17 we need drop some features ....

v8-3.14.5.8-1.fc18, nodejs-0.10.2-1.fc18, libuv-0.10.3-1.fc18 has been pushed to the Fedora 18 stable repository.  If problems still persist, please make note of it in this bug report.

nodejs-0.10.3-2.el6.1,libuv-0.10.3-2.el6,http-parser-2.0-4.20121128gitcd01361.el6,c-ares19-1.9.1-4.el6.3 has been submitted as an update for Fedora EPEL 6.
https://admin.fedoraproject.org/updates/nodejs-0.10.3-2.el6.1,libuv-0.10.3-2.el6,http-parser-2.0-4.20121128gitcd01361.el6,c-ares19-1.9.1-4.el6.3

libuv-0.10.4-1.el6, nodejs-0.10.4-1.el6, http-parser-2.0-4.20121128gitcd01361.el6, c-ares19-1.9.1-4.el6.3 has been pushed to the Fedora EPEL 6 stable repository.