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]
On Mon, May 2, 2016 at 1:37 PM Stephen Gallagher <sgallagh(a)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/181...
> [5]
http://copr-dist-git.fedorainfracloud.org/cgit/@nodejs-sig/nodejs-lts/nod...
>
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(a)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(a)lists.fedoraproject.org <mailto:
nodejs(a)lists.fedoraproject.org>
>
http://lists.fedoraproject.org/admin/lists/nodejs@lists.fedoraproject.org
>
>
>
> _______________________________________________
> nodejs mailing list
> nodejs(a)lists.fedoraproject.org
>
http://lists.fedoraproject.org/admin/lists/nodejs@lists.fedoraproject.org
>
_______________________________________________
nodejs mailing list
nodejs(a)lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/nodejs@lists.fedoraproject.org