Are there any actual plans for Node.js stack in fedora? Are we going to update everything and hope that nothing breaks (much)? Is there any way of knowing beforehand if update will break some other packages (because I don't know of any, so please enlighten me)? What about updating v8, nodejs and npm? Are we going for LTS and npm@2 or directly to v5.x and npm@3?
I'm sorry for so many questions, I'd just like to have some answers so I know on what I should focus.
Thanks
On Thu, Nov 26, 2015 at 7:11 AM, Zuzana Svetlikova zsvetlik@redhat.com wrote:
Are there any actual plans for Node.js stack in fedora? Are we going to update everything and hope that nothing breaks (much)? Is there any way of knowing beforehand if update will break some other packages (because I don't know of any, so please enlighten me)?
While I don't have any definitive plans, I would like to see the entire stack updated in Fedora and EPEL. I've slowly been working on a lot of updated packages in my COPR repo, but haven't yet take then time to try update v8 or nodejs or npm. I know that someone had proposed Node v4.x as a feature for F23, but then it got delayed, and I haven't heard of any plans since.
What about updating v8, nodejs and npm? Are we going for LTS and npm@2 or directly to v5.x and npm@3?
While I'd love to support v5.x, given the current lack of resources, I'd say targeting LTS might make more sense (and certainly makes sense for EPEL, no matter what we decide for Fedora).
-- Jared Smith
On 11/26/2015 01:11 PM, Zuzana Svetlikova wrote:
Are there any actual plans for Node.js stack in fedora? Are we going to update everything and hope that nothing breaks (much)? Is there any way of knowing beforehand if update will break some other packages (because I don't know of any, so please enlighten me)?
I try to build packages in COPR first, but this is quite work intensive and does not have any automated checks. Rawhide has no gating/checks either, I think most of us did accidentally push a package to rawhide which happened to introduce new missing dependencies. Koschei is good to see if an update to a package breaks a dependency, but for this to work packages need to have tests enabled and we still miss some test frameworks (which are not packaged yet). Also Kosechei is a bit too late imho, I would rather want to know if my update breaks something *before* I push it to rawhide, not after..
What about updating v8, nodejs and npm? Are we going for LTS and npm@2 or directly to v5.x and npm@3?
T.C. Hollingsworth had plans to update but this got delayed. I haven't heard from him in a while. Victor Jancik tried to update nodejs out of the blue without contacting any one of us. That wasn't received well and most of his ACL requests got mass denied. I think that unfortunately this reaction demotivated him to continue on this.
Someone needs to step up to lead these updates. I certainly don't have the time and packaging experience to do this.
I'm sorry for so many questions, I'd just like to have some answers so I know on what I should focus.
Thanks _______________________________________________ nodejs mailing list nodejs@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/nodejs@lists.fedoraproject.org
Hi,
On Mon, Nov 30, 2015 at 1:47 AM, Piotr Popieluch piotr1212@gmail.com wrote:
On 11/26/2015 01:11 PM, Zuzana Svetlikova wrote:
Are there any actual plans for Node.js stack in fedora? Are we going to update everything and hope that nothing breaks (much)? Is there any way of knowing beforehand if update will break some other packages (because I don't know of any, so please enlighten me)?
I try to build packages in COPR first, but this is quite work intensive and does not have any automated checks. Rawhide has no gating/checks either, I think most of us did accidentally push a package to rawhide which happened to introduce new missing dependencies. Koschei is good to see if an update to a package breaks a dependency, but for this to work packages need to have tests enabled and we still miss some test frameworks (which are not packaged yet). Also Kosechei is a bit too late imho, I would rather want to know if my update breaks something *before* I push it to rawhide, not after..
What about updating v8, nodejs and npm? Are we going for LTS and npm@2 or directly to v5.x and npm@3?
T.C. Hollingsworth had plans to update but this got delayed. I haven't heard from him in a while. Victor Jancik tried to update nodejs out of the blue without contacting any one of us. That wasn't received well and most of his ACL requests got mass denied. I think that unfortunately this reaction demotivated him to continue on this.
Someone needs to step up to lead these updates. I certainly don't have the time and packaging experience to do this.
I did mass denied Victor's requests because the usual process has not been followed. That process should be like send an email to the related group like this list about your plans then propose one F24 Change and add the link for further review of it here, once the people here find that proposal good to be implemented then ACL's could have been requested and I would have happily granted ACL's for all of my packages.
If anyone needs any packaging help then I am always here to help for it. I can help but not that experienced in nodejs to lead this effort.
Regards, Parag.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 11/29/2015 03:17 PM, Piotr Popieluch wrote:
On 11/26/2015 01:11 PM, Zuzana Svetlikova wrote:
Are there any actual plans for Node.js stack in fedora? Are we going to update everything and hope that nothing breaks (much)? Is there any way of knowing beforehand if update will break some other packages (because I don't know of any, so please enlighten me)?
I try to build packages in COPR first, but this is quite work intensive and does not have any automated checks. Rawhide has no gating/checks either, I think most of us did accidentally push a package to rawhide which happened to introduce new missing dependencies. Koschei is good to see if an update to a package breaks a dependency, but for this to work packages need to have tests enabled and we still miss some test frameworks (which are not packaged yet). Also Kosechei is a bit too late imho, I would rather want to know if my update breaks something *before* I push it to rawhide, not after..
What about updating v8, nodejs and npm? Are we going for LTS and npm@2 or directly to v5.x and npm@3?
T.C. Hollingsworth had plans to update but this got delayed. I haven't heard from him in a while.
- From what I've heard, he's effectively gone from this project due to other commitments at this time.
Victor Jancik tried to update nodejs out of the blue without contacting any one of us. That wasn't received well and most of his ACL requests got mass denied. I think that unfortunately this reaction demotivated him to continue on this.
Someone needs to step up to lead these updates. I certainly don't have the time and packaging experience to do this.
I have the packaging experience and can try to help with reviews, but my daily tasks will prevent me from doing a lot of active work right now. That said, I know that there are plenty of people with a vested interest in seeing Node,js 4.x+ appear in Fedora and EPEL as soon as humanly possible. In particular, with the source release of Visual Studio Code, there are some folks who would consider it a coup for Fedora 24 to be the first distro to carry it in the repository.
I'd also like to propose that we focus on working only on the 4.x LTS release initially and upgrade Fedora to the latest supported release after that (this way we can do the exact same work for both Fedora and EPEL in the first pass; I think it makes sense for EPEL to always stay on the LTS releases).
I'm sorry for so many questions, I'd just like to have some answers so I know on what I should focus.
No, it's important to have a plan, certainly. I'll see what I can do to get the core libuv and nodejs packages up to 4.x if I can find the time this week.
In order to avoid breaking Rawhide significantly, I think it would be a good idea to request a side-tag to work on this.
I'm resurrecting the 0.12 upgrade Change Proposal and updating it to 4.x: https://fedoraproject.org/wiki/Changes/NodeJS4x
I've put my name on it as the Change Owner, but I'd appreciate if anyone else who is working on this would also add their names to the Owner section. I'll mark the page as ready for the wrangler announcement once at least one other person signs on.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 11/30/2015 08:21 AM, Stephen Gallagher wrote:
In order to avoid breaking Rawhide significantly, I think it would be a good idea to request a side-tag to work on this.
I went ahead and requested that tag: https://fedorahosted.org/rel-eng/ticket/6308
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 11/30/2015 08:22 AM, Stephen Gallagher wrote:
On 11/30/2015 08:21 AM, Stephen Gallagher wrote:
In order to avoid breaking Rawhide significantly, I think it would be a good idea to request a side-tag to work on this.
I went ahead and requested that tag: https://fedorahosted.org/rel-eng/ticket/6308 _______________________________________________ nodejs mailing list nodejs@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/nodejs@lists.fedoraproject.org
""" Comment (by pbrobinson):
f24-nodejs4 is created. You can build with:
{{{ fedpkg build --target f24-nodejs4 }}}
Please update this ticket when you have all the builds in place so rel-eng can coordinate to have them all tagged over into rawhide. """
I'll take a look at getting the foundational pieces in place this week.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 11/30/2015 07:53 PM, Stephen Gallagher wrote:
On 11/30/2015 08:22 AM, Stephen Gallagher wrote:
On 11/30/2015 08:21 AM, Stephen Gallagher wrote:
In order to avoid breaking Rawhide significantly, I think it would be a good idea to request a side-tag to work on this.
I went ahead and requested that tag: https://fedorahosted.org/rel-eng/ticket/6308 _______________________________________________ nodejs mailing list nodejs@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/nodejs@lists.fedoraproject.org
""" Comment (by pbrobinson):
f24-nodejs4 is created. You can build with:
{{{ fedpkg build --target f24-nodejs4 }}}
Please update this ticket when you have all the builds in place so rel-eng can coordinate to have them all tagged over into rawhide. """
I'll take a look at getting the foundational pieces in place this week.
OK, the f24-nodejs4 side-tag now has all the pieces up to and including the nodejs-4.2.2-1.fc24 package. (This does not include npm).
Basically, I needed to build three packages: libuv 1.7.5, http_parser 2.6.0 and Node.js 4.2.2
Note: this version of Node.js bundles c-ares and v8 due to upstream forks. The reference to upstream's decision is included in the spec file and I have added Provides: bundled(c-ares) and Provides: bundled(v8) as appropriate.
I'd like for someone else to start the process of getting npm built into that tag. Once that's in place, we should be able to start migrating the existing nodejs-* packages.
On 02/12/15 00:54, Stephen Gallagher wrote:
OK, the f24-nodejs4 side-tag now has all the pieces up to and including the nodejs-4.2.2-1.fc24 package. (This does not include npm).
Basically, I needed to build three packages: libuv 1.7.5, http_parser 2.6.0 and Node.js 4.2.2
Actually the nodejs build failed on ARM with an undefined reference when linking:
http://koji.fedoraproject.org/koji/taskinfo?taskID=12026059 https://kojipkgs.fedoraproject.org/work/tasks/6059/12026059/build.log
Tom
On Dec 2, 2015, at 5:08 AM, Tom Hughes tom@compton.nu wrote:
On 02/12/15 00:54, Stephen Gallagher wrote:
OK, the f24-nodejs4 side-tag now has all the pieces up to and including the nodejs-4.2.2-1.fc24 package. (This does not include npm).
Basically, I needed to build three packages: libuv 1.7.5, http_parser 2.6.0 and Node.js 4.2.2
Actually the nodejs build failed on ARM with an undefined reference when linking:
http://koji.fedoraproject.org/koji/taskinfo?taskID=12026059 https://kojipkgs.fedoraproject.org/work/tasks/6059/12026059/build.log
Ugh, okay. I guess that's what I get for trusting x86_64 scratch builds.
I'll look into it later this morning. In the meantime, if anyone wants to pull down the packages that did build and start testing it to see if it supports their npms/applications, that would be helpful.
Tom
-- Tom Hughes (tom@compton.nu) http://compton.nu/ _______________________________________________ nodejs mailing list nodejs@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/nodejs@lists.fedoraproject.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 12/02/2015 05:43 AM, Stephen Gallagher wrote:
On Dec 2, 2015, at 5:08 AM, Tom Hughes tom@compton.nu wrote:
On 02/12/15 00:54, Stephen Gallagher wrote:
OK, the f24-nodejs4 side-tag now has all the pieces up to and including the nodejs-4.2.2-1.fc24 package. (This does not include npm).
Basically, I needed to build three packages: libuv 1.7.5, http_parser 2.6.0 and Node.js 4.2.2
Actually the nodejs build failed on ARM with an undefined reference when linking:
http://koji.fedoraproject.org/koji/taskinfo?taskID=12026059 https://kojipkgs.fedoraproject.org/work/tasks/6059/12026059/build.log
Ugh, okay. I guess that's what I get for trusting x86_64 scratch builds.
I'll look into it later this morning. In the meantime, if anyone wants to pull down the packages that did build and start testing it to see if it supports their npms/applications, that would be helpful.
Looks like the ARM build from upstream is broken for the Debug builds but works fine for the Release builds. For the moment, I just disabled the Debug builds (and the node_g binary) for ARM. That has now built to completion in the side-tag.
On 02/12/15 15:28, Stephen Gallagher wrote:
Looks like the ARM build from upstream is broken for the Debug builds but works fine for the Release builds. For the moment, I just disabled the Debug builds (and the node_g binary) for ARM. That has now built to completion in the side-tag.
Now in the build root as well, but I notice that it is still providing nodejs(abi) as 0.10 and /usr/lib/rpm/nodejs_native.req is adding that as the require for native modules as well.
The nodejs(v8-abi) has changed, but before I start trying to rebuild my native modules should be changing nodejs(abi) as well?
Tom
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 12/02/2015 10:56 AM, Tom Hughes wrote:
On 02/12/15 15:28, Stephen Gallagher wrote:
Looks like the ARM build from upstream is broken for the Debug builds but works fine for the Release builds. For the moment, I just disabled the Debug builds (and the node_g binary) for ARM. That has now built to completion in the side-tag.
Now in the build root as well, but I notice that it is still providing nodejs(abi) as 0.10 and /usr/lib/rpm/nodejs_native.req is adding that as the require for native modules as well.
The nodejs(v8-abi) has changed, but before I start trying to rebuild my native modules should be changing nodejs(abi) as well?
Yeah, I think I missed that. Whoops. I'll get that fixed and rebuilt.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 12/02/2015 11:12 AM, Stephen Gallagher wrote:
On 12/02/2015 10:56 AM, Tom Hughes wrote:
On 02/12/15 15:28, Stephen Gallagher wrote:
Looks like the ARM build from upstream is broken for the Debug builds but works fine for the Release builds. For the moment, I just disabled the Debug builds (and the node_g binary) for ARM. That has now built to completion in the side-tag.
Now in the build root as well, but I notice that it is still providing nodejs(abi) as 0.10 and /usr/lib/rpm/nodejs_native.req is adding that as the require for native modules as well.
The nodejs(v8-abi) has changed, but before I start trying to rebuild my native modules should be changing nodejs(abi) as well?
Yeah, I think I missed that. Whoops. I'll get that fixed and rebuilt.
Should be all set now. Thanks for catching that.
http://koji.fedoraproject.org/koji/buildinfo?buildID=702863
On 02/12/15 17:04, Stephen Gallagher wrote:
Should be all set now. Thanks for catching that.
So current status of the binary modules is as follows. Firstly ones that were using nan v2 and have been rebuilt successfully in the side tag:
nodejs-fs-ext nodejs-gdal nodejs-iconv nodejs-node-expat nodejs-sqlite3 nodejs-zipfile
Ones which have been updated to new upstream releases and/or patches from upstream and built in the side tag:
nodejs-i2c nodejs-libxmljs
One where work is still needed:
nodejs-node-stringprep has a patch on github but the comments suggest it still has issues so it will need more investigation.
nodejs-mapnik is mine, and will need to be updated, but that needs an update to mapnik 3 which I am currently working on in a copr.
nodejs-pg - this is very out of date, and is now noarch with the optional C bindings in the libpq module. I think there are also a number of new dependencies that will need packaging.
Tom
There is a CVE, I am not sure if we have the fixed sources already.
https://nodejs.org/en/blog/vulnerability/cve-2015-8027_cve-2015-6764/
----- Original Message ----- From: "Tom Hughes" tom@compton.nu To: "Node.js on Fedora" nodejs@lists.fedoraproject.org Sent: Thursday, December 3, 2015 1:55:29 AM Subject: Re: Plans for Node.js
On 02/12/15 17:04, Stephen Gallagher wrote:
Should be all set now. Thanks for catching that.
So current status of the binary modules is as follows. Firstly ones that were using nan v2 and have been rebuilt successfully in the side tag:
nodejs-fs-ext nodejs-gdal nodejs-iconv nodejs-node-expat nodejs-sqlite3 nodejs-zipfile
Ones which have been updated to new upstream releases and/or patches from upstream and built in the side tag:
nodejs-i2c nodejs-libxmljs
One where work is still needed:
nodejs-node-stringprep has a patch on github but the comments suggest it still has issues so it will need more investigation.
nodejs-mapnik is mine, and will need to be updated, but that needs an update to mapnik 3 which I am currently working on in a copr.
nodejs-pg - this is very out of date, and is now noarch with the optional C bindings in the libpq module. I think there are also a number of new dependencies that will need packaging.
Tom
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 12/03/2015 08:06 AM, Zuzana Svetlikova wrote:
There is a CVE, I am not sure if we have the fixed sources already.
https://nodejs.org/en/blog/vulnerability/cve-2015-8027_cve-2015-6764/
OK, looking into it, it seems that they haven't released the updated packages or actually lifted the embargo yet. I'll keep an eye on it.
Thanks for the heads-up.
----- Original Message ----- From: "Tom Hughes" tom@compton.nu To: "Node.js on Fedora" nodejs@lists.fedoraproject.org Sent: Thursday, December 3, 2015 1:55:29 AM Subject: Re: Plans for Node.js
On 02/12/15 17:04, Stephen Gallagher wrote:
Should be all set now. Thanks for catching that.
So current status of the binary modules is as follows. Firstly ones that were using nan v2 and have been rebuilt successfully in the side tag:
nodejs-fs-ext nodejs-gdal nodejs-iconv nodejs-node-expat nodejs-sqlite3 nodejs-zipfile
Ones which have been updated to new upstream releases and/or patches from upstream and built in the side tag:
nodejs-i2c nodejs-libxmljs
One where work is still needed:
nodejs-node-stringprep has a patch on github but the comments suggest it still has issues so it will need more investigation.
nodejs-mapnik is mine, and will need to be updated, but that needs an update to mapnik 3 which I am currently working on in a copr.
nodejs-pg - this is very out of date, and is now noarch with the optional C bindings in the libpq module. I think there are also a number of new dependencies that will need packaging.
Tom
On 03/12/15 13:12, Stephen Gallagher wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 12/03/2015 08:06 AM, Zuzana Svetlikova wrote:
There is a CVE, I am not sure if we have the fixed sources already.
https://nodejs.org/en/blog/vulnerability/cve-2015-8027_cve-2015-6764/
OK, looking into it, it seems that they haven't released the updated packages or actually lifted the embargo yet. I'll keep an eye on it.
They moved it from yesterday to tomorrow it seems:
https://nodejs.org/en/blog/vulnerability/december-2015-security-release-upda...
Tom
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 12/03/2015 08:12 AM, Stephen Gallagher wrote:
On 12/03/2015 08:06 AM, Zuzana Svetlikova wrote:
There is a CVE, I am not sure if we have the fixed sources already.
https://nodejs.org/en/blog/vulnerability/cve-2015-8027_cve-2015-6764/
OK, looking into it, it seems that they haven't released the updated packages or actually lifted the embargo yet. I'll keep an eye on it.
Thanks for the heads-up.
OK, I just found https://groups.google.com/forum/#!topic/nodejs-sec/Zf7Nxtg230E which suggests that the updated timetable is sometime today (in the US).
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 12/03/2015 08:14 AM, Stephen Gallagher wrote:
On 12/03/2015 08:12 AM, Stephen Gallagher wrote:
On 12/03/2015 08:06 AM, Zuzana Svetlikova wrote:
There is a CVE, I am not sure if we have the fixed sources already.
https://nodejs.org/en/blog/vulnerability/cve-2015-8027_cve-2015-6764
/
OK, looking into it, it seems that they haven't released the updated packages or actually lifted the embargo yet. I'll keep an eye on it.
Thanks for the heads-up.
OK, I just found https://groups.google.com/forum/#!topic/nodejs-sec/Zf7Nxtg230E which suggests that the updated timetable is sometime today (in the US).
I'm building 4.2.3 now. I also noticed that I screwed something up in the earlier builds: I was accidentally looking at 5.1's copy of v8, so the v8_abi version was wrong. We're actually using a v8 of 4.5 (specifically 4.5.103.35). The 4.2.3 build will correct this, but if any packages need to be rebuilt to handle this properly, be aware of it.
On 03/12/15 00:55, Tom Hughes wrote:
nodejs-pg - this is very out of date, and is now noarch with the optional C bindings in the libpq module. I think there are also a number of new dependencies that will need packaging.
I've opened reviews for dependencies needed to update nodejs-pg:
1288241 pgpass 1288239 pg-escape 1288240 tmp 1288236 pg-types 1288235 postgres-interval 1288234 postgres-date 1288232 postgres-bytea 1288231 postgres-array 1288230 ap 1288242 pff 1288244 pg-connection-string 1288245 packet-reader 1288246 buffer-writer
That gets us the pure js support. To get the compiled interface we will need pg-native and libpq as well.
Tom
On 03/12/15 00:55, Tom Hughes wrote:
Ones which have been updated to new upstream releases and/or patches from upstream and built in the side tag:
nodejs-i2c nodejs-libxmljs
One where work is still needed:
nodejs-node-stringprep has a patch on github but the comments suggest it still has issues so it will need more investigation.
These three are all built in the side tag now.
nodejs-mapnik is mine, and will need to be updated, but that needs an update to mapnik 3 which I am currently working on in a copr.
This is all ready and will be updated once the python-mapnik review is complete.
Tom
On Tue, Dec 1, 2015 at 7:54 PM, Stephen Gallagher sgallagh@redhat.com wrote:
I'd like for someone else to start the process of getting npm built into that tag. Once that's in place, we should be able to start migrating the existing nodejs-* packages.
I've started working on the dependencies for a newer version of npm -- but I'm at a conference this week so I'll be a bit slower than usual at working on these packages.
-Jared
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 12/03/2015 09:30 AM, Jared K. Smith wrote:
On Tue, Dec 1, 2015 at 7:54 PM, Stephen Gallagher <sgallagh@redhat.com mailto:sgallagh@redhat.com> wrote:
I'd like for someone else to start the process of getting npm built into that tag. Once that's in place, we should be able to start migrating the existing nodejs-* packages.
I've started working on the dependencies for a newer version of npm -- but I'm at a conference this week so I'll be a bit slower than usual at working on these packages.
Perhaps if you send the list of them, we can divide up the work.
Are there new package requests needed for this, or are we going to be able to just bump revisions on existing packages?
On Thu, Dec 3, 2015 at 9:33 AM, Stephen Gallagher sgallagh@redhat.com wrote:
Perhaps if you send the list of them, we can divide up the work.
Will do, once I figure them all out -- it's somewhat of an iterative process -- where some dependencies have new dependencies themselves, etc. I'll probably put together a Google Doc or something to keep track of this over time -- or maybe use Taiga in Fedora Infracloud.
Are there new package requests needed for this, or are we going to be able to just bump revisions on existing packages?
Both.
-- Jared Smith
What about installing npm into a directory and then pasting the output of npm ls somewhere?
----- Original Message ----- From: "Jared K. Smith" jsmith@fedoraproject.org To: "Node.js on Fedora" nodejs@lists.fedoraproject.org Sent: Thursday, December 3, 2015 3:36:22 PM Subject: Re: Plans for Node.js
On Thu, Dec 3, 2015 at 9:33 AM, Stephen Gallagher < sgallagh@redhat.com > wrote:
Perhaps if you send the list of them, we can divide up the work.
Will do, once I figure them all out -- it's somewhat of an iterative process -- where some dependencies have new dependencies themselves, etc. I'll probably put together a Google Doc or something to keep track of this over time -- or maybe use Taiga in Fedora Infracloud.
Are there new package requests needed for this, or are we going to be able to just bump revisions on existing packages?
Both.
On Thu, Dec 3, 2015 at 9:36 AM, Jared K. Smith jsmith@fedoraproject.org wrote:
Will do, once I figure them all out -- it's somewhat of an iterative process -- where some dependencies have new dependencies themselves, etc.
So far, this is how far I've made it down the chain:
npm .npm-registry-client (needs nock) ..nock (needs propagate and needle) ...propagate (1286844) ...needle (needs jschardet) ....jschardet (tests not running, but otherwise packaged)
I still haven't figured out the proper incantation to get the tests to run in jschardet -- it seems to require qunit (and even bundles an older copy), but I could use some help figuring out the right way to get the tests invoked, since it isn't specified in package.json. My initial packaging efforts are at https://jsmith.fedorapeople.org/Packaging/nodejs-jschardet/ and I'll be submitting this for review (without the tests) if I don't get a response on this in the next couple of days.
-- Jared Smith
On 03/12/15 16:59, Jared K. Smith wrote:
So far, this is how far I've made it down the chain:
npm .npm-registry-client (needs nock) ..nock (needs propagate and needle) ...propagate (1286844) ...needle (needs jschardet) ....jschardet (tests not running, but otherwise packaged)
I still haven't figured out the proper incantation to get the tests to run in jschardet -- it seems to require qunit (and even bundles an older copy), but I could use some help figuring out the right way to get the tests invoked, since it isn't specified in package.json. My initial packaging efforts are at https://jsmith.fedorapeople.org/Packaging/nodejs-jschardet/ and I'll be submitting this for review (without the tests) if I don't get a response on this in the next couple of days.
As best I can figure QUnit only works in a browser.
If you load index.html in a browser it will run the tests, but I can't see any obvious way to run it from the command line and it relies on injecting methods into the window object.
So because index.html loads qunit.js before the tests, the module, test and equals functions exist because qunit.js adds them to the window object. Works fine in a browser, but not in node...
Tom
On 03/12/15 17:29, Tom Hughes wrote:
If you load index.html in a browser it will run the tests, but I can't see any obvious way to run it from the command line and it relies on injecting methods into the window object.
So you can do it with node-qunit... But it's a bit fiddly...
npm install qunit
then:
node_modules/qunit/bin/cli.js -c jschardet:./index.js -t ./tests/jschardet.js
except you also have to change module to QUnit.module (because module is reserved in node) and equals to equal (because this is a newer qunit version) in the tests.
Tom
On Thu, Dec 3, 2015 at 12:35 PM, Tom Hughes tom@compton.nu wrote:
So you can do it with node-qunit... But it's a bit fiddly...
npm install qunit
then:
node_modules/qunit/bin/cli.js -c jschardet:./index.js -t ./tests/jschardet.js
except you also have to change module to QUnit.module (because module is reserved in node) and equals to equal (because this is a newer qunit version) in the tests.
Wow, not sure I would have figured that out on my own. I got as far as packaging up the dependencies for qunit, but there's obviously something wrong in my qunit package because it was giving me a different error. When I use the qunit installed by npm, the tests run, but I get five failing tests. :-(
-- Jared Smith
On 03/12/15 20:52, Jared K. Smith wrote:
Wow, not sure I would have figured that out on my own. I got as far as packaging up the dependencies for qunit, but there's obviously something wrong in my qunit package because it was giving me a different error. When I use the qunit installed by npm, the tests run, but I get five failing tests. :-(
Sure, but the same five that fail if you just load index.html in a browser ;-)
I didn't dig into that...
Tom
On Mon, Nov 30, 2015 at 8:21 AM, Stephen Gallagher sgallagh@redhat.com wrote:
I have the packaging experience and can try to help with reviews, but my daily tasks will prevent me from doing a lot of active work right now. That said, I know that there are plenty of people with a vested interest in seeing Node,js 4.x+ appear in Fedora and EPEL as soon as humanly possible. In particular, with the source release of Visual Studio Code, there are some folks who would consider it a coup for Fedora 24 to be the first distro to carry it in the repository.
I also have some packaging experience, and *should* have some free time the first couple of weeks of December, as my current job is winding down at the end of the year. If I don't find another job, I'll have *lots* of free time in January :-p
Until I know what my job situation looks like in 2106, consider me on-board and willing to help with the effort. Hopefully my next job will be flexible on letting me spend some of my time helping on this as well.
-- Jared Smith
On Mon, Nov 30, 2015 at 8:21 AM, Stephen Gallagher sgallagh@redhat.com wrote:
I'm resurrecting the 0.12 upgrade Change Proposal and updating it to 4.x: https://fedoraproject.org/wiki/Changes/NodeJS4x
I've put my name on it as the Change Owner, but I'd appreciate if anyone else who is working on this would also add their names to the Owner section. I'll mark the page as ready for the wrangler announcement once at least one other person signs on.
I've added my name, for better or for worse :-)
-- Jared Smith
W dniu 01.01.1970 o 01:00, Stephen Gallagher pisze:
Someone needs to step up to lead these updates. I certainly don't have the time and packaging experience to do this.
I have the packaging experience and can try to help with reviews, but my daily tasks will prevent me from doing a lot of active work right now. That said, I know that there are plenty of people with a vested interest in seeing Node,js 4.x+ appear in Fedora and EPEL as soon as humanly possible. In particular, with the source release of Visual Studio Code, there are some folks who would consider it a coup for Fedora 24 to be the first distro to carry it in the repository.
I have no idea what nodejs and how it works but I am good at building stuff :D
http://fedora.juszkiewicz.com.pl/20151204-nodejs-rebuild/ shows results of my (still ongoing) rebuild of nodejs packages on AArch64 architecture (secondary).
I use "mockchain" (so all build dependencies queues are resolved by hand and --recurse mode) with 884 noarch packages imported from primary. List was generated with "dnf download nodejs* mocha --resolve --destdir /tmp/del/nodejs" command.
Found issues to fix on packaging side:
node-gyp depends on v8-devel while nodejs 4.2.x bundles it - dependency needs to be removed
nodejs-fs-ext ExclusiveArch only for primary instead of %{nodejs_arches}
So far 690/722 built without other changes than above.
On 07/12/15 12:55, Marcin Juszkiewicz wrote:
nodejs-fs-ext ExclusiveArch only for primary instead of %{nodejs_arches}
I've pushed a fix for this and it's building in the side tag now.
Tom
W dniu 07.12.2015 o 13:55, Marcin Juszkiewicz pisze:
Found issues to fix on packaging side:
node-gyp depends on v8-devel while nodejs 4.2.x bundles it - dependency needs to be removed
docco: created /usr/share/doc/docco/resources and not packaged it.
nodejs-millstone-0.6.16-4.fc24 reports: DEBUG util.py:393: Error: nothing provides nodejs(v8-abi) = 4.6 needed by nodejs-zipfile-0.5.9-3.fc24.aarch64
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 12/07/2015 08:37 AM, Marcin Juszkiewicz wrote:
W dniu 07.12.2015 o 13:55, Marcin Juszkiewicz pisze:
Found issues to fix on packaging side:
node-gyp depends on v8-devel while nodejs 4.2.x bundles it - dependency needs to be removed
docco: created /usr/share/doc/docco/resources and not packaged it.
nodejs-millstone-0.6.16-4.fc24 reports: DEBUG util.py:393: Error: nothing provides nodejs(v8-abi) = 4.6 needed by nodejs-zipfile-0.5.9-3.fc24.aarch64
This was due to a typo that I added to the nodejs-4.2.2 series of builds; the nodejs(v8-abi) was supposed to be 4.5, not 4.6. As a result, anything that was built against 4.2.2 needs to be rebuilt against 4.2.3. Sorry about that.
On 07/12/15 13:41, Stephen Gallagher wrote:
nodejs-millstone-0.6.16-4.fc24 reports: DEBUG util.py:393: Error: nothing provides nodejs(v8-abi) = 4.6 needed by nodejs-zipfile-0.5.9-3.fc24.aarch64
This was due to a typo that I added to the nodejs-4.2.2 series of builds; the nodejs(v8-abi) was supposed to be 4.5, not 4.6. As a result, anything that was built against 4.2.2 needs to be rebuilt against 4.2.3. Sorry about that.
The -3 release of zipfile was a rebuild for that reason though. The x86_64 build of it has:
nodejs(v8-abi) = 4.5
My guess is the rebuilds of the binary extensions on aarch64 were done too early, before nodejs 4.2.3 was built.
Tom
nodejs@lists.fedoraproject.org
-
Jared K. Smith -
Marcin Juszkiewicz -
Parag Nemade -
Piotr Popieluch -
Stephen Gallagher -
Tom Hughes -
Zuzana Svetlikova