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 <sgall...@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 <sgall...@redhat.com
> > <mailto:sgall...@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
>
_______________________________________________
nodejs mailing list
nodejs@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/nodejs@lists.fedoraproject.org
