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::FunctionCallbackInfov8::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-x8...
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...
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