Hi Stephen,

Thanks for the fast response time.  I did end up pulling the SRPM from the latest build on Kodi [1], but before that I was also trying to use Mock SCM.  There's apparently an issue going on with that [2] at the moment -- would that eventually be the preferred way, since it can pull straight from a git repo?

When building Node for Fedora 23 I think I encountered the error you were alluding to with `libuv` [3]:

```
../src/node_os.cc: In function 'void node::os::GetHomeDirectory(const v8::FunctionCallbackInfo<v8::Value>&)':
../src/node_os.cc:279:42: error: 'uv_os_homedir' was not declared in this scope
   const int err = uv_os_homedir(buf, &len);
                                          ^
../src/node_os.cc:282:54: error: return-statement with a value, in function returning 'void' [-fpermissive]
     return env->ThrowUVException(err, "uv_os_homedir");
                                                      ^
node.target.mk:143: recipe for target '/builddir/build/BUILD/node-v4.4.3/out/Debug/obj.target/node/src/node_os.o' failed
```
Would I need to update the nodejs.spec file for Fedora 23 to reflect a newer version, or different version in order to get around that?

[1] https://copr.fedorainfracloud.org/coprs/voor/nodejs-lts/build/182807/
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1312820
[3] https://copr-be.cloud.fedoraproject.org/results/voor/nodejs-lts/fedora-23-x86_64/00182807-nodejs/build.log.gz



On Mon, May 2, 2016 at 1:37 PM Stephen Gallagher <sgallagh@redhat.com> wrote:
On 05/02/2016 12:43 PM, Robert Van Voorhees wrote:
> Hey guys,
>
> Long time lurker, who wants to try and get more involved with Stephen's shifting
> responsibilities.  Is there a "getting started" or "hey new guy don't E-mail the
> mailing list" approach to contributing to this?  I've heard Stephen refer to a
> COPR every now and then -- I'm aware of the COPR at [1] which I forked into my
> own COPR, and then also the wiki [2] with basic information on actually using
> Node.JS in Fedora.  The packaging Node.JS page [3] looks severely outdated,
> since we are now no longer attempting to RPM package each individual NPM
> dependency and instead using that built in process?  (That was a question)
>

Why do you think it's outdated? We have a single special case for the embedded
npm in nodejs because it was necessary to enable us to move quickly when nodejs
updates land. (npm keeps getting random additional dependencies all the time and
trying to maintain its monstrous chain separately to get a nodejs security fix
out the door was proving impossible).

Other Node.js modules should absolutely continue to follow those packaging
guidelines.


> The other part I'm confused on is that the COPR shows the build was triggered by
> a SRPM that was uploaded [4], but then also refers to a git repository at [5]
>

That git repository is pretty much an internal implementation detail of COPR. As
it is, the existing COPR repositories are pretty out of date (they were
more-or-less abandoned once we landed the updated Node versions in F24 and Rawhide).

However, we should probably look at prepping the Node.js 6.x upgrade through
COPR before we push it to Rawhide, since we know that there are
backwards-compatibility issues.


> I wanted to "cut my teeth" on trying to configure the COPR to do a Fedora 23
> build, since I'm still on Fedora 23.  How would I go about doing that?  As I
> said I forked the COPR and activated Fedora 23 as an option, would I need to
> upload my own SRPM based on the git repository, or should I be setting it up to
> pull automagically from elsewhere?


I'm not aware of any reason Fedora 23 couldn't just pull in the SRPM of the
latest builds from Koji (since most of what it needs is bundled in). You'll
probably need to build `libuv` first, then try to build nodejs and see what happens.


>
> [1] https://copr.fedorainfracloud.org/groups/g/nodejs-sig/coprs/
> <https://copr.fedorainfracloud.org/groups/g/nodejs-sig/coprs/>
> [2] https://fedoraproject.org/wiki/Node.js
> [3] https://fedoraproject.org/wiki/Packaging:Node.js
> [4] https://copr.fedorainfracloud.org/coprs/g/nodejs-sig/nodejs-lts/build/181534/
> [5] http://copr-dist-git.fedorainfracloud.org/cgit/@nodejs-sig/nodejs-lts/nodejs.git/
>


Also, there are many modules in Fedora that were added specifically to support
the 'npm' package which is now bundled with the nodejs package: We should
probably take an inventory of them and figure out which ones are worth
continuing to support as distribution packages (meaning they're valuable to
something else we want to distribute, like nodejs-less or Visual Studio Code,
etc.) or if we should continue retiring some of them so as not to need to
continue maintaining them.



>
>
> On Wed, Apr 27, 2016 at 8:38 AM Stephen Gallagher <sgallagh@redhat.com
> <mailto:sgallagh@redhat.com>> wrote:
>
>     On 04/27/2016 04:19 AM, Tom Hughes wrote:
>     > On 27/04/16 03:00, Stephen Gallagher wrote:
>     >
>     >> As for Option 1)? I think someone with more knowledge of the individual
>     modules
>     >> in Fedora (Tom Hughes? Jared Smith?) would need to figure out how many
>     modules
>     >> would be broken if we downgraded. If it's sufficiently small, I suppose
>     we could
>     >> epoch-bump nodejs and its virtual npm Provides: and go that route. I
>     don't love
>     >> that we will effectively been playing yo-yo with the version in F24, but it
>     >> would be a solution...
>     >
>     > Off the top of my head I'm not aware of anything that requires 5.x and for the
>     > most part I think people try to support at least 4.x and 5.x at the
>     moment, and
>     > often earlier versions as well.
>     >
>     > Tom
>     >
>
>     OK, I did some repoquery magic just now and came up with (unique-only):
>
>
>     nodejs(engine)
>     nodejs(engine) >= 0.1
>     nodejs(engine) >= 0.10
>     nodejs(engine) >= 0.10.0
>     nodejs(engine) >= 0.10.12
>     nodejs(engine) >= 0.10.15
>     nodejs(engine) >= 0.10.3
>     nodejs(engine) >= 0.10.36
>     nodejs(engine) >= 0.1.103
>     nodejs(engine) >= 0.12.0
>     nodejs(engine) >= 0.1.90
>     nodejs(engine) > 0.1.90
>     nodejs(engine) >= 0.2.0
>     nodejs(engine) >= 0.2.0-0
>     nodejs(engine) >= 0.2.4
>     nodejs(engine) >= 0.2.5
>     nodejs(engine) >= 0.3.0
>     nodejs(engine) >= 0.3.1
>     nodejs(engine) >= 0.3.6
>     nodejs(engine) >= 0.4
>     nodejs(engine) >= 0.4.
>     nodejs(engine) >= 0.4.0
>     nodejs(engine) >= 0.4.1
>     nodejs(engine) >= 0.4.2
>     nodejs(engine) >= 0.4.7
>     nodejs(engine) >= 0.4.9
>     nodejs(engine) >= 0.6
>     nodejs(engine) >= 0.6.0
>     nodejs(engine) >= 0.6.19
>     nodejs(engine) >= 0.6.3
>     nodejs(engine) >= 0.6.6
>     nodejs(engine) >= 0.8
>     nodejs(engine) >= 0.8.
>     nodejs(engine) >= 0.8.0
>     nodejs(engine) >= 0.8.19
>     nodejs(engine) >= 0.9.0
>     nodejs(engine) >= 4
>     nodejs(engine) >= 4.0.0
>
>
>
>     So according to this, we have nothing in the package collection that is known to
>     require only 5.x or later. So that's a point in favor of the 4.x downgrade
>     approach.
>
>     I don't love the idea of regressing the versions post-Beta, but it's starting to
>     look like the least-risky approach. We really have no idea what is going to be
>     broken by 6.0 and I don't want to stick some poor volunteer with maintaining
>     backports of a dead upstream release.
>
>     _______________________________________________
>     nodejs mailing list
>     nodejs@lists.fedoraproject.org <mailto:nodejs@lists.fedoraproject.org>
>     http://lists.fedoraproject.org/admin/lists/nodejs@lists.fedoraproject.org
>
>
>
> _______________________________________________
> nodejs mailing list
> nodejs@lists.fedoraproject.org
> http://lists.fedoraproject.org/admin/lists/nodejs@lists.fedoraproject.org
>


_______________________________________________
nodejs mailing list
nodejs@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/nodejs@lists.fedoraproject.org