1:07 p.m.
Hi Fedora noders!
If you're receiving this, you've done *something* related to Node at
some point. (And there's a lot of you, which is why you're all
Bcc'ed!) There's now a Node.js mailing list to make communicating
easier:
https://admin.fedoraproject.org/mailman/listinfo/nodejs
Please join us there if you're interested; this will be the last time
I mass mail anybody. If you don't care about node anymore, feel free
to skip the rest of this, otherwise read on..
In addition to the mailing list, I've also given node some wiki love.
There's now an overview page you can point all your friends to:
https://fedoraproject.org/wiki/Node.js
There's also a fancy SIG page. Add your name to it!
https://fedoraproject.org/wiki/SIGs/Node.js
While I got them off to a start, they definitely could use some more
love. Please edit away, it is a wiki after all!
Note that there's a link to a Packaging FAQ, but it currently
redirects to the guidelines. I'm going to be putting in a guidelines
update real soon now, taking into account all the changes thanks to
your wonderful suggestions. Part of that will be moving some stuff
out of the guidelines and into the FAQ, since FPC wants to get the
guidelines back to the basics. [1] So that page won't stay a redirect
long! If you have any suggestions in this area that we haven't
already discussed previously, please e-mail the list. Otherwise, I'll
send out the drafts there prior to sending them along to FPC to gather
feedback.
Additionally, there's now a tracking bug for Node.js reviews [2].
Please add "nodejs-reviews" to the Blocks field of all future
Node.js-related package reviews. npm2rpm will use it to skip packages
that are already awaiting review. Speaking of npm2rpm, I hope to have
that out for everyone next week, along with an additional script that
checks npm for updates and updates packages. Sorry it's taken so
long!
In case you missed it, Stephen Gallagher recently got Node.js working
on EPEL 6. (Thanks, Stephen!) The only thing extra you need to do
for EPEL is add %{?nodejs_find_provides_and_requires} to the top of
your spec file. This forces the older RPM in RHEL6 to invoke the
Node.js provides and requires generators, since it cannot be done
automatically like it is in Fedora. (This will also find it's way
into the EPEL guidelines in the aforementioned guidelines update.)
Finally, at this point in the Node.js 0.10.x release cycle, updates
are being released roughly every week, as more people migrate to the
new version and find all the bugs in it. Unfortunately, that means as
soon as bodhi lets me push 0.10.4, 0.10.5 is out! Please test new
versions, and visit bodhi and give them karma, so we're not pushing
stuff with already fixed bugs stable two days after the next version
is released. In about a month or so, releases should taper off and it
won't be such a problem anymore.
Thanks for all of your awesome work!
-T.C.
[1] https://lists.fedoraproject.org/pipermail/packaging/2013-March/008971.html
[2] https://bugzilla.redhat.com/show_bug.cgi?id=956806
4:34 a.m.
Quoting T.C. Hollingsworth (2013-04-25 20:07:21)
Hi Fedora noders!
If you're receiving this, you've done *something* related to Node at
some point. (And there's a lot of you, which is why you're all
Bcc'ed!) There's now a Node.js mailing list to make communicating
easier:
https://admin.fedoraproject.org/mailman/listinfo/nodejs
Heh, funnily enough just yesterday I was talking to thrcka about proposing some
mailing list to simplify coordination and communication
Note that there's a link to a Packaging FAQ, but it currently
redirects to the guidelines. I'm going to be putting in a guidelines
update real soon now, taking into account all the changes thanks to
your wonderful suggestions. Part of that will be moving some stuff
out of the guidelines and into the FAQ, since FPC wants to get the
guidelines back to the basics. [1]
Uhmm, that's was just my goal with Java guidelines since they have become
bloated over time :-) In any case I believe it's a good idea to separate policy
and common trips & tricks so +1 for this endeavor
Additionally, there's now a tracking bug for Node.js reviews
[2].
Please add "nodejs-reviews" to the Blocks field of all future
Node.js-related package reviews. npm2rpm will use it to skip packages
that are already awaiting review. Speaking of npm2rpm, I hope to have
that out for everyone next week, along with an additional script that
checks npm for updates and updates packages. Sorry it's taken so
long!
Great to hear, it will surely simplify and speed up common tasks. Automation is
the key :-)
[snip]
Finally, at this point in the Node.js 0.10.x release cycle, updates
are being released roughly every week, as more people migrate to the
new version and find all the bugs in it. Unfortunately, that means as
soon as bodhi lets me push 0.10.4, 0.10.5 is out! Please test new
versions, and visit bodhi and give them karma, so we're not pushing
stuff with already fixed bugs stable two days after the next version
is released. In about a month or so, releases should taper off and it
won't be such a problem anymore.
There's another thing which I mentioned to T.C., but I'll repeat it here in ML
as well. It would be nice if we split up packaging of rpm macros and various
helper scripts from nodejs package itself and create a separate project on
fedorahosted just for those scripts/tools. It will simplify improvements to
tooling and provide a common place where other distributions can perhaps share
some code. We have something similar set up for Java packaging[1] for a while and
it's been working great.
Last thing from me: in Java it became apparent only after a while...It might be good
idea to create a separate "nodejs-local" or similarly named package used for
RPM
builds. This would pull in macros and all dependencies needed to build RPMs.
Otherwise we'll possibly pollute user systems with rpm macros and additional
dependencies even though they are not interested in packaging RPMs, just using
node/npm.
[1] https://fedorahosted.org/javapackages/
--
Stanislav Ochotnicky <sochotnicky(a)redhat.com>
Software Engineer - Developer Experience
PGP: 7B087241
Red Hat Inc. http://cz.redhat.com
5:03 p.m.
Sorry, this went out to just Stanislav by accident. I'll recheck the
list settings; I thought I configured it so Reply-To gets set to the
list.
On Fri, Apr 26, 2013 at 2:34 AM, Stanislav Ochotnicky
<sochotnicky(a)redhat.com> wrote:
Quoting T.C. Hollingsworth (2013-04-25 20:07:21)
> Hi Fedora noders!
>
> If you're receiving this, you've done *something* related to Node at
> some point. (And there's a lot of you, which is why you're all
> Bcc'ed!) There's now a Node.js mailing list to make communicating
> easier:
> https://admin.fedoraproject.org/mailman/listinfo/nodejs
Heh, funnily enough just yesterday I was talking to thrcka about proposing some
mailing list to simplify coordination and communication
Get out of my brain! :-)
> Note that there's a link to a Packaging FAQ, but it
currently
> redirects to the guidelines. I'm going to be putting in a guidelines
> update real soon now, taking into account all the changes thanks to
> your wonderful suggestions. Part of that will be moving some stuff
> out of the guidelines and into the FAQ, since FPC wants to get the
> guidelines back to the basics. [1]
Uhmm, that's was just my goal with Java guidelines since they have become
bloated over time :-) In any case I believe it's a good idea to separate policy
and common trips & tricks so +1 for this endeavor
Well one member of FPC +1ed your idea at least, so it seemed worth it
to go that route since I need to update the guidelines anyway.
Yeah, this seems like a good idea. I wonder if npm2rpm and stuff like
that should live in this package, or in it's own?
Last thing from me: in Java it became apparent only after a
while...It might be good
idea to create a separate "nodejs-local" or similarly named package used for
RPM
builds. This would pull in macros and all dependencies needed to build RPMs.
Otherwise we'll possibly pollute user systems with rpm macros and additional
dependencies even though they are not interested in packaging RPMs, just using
node/npm.
I'm not sure this is necessary in node's case. The only thing RPM
builds need that normal node use doesn't require is the RPM macros,
which will end up in their own package eventually anyway.
-T.C.
2:02 a.m.
Quoting T.C. Hollingsworth (2013-04-27 00:03:21)
>> Note that there's a link to a Packaging FAQ, but it
currently
>> redirects to the guidelines. I'm going to be putting in a guidelines
>> update real soon now, taking into account all the changes thanks to
>> your wonderful suggestions. Part of that will be moving some stuff
>> out of the guidelines and into the FAQ, since FPC wants to get the
>> guidelines back to the basics. [1]
>
> Uhmm, that's was just my goal with Java guidelines since they have become
> bloated over time :-) In any case I believe it's a good idea to separate policy
> and common trips & tricks so +1 for this endeavor
Well one member of FPC +1ed your idea at least, so it seemed worth it
to go that route since I need to update the guidelines anyway.
Yeah, this seems like a good idea. I wonder if npm2rpm and stuff like
that should live in this package, or in it's own?
Advantage of having single project is that you won't have to approve commit
access several times :-) In Java we create single source tarball, but then
spec file splits this into several smaller binary RPMs.
I guess it depends on how much code sharing you envision could happen there.
> Last thing from me: in Java it became apparent only after a
while...It might be good
> idea to create a separate "nodejs-local" or similarly named package used
for RPM
> builds. This would pull in macros and all dependencies needed to build RPMs.
> Otherwise we'll possibly pollute user systems with rpm macros and additional
> dependencies even though they are not interested in packaging RPMs, just using
> node/npm.
I'm not sure this is necessary in node's case. The only thing RPM
builds need that normal node use doesn't require is the RPM macros,
which will end up in their own package eventually anyway.
Right, in Java those macros eventually started using Python/Perl and pulled in a
few more dependencies. Plus RPM builds in Maven differ quite a lot
dependency-wise from non-RPM so situation is indeed different. Something to keep
in mind for the future in case something changes.
--
Stanislav Ochotnicky <sochotnicky(a)redhat.com>
Software Engineer - Developer Experience
PGP: 7B087241
Red Hat Inc. http://cz.redhat.com
12:40 a.m.
On Mon, Apr 29, 2013 at 12:02 AM, Stanislav Ochotnicky
<sochotnicky(a)redhat.com> wrote:
Quoting T.C. Hollingsworth (2013-04-27 00:03:21)
> Yeah, this seems like a good idea. I wonder if npm2rpm and stuff like
> that should live in this package, or in it's own?
Advantage of having single project is that you won't have to approve commit
access several times :-) In Java we create single source tarball, but then
spec file splits this into several smaller binary RPMs.
True. We'd definitely want to split the binary RPMs if we did this
because npm2rpm will be much more dep heavy (it needs npm itself as
well as a templating library).
I guess it depends on how much code sharing you envision could happen
there.
None really. The current version uses the requires generator for
nodejs to write BuildRequires based on package.json devDependencies,
but I'm going to rip that out because the specific versioned
dependencies that results in are really overkill for BuildRequires in
Fedora packages.
> I'm not sure this is necessary in node's case. The only
thing RPM
> builds need that normal node use doesn't require is the RPM macros,
> which will end up in their own package eventually anyway.
Right, in Java those macros eventually started using Python/Perl and pulled in a
few more dependencies. Plus RPM builds in Maven differ quite a lot
dependency-wise from non-RPM so situation is indeed different. Something to keep
in mind for the future in case something changes.
Well we use Python, but I purposely stuck to the standard library
(well actually there wasn't really any reason not to ;-) and there
isn't a practical Fedora installation without a Python interpreter
thanks to yum and others, so I don't think that's a big deal.
Anyway, I'm going to go ahead and file a ticket for a nodejs-packaging
fedorahosted project to get the ball rolling on this.
-T.C.
6:50 a.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 05/02/2013 01:40 AM, T.C. Hollingsworth wrote:
On Mon, Apr 29, 2013 at 12:02 AM, Stanislav Ochotnicky
<sochotnicky(a)redhat.com> wrote:
> Quoting T.C. Hollingsworth (2013-04-27 00:03:21)
>> Yeah, this seems like a good idea. I wonder if npm2rpm and
>> stuff like that should live in this package, or in it's own?
>
> Advantage of having single project is that you won't have to
> approve commit access several times :-) In Java we create single
> source tarball, but then spec file splits this into several
> smaller binary RPMs.
True. We'd definitely want to split the binary RPMs if we did
this because npm2rpm will be much more dep heavy (it needs npm
itself as well as a templating library).
Please remember to consider the bootstrapping problem in the event of
future mass-rebuilds. If the nodejs package starts build-depending on
the npm package, that's a circular dependency that becomes very
difficult to maintain. (I've seen how they have to do it in GCC, and
it's not pretty).
I'd suggest that we might want to pull out the macro and npm2rpm stuff
as a separate SRPM, mainly just to avoid this problem. So I'm all for
the 'nodejs-packaging' project to be all-encompassing here.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlGCUxQACgkQeiVVYja6o6PzqwCfURLnl4F0BnfLkYcaY7hPt8aJ
Qd4AnjCHo7ywIniAsvwmeFFDqh0kScqU
=wL7h
-----END PGP SIGNATURE-----
8:53 a.m.
On Thu, May 2, 2013 at 4:50 AM, Stephen Gallagher <sgallagh(a)redhat.com> wrote:
On 05/02/2013 01:40 AM, T.C. Hollingsworth wrote:
> On Mon, Apr 29, 2013 at 12:02 AM, Stanislav Ochotnicky
> <sochotnicky(a)redhat.com> wrote:
>> Quoting T.C. Hollingsworth (2013-04-27 00:03:21)
>>> Yeah, this seems like a good idea. I wonder if npm2rpm and
>>> stuff like that should live in this package, or in it's own?
>>
>> Advantage of having single project is that you won't have to
>> approve commit access several times :-) In Java we create single
>> source tarball, but then spec file splits this into several
>> smaller binary RPMs.
>
> True. We'd definitely want to split the binary RPMs if we did
> this because npm2rpm will be much more dep heavy (it needs npm
> itself as well as a templating library).
>
Please remember to consider the bootstrapping problem in the event of
future mass-rebuilds. If the nodejs package starts build-depending on
the npm package, that's a circular dependency that becomes very
difficult to maintain. (I've seen how they have to do it in GCC, and
it's not pretty).
I'm just talking about Requires: npm. We definitely wouldn't need
BuildRequires on it (the only way that would ever be possible is for
%check, but there's no network in koji so we couldn't use it for any
tests there anyway). So, this shouldn't be a problem?
I'd suggest that we might want to pull out the macro and npm2rpm
stuff
as a separate SRPM, mainly just to avoid this problem. So I'm all for
the 'nodejs-packaging' project to be all-encompassing here.
-T.C.
1:38 p.m.
On Fri, May 3, 2013 at 6:53 AM, T.C. Hollingsworth
<tchollingsworth(a)gmail.com> wrote:
> Please remember to consider the bootstrapping problem in the
event of
> future mass-rebuilds. If the nodejs package starts build-depending on
> the npm package, that's a circular dependency that becomes very
> difficult to maintain. (I've seen how they have to do it in GCC, and
> it's not pretty).
I'm just talking about Requires: npm. We definitely wouldn't need
BuildRequires on it (the only way that would ever be possible is for
%check, but there's no network in koji so we couldn't use it for any
tests there anyway). So, this shouldn't be a problem?
Actually, come to think of it, there's still a nasty dep loop if
npm2rpm and nodejs-packaging share SRPMs regardless of whether its
build-time or runtime. It don't think it's realistically a problem
for Fedora secondary arches since they just import noarch binary RPMs
from primary wholesale, but better to avoid it anyway.
I'll get a nodejs-packaging package up for review soonish, so we can
hopefully migrate to it when 0.10.6 comes out (which ought not to be
for a little while; I see no interesting commits on the v0.10 branch
since 0.10.5).
-T.C.
3:46 p.m.
On 25/04/13 19:07, T.C. Hollingsworth wrote:
Hi Fedora noders!
<snip>
Great stuff, congrats everyone! Things are coming along nicely :)
I just spotted nodejs-tap on bodhi (thanks T.C.!). That means we now
have mocha, expresso, should, vows, jasmine-node and tap in Fedora,
which means most modules should be able to have their %check
section enabled.
I plan to post a few more test-suite related packages for review
at some point to increase our %check coverage even more (eg, nodeunit
+deps, superagent, supertest etc), but of course anyone can feel free to
beat me to it ;)
Kind regards,
--
Jamie Nguyen
5:01 p.m.
On Fri, Apr 26, 2013 at 1:46 PM, Jamie Nguyen <j(a)jamielinux.com> wrote:
Great stuff, congrats everyone! Things are coming along nicely :)
I just spotted nodejs-tap on bodhi (thanks T.C.!). That means we now
have mocha, expresso, should, vows, jasmine-node and tap in Fedora,
which means most modules should be able to have their %check
section enabled.
Sorry, I meant to mention that in that e-mail as well. I'll be
enabling %check in the npm stack and rebuilding in Rawhide soon.
I plan to post a few more test-suite related packages for review
at some point to increase our %check coverage even more (eg, nodeunit
+deps, superagent, supertest etc), but of course anyone can feel free to
beat me to it ;)
Awesome! A couple npm dependencies use nodeunit, so this will be very helpful.
-T.C.
4009
days inactive
4018
days old
nodejs@lists.fedoraproject.org
9 comments
4 participants
participants (4)
-
Jamie Nguyen -
Stanislav Ochotnicky -
Stephen Gallagher -
T.C. Hollingsworth