Handling architecture limitations
by Stephen Gallagher
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
The main Node.js package supports only x86[_64] and ARM architectures,
due to these being the only supported architectures of v8. This is
causing issues with the downstream packages such as nodejs-less which
are built for EPEL6.
Is there any way to add ExclusiveArch to the
%{?nodejs_find_provides_and_requires} macro in the main node package
so that we won't try to build the modules on unsupported
architectures? It would be a lot less effort to fix that macro than it
would be to fix every node module.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlGaF3sACgkQeiVVYja6o6MlugCdGBTLzrVaz6ZQNWM7juDt0trc
krYAn0HXNxsnHewgCkyFLXC6EAUkYKSd
=PPij
-----END PGP SIGNATURE-----
10 years, 3 months
nodejs-0.10.8
by T.C. Hollingsworth
I just pushed updates to nodejs-0.10-8, libuv-0.10.8, and v8-3.14.5.10
to updates-testing in all branches.
These updates contain the libuv linker changes previously mentioned by
Stephen Gallagher on this list. [1] They also contain the first V8
JavaScript interpreter update in quite some time.
While I tested things as much as I could, I wouldn't be the least bit
surprised if I missed something (anyone who has watchcommits on my
packages knows I space out on silly stuff all the time), so please
test your modules with the updates extensively and report [2] any
issues you encounter. There are a lot of moving parts in this update
so it'd be nice to be 100% certain everything is copacetic before
going stable, as this is likely what will ship with F19 Gold.
And if by some miracle everything works well, please provide positive
karma to the F19 [3], F18 [4], and EPEL6 [5] updates as appropriate.
An npm update is forthcoming, but that will require a few more package
reviews as isaacs continues to split out functionality useful to other
projects into their own modules. I'll post to the list when they're
ready.
Thanks everyone for your awesome efforts!
-T.C.
[1] http://comments.gmane.org/gmane.linux.redhat.fedora.nodejs/14
[2] http://bugz.fedoraproject.org/nodejs
[3] https://admin.fedoraproject.org/updates/v8-3.14.5.10-1.fc19,libuv-0.10.8-...
[4] https://admin.fedoraproject.org/updates/v8-3.14.5.10-1.fc18,libuv-0.10.8-...
[5] https://admin.fedoraproject.org/updates/v8-3.14.5.10-1.el6,libuv-0.10.8-1...
10 years, 4 months
Back in action
by Jamie Nguyen
Hi all,
Just to let you know I'm now back in action. Most of the open reviews at
https://bugzilla.redhat.com/show_bug.cgi?id=956806 are mine, but most
aren't particularly urgent.
Just a note that nodejs-node-xmpp does not yet work on Node 0.10.x.
Since node-xmpp is an essential component of the buddycloud software,
buddycloud doesn't really work yet (ie, segfaults and weird behaviour).
The original author of node-xmpp went on to other things a long time ago
so it hasn't received any love for a while, but a buddycloud developer
has recently taken over node-xmpp so hopefully things will change over
the next few months. Regardless, it will be nice to have all the
dependencies ready for when buddycloud does start to work, and many of
them are very popular themselves anyway (like winston or stylus).
I'll also make a start on reviewing some of the other outstanding Node
reviews.
Kind regards,
--
Jamie Nguyen
10 years, 4 months
libuv tweaks
by Stephen Gallagher
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I saw today that libuv pushed a patch upstream to enable proper
setting of the -soname argument when calling 'ld'. I built this change
in Rawhide, but I'll confess to not being certain enough about how the
linker works to backport the same change to F19 and earlier. I'm
concerned it might be an effective soname bump without the
accompanying filename change.
The other change I made was to drop the Bundles(ev) notification, as I
see that they actually pulled that out of the code quite some time
ago. Which is excellent.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlGQ2WUACgkQeiVVYja6o6PKPACfdZRjzwrLP/Ig3I/pV7bdLNWV
3coAn22ol8dgnDlfhiC8+zW3tK0CX5eK
=Y8VW
-----END PGP SIGNATURE-----
10 years, 4 months
Node.js Mailing List (& more!)
by T.C. Hollingsworth
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
10 years, 4 months
Package rename breakage - wat do?
by T.C. Hollingsworth
Someone recently experienced a little breakage related to a package
rename, and I'm not sure about the best strategy to resolve it.
Upstream finally got around to unbundling a cookie handling library
from two unrelated npm packages (tobi and request). We had previously
split it off in Fedora before, but needed to rename the package and
move it into its final home, so the directory under
/usr/lib/node_modules changed. While I shipped an updated
nodejs-request along with the new nodejs-cookie-jar package in the
same Bodhi update, it's possible to update to nodejs-cookie-jar (which
Obsolotes/Provides the old unbundled package) without updating
nodejs-request. This will of course will break request since it looks
for it under the old, temporary name.
So, should we:
1. provide a compatibility symlink so older versions of
nodejs-request aren't broken at all
2. add Conflicts to nodejs-cookie-jar specifiying the older versions
of nodejs-request that it will break
3. do nothing; if you install only part of a single bodhi update and
it breaks you get to keep both pieces
Both 1 or 2 are ugly in their own way, and 3 might be technically
correct but doesn't seem very nice, so I'm not sure how to proceed.
Thanks in advance for suggestions!
-T.C.
10 years, 5 months
