So we have a load more broken dependencies because sntp 2.x has been pushed in rawhide but it requires nodejs 4.x.
It seems it really does require 4.x as it uses various "harmony" features, some of which don't even work under node 0.10 even with -harmony.
Piotr - did you intend to build it in the side tag? or did you just not realise it needed node 4?
Tom
On 12/13/2015 06:12 PM, Tom Hughes wrote:
So we have a load more broken dependencies because sntp 2.x has been pushed in rawhide but it requires nodejs 4.x.
It seems it really does require 4.x as it uses various "harmony" features, some of which don't even work under node 0.10 even with -harmony.
Piotr - did you intend to build it in the side tag? or did you just not realise it needed node 4?
No this is by accident. I don't know how I could miss this as I did think about checking this, I even did not push some other modules because of this reason. Excuse me for the mess.
What is the progress on 4.x? Should I downgrade sntp to 1.0.9 or wait for 4.x?
Piotr
On 13/12/15 21:20, Piotr Popieluch wrote:
On 12/13/2015 06:12 PM, Tom Hughes wrote:
So we have a load more broken dependencies because sntp 2.x has been pushed in rawhide but it requires nodejs 4.x.
It seems it really does require 4.x as it uses various "harmony" features, some of which don't even work under node 0.10 even with -harmony.
Piotr - did you intend to build it in the side tag? or did you just not realise it needed node 4?
No this is by accident. I don't know how I could miss this as I did think about checking this, I even did not push some other modules because of this reason. Excuse me for the mess.
What is the progress on 4.x? Should I downgrade sntp to 1.0.9 or wait for 4.x?
Well 4.x is working and the binary modules are all rebuilt now I think.
The remaining issue is updating the npm stack I think?
Maybe we should untag that build from rawhide for now and build it in the side tag instead?
Tom
On Sun, Dec 13, 2015 at 5:42 PM, Tom Hughes tom@compton.nu wrote:
The remaining issue is updating the npm stack I think?
Yes, that that's going to take quite a bit of work... Every time I sit down to try to tackle more of the dependencies, I end up losing a bit of my sanity. I'll try to take some time this week to document the problems I'm running into, and maybe brighter minds than mine can figure out some of the issues.
Maybe we should untag that build from rawhide for now and build it in the side tag instead?
I think that sounds like a good plan.
-- Jared Smith
On Dec 13, 2015, at 8:25 PM, Jared K. Smith jsmith@fedoraproject.org wrote:
On Sun, Dec 13, 2015 at 5:42 PM, Tom Hughes tom@compton.nu wrote: The remaining issue is updating the npm stack I think?
Yes, that that's going to take quite a bit of work... Every time I sit down to try to tackle more of the dependencies, I end up losing a bit of my sanity. I'll try to take some time this week to document the problems I'm running into, and maybe brighter minds than mine can figure out some of the issues.
Maybe we should untag that build from rawhide for now and build it in the side tag instead?
I think that sounds like a good plan.
Unfortunately, it's too late for an untag since it has hit the mirrors. The right move here is probably an epoch-bump downgrade to unbreak Rawhide.
-- Jared Smith
nodejs mailing list nodejs@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/nodejs@lists.fedoraproject.org
On Mon, Dec 14, 2015 at 2:27 AM, Stephen Gallagher sgallagh@redhat.com wrote:
On Dec 13, 2015, at 8:25 PM, Jared K. Smith jsmith@fedoraproject.org wrote:
On Sun, Dec 13, 2015 at 5:42 PM, Tom Hughes tom@compton.nu wrote:
The remaining issue is updating the npm stack I think?
Yes, that that's going to take quite a bit of work... Every time I sit down to try to tackle more of the dependencies, I end up losing a bit of my sanity. I'll try to take some time this week to document the problems I'm running into, and maybe brighter minds than mine can figure out some of the issues.
I'm glad I'm not the only one feeling this way. As careful I am trying to
be I still end up overlooking some dependency. I wonder if it would be possible to reuse the code from taskotron depcheck, or from the koji depcheck to have a local depency check which could be run before pushing to rawhide.
Maybe we should untag that build from rawhide for now and build it in the side tag instead?
I think that sounds like a good plan.
Unfortunately, it's too late for an untag since it has hit the mirrors. The right move here is probably an epoch-bump downgrade to unbreak Rawhide.
Just did this.
On 14/12/15 08:05, Piotr Popieluch wrote:
I'm glad I'm not the only one feeling this way. As careful I am trying to be I still end up overlooking some dependency. I wonder if it would be possible to reuse the code from taskotron depcheck, or from the koji depcheck to have a local depency check which could be run before pushing to rawhide.
I was thinking about this last night, and much of the problem comes from modules where for one reason or another we don't have the tests enabled.
It struck me that, in most cases, and at least with the recent issues with both argparse and sntp, even just a simple attempt to load the module would have caught them.
So my proposal is that if there are no proper tests, or we are not currently able to enable them, then a simple %check along these lines should be included:
%{__nodejs} -e 'require("./")'
It won't catch everything because sometimes a dependency is only loaded when a particular feature is used, but in most cases they are loaded unconditionally when the module is loaded.
Tom
On Dec 14, 2015, at 4:10 AM, Tom Hughes tom@compton.nu wrote:
On 14/12/15 08:05, Piotr Popieluch wrote:
I'm glad I'm not the only one feeling this way. As careful I am trying to be I still end up overlooking some dependency. I wonder if it would be possible to reuse the code from taskotron depcheck, or from the koji depcheck to have a local depency check which could be run before pushing to rawhide.
I was thinking about this last night, and much of the problem comes from modules where for one reason or another we don't have the tests enabled.
It struck me that, in most cases, and at least with the recent issues with both argparse and sntp, even just a simple attempt to load the module would have caught them.
So my proposal is that if there are no proper tests, or we are not currently able to enable them, then a simple %check along these lines should be included:
%{__nodejs} -e 'require("./")'
It won't catch everything because sometimes a dependency is only loaded when a particular feature is used, but in most cases they are loaded unconditionally when the module is loaded.
I'd actually argue that we probably want to do this whether or not there are other tests. (It's always possible that upstream tests run against the source directory instead of the installed path, and therefore might not be entirely correct)
I'd go so far as to say that we should propose a modification to the packaging guidelines to state this explicitly. Would you like me to prepare a draft?
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
On 14/12/15 11:35, Stephen Gallagher wrote:
I'd actually argue that we probably want to do this whether or not there are other tests. (It's always possible that upstream tests run against the source directory instead of the installed path, and therefore might not be entirely correct)
Well normally in koji there won't an old version present so that's unlikely. Plus because node only searches the local node_modules normally it would still be unlikely to find it.
I'd go so far as to say that we should propose a modification to the packaging guidelines to state this explicitly. Would you like me to prepare a draft?
Sounds good to me.
Sometimes modules have extra entry points that can be loaded with variants of require in which case those could be test loaded as well.
Tom
On Dec 14, 2015, at 6:55 AM, Tom Hughes tom@compton.nu wrote:
On 14/12/15 11:35, Stephen Gallagher wrote:
I'd actually argue that we probably want to do this whether or not there are other tests. (It's always possible that upstream tests run against the source directory instead of the installed path, and therefore might not be entirely correct)
Well normally in koji there won't an old version present so that's unlikely. Plus because node only searches the local node_modules normally it would still be unlikely to find it.
I'd go so far as to say that we should propose a modification to the packaging guidelines to state this explicitly. Would you like me to prepare a draft?
Sounds good to me.
Sometimes modules have extra entry points that can be loaded with variants of require in which case those could be test loaded as well.
Could you give me an example of those variants?
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
On 14/12/15 12:08, Stephen Gallagher wrote:
I'd go so far as to say that we should propose a modification to the packaging guidelines to state this explicitly. Would you like me to prepare a draft?
Sounds good to me.
Sometimes modules have extra entry points that can be loaded with variants of require in which case those could be test loaded as well.
Could you give me an example of those variants?
I was going to say readable-stream, where you can do:
require('readable-stream/transform')
but it turns out the main entry point also requires and exports that, so it is equivalent to:
require('readable-stream').Transform
It illustrates the basic point though, that there can be other top level js files that you can require as module/file or test as:
node -e "require('./file')"
Tom
On 14/12/15 01:25, Jared K. Smith wrote:
Yes, that that's going to take quite a bit of work... Every time I sit down to try to tackle more of the dependencies, I end up losing a bit of my sanity. I'll try to take some time this week to document the problems I'm running into, and maybe brighter minds than mine can figure out some of the issues.
So I did "npm install npm" and then listed the contents of all the node_modules directories in the result tree, deduplicated them, and tried to install them all in rawhide and these are the missing ones:
aproba are-we-there-yet array-index balanced-match brace-expansion builtin-modules concat-map delegates escape-string-regexp foo gauge graceful-readlink has-ansi has-unicode iferr imurmurhash is-absolute is-builtin-module is-relative jju json-parse-helpfulerror os-homedir path-array read-cmd-shim readdir-scoped-modules read-package-tree realize-package-specifier sorted-object spdx-correct spdx-exceptions spdx-expression-parse unique-filename unique-slug validate-npm-package-license
There may be others which need updating to newer versions, but this is a start at least.
Tom
I have packages either built or in process for the following:
balanced-match brace-expansion builtin-modules concat-map escape-string-regexp graceful-readlink has-ansi is-builtin-module jju json-parse-helpfulerror os-homedir spdx-correct spdx-exceptions spdx-expression-parse validate-npm-package-license
I'll double-check each of them and start creating review requests for them today.
-- Jared Smith
On 14/12/15 15:25, Jared K. Smith wrote:
I have packages either built or in process for the following:
balanced-match brace-expansion builtin-modules concat-map escape-string-regexp graceful-readlink has-ansi is-builtin-module jju json-parse-helpfulerror os-homedir spdx-correct spdx-exceptions spdx-expression-parse validate-npm-package-license
I'll double-check each of them and start creating review requests for them today.
We should probably create a wiki page with list of all the packages and package updates that we know are needed along with bug numbers and/or who is working on them?
Tom
On Mon, Dec 14, 2015 at 11:05 AM, Tom Hughes tom@compton.nu wrote:
We should probably create a wiki page with list of all the packages and package updates that we know are needed along with bug numbers and/or who is working on them?
Quick and dirty wiki page created at https://fedoraproject.org/wiki/Node.js/npm_update_status
-Jared
Are these just the packages needed for npm? I'm just asking because I don't see nodejs-foo listed as a npm dependency and it looks pretty dead to me.
----- Original Message ----- From: "Jared K. Smith" jsmith@fedoraproject.org To: "Node.js on Fedora" nodejs@lists.fedoraproject.org Sent: Monday, December 14, 2015 5:31:46 PM Subject: Re: sntp
On Mon, Dec 14, 2015 at 11:05 AM, Tom Hughes < tom@compton.nu > wrote:
We should probably create a wiki page with list of all the packages and package updates that we know are needed along with bug numbers and/or who is working on them?
Quick and dirty wiki page created at https://fedoraproject.org/wiki/Node.js/npm_update_status
-Jared
_______________________________________________ nodejs mailing list nodejs@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/nodejs@lists.fedoraproject.org
On 14/12/15 19:38, Zuzana Svetlikova wrote:
Are these just the packages needed for npm? I'm just asking because I don't see nodejs-foo listed as a npm dependency and it looks pretty dead to me.
Looks like my script was confused by this:
node_modules/read-package-tree/test/fixtures/empty/node_modules/foo/ node_modules/read-package-tree/test/fixtures/noname/node_modules/foo/
So scratch foo from the list.
Tom
----- Original Message ----- From: "Jared K. Smith" jsmith@fedoraproject.org To: "Node.js on Fedora" nodejs@lists.fedoraproject.org Sent: Monday, December 14, 2015 5:31:46 PM Subject: Re: sntp
On Mon, Dec 14, 2015 at 11:05 AM, Tom Hughes < tom@compton.nu > wrote:
We should probably create a wiki page with list of all the packages and package updates that we know are needed along with bug numbers and/or who is working on them?
Quick and dirty wiki page created at https://fedoraproject.org/wiki/Node.js/npm_update_status
-Jared
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@lists.fedoraproject.org