$ grep -H "[[:space:]]=dev-libs/openssl-1\.1\.0\*" net-libs/nodejs/*.ebuild net-libs/nodejs/nodejs-10.11.0.ebuild: ssl? ( =dev-libs/openssl-1.1.0*:0=[-bindist] ) net-libs/nodejs/nodejs-10.12.0.ebuild: ssl? ( =dev-libs/openssl-1.1.0*:0=[-bindist] ) net-libs/nodejs/nodejs-10.13.0.ebuild: ssl? ( =dev-libs/openssl-1.1.0*:0=[-bindist] ) net-libs/nodejs/nodejs-11.0.0.ebuild: ssl? ( =dev-libs/openssl-1.1.0*:0=[-bindist] ) net-libs/nodejs/nodejs-11.1.0.ebuild: ssl? ( =dev-libs/openssl-1.1.0*:0=[-bindist] ) This is not good now that openssl-1.1.1 is available which is the new LTS version according to upstream. Please check if above mentioned nodejs versions can also work with =openssl-1.1.1* and adjust dependencies accordingly.
It worked for me when I changed the dep to : =dev-libs/openssl-1.1*:0=[-bindist]
The problem is that nodejs itself isn't compatible with openssl 1.1.1, but is compatible with openssl 1.1.0. If you try to compile nodejs with FEATURES="test" enabled, about 65 openssl-related tests fail when using openssl 1.1.1. Nodejs has an issue open for this: https://github.com/nodejs/node/issues/18770
An option could be to let nodejs bundle its own openssl library (remove the use of the --shared-openssl flag in the ebuild). That would let nodejs use its own, bundled and working openssl-1.1.0 while leaving the rest of the system benefit from 1.1.1 or whatever system-wide openssl library version is installed. This could even be controlled through a USE flag, the same way dev-util/cmake has 'system-jsoncpp' for similar purposes.
Created attachment 555616 [details] nodejs-10.13.0-r1.ebuild Proposed ebuild. I'm leaving system-openssl off by default, so that we use the bundled openssl version unless the user requests otherwise. This should allow for nodejs-10.13 to be unmasked, since system-wide openssl-1.1 is the blocker for that right now. If we don't depend on it by default anymore, there should be no reason to keep the mask in place.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=64bc534bf4412e0088839c628ff79fa456ae60bb commit 64bc534bf4412e0088839c628ff79fa456ae60bb Author: Thomas Deutschmann <whissi@gentoo.org> AuthorDate: 2018-11-18 22:11:35 +0000 Commit: Thomas Deutschmann <whissi@gentoo.org> CommitDate: 2018-11-18 22:11:57 +0000 net-libs/nodejs: adjust dev-lib/openssl requirement - We are patching dev-libs/openssl to ship some EC curves even with dev-libs/openssl[bindist] so it is no longer required to enforce dev-libs/openssl[-bindist]. - NodeJS >=10 requires OpenSSL 1.1 or newer. Closes: https://bugs.gentoo.org/670574 Package-Manager: Portage-2.3.51, Repoman-2.3.12 Signed-off-by: Thomas Deutschmann <whissi@gentoo.org> net-libs/nodejs/nodejs-10.13.0.ebuild | 2 +- net-libs/nodejs/nodejs-11.2.0.ebuild | 2 +- net-libs/nodejs/nodejs-99999999.ebuild | 4 ++-- 3 files changed, 4 insertions(+), 4 deletions(-)
Are the test failures against openssl-1.1.1 not a problem? nodejs 10.13 compiles fine against openssl-1.1.0 just as it does against openssl-1.1.1, the failures or would-be failures are at runtime, hence my previous comments. openssl is a security-critical component. I'm concerned that my earlier comments were not addressed.
Can you show me build.log and test failures with =net-libs/nodejs-10.13.0 or =net-libs/nodejs-11.2.0 using *our* =dev-libs/1.1.0i-r3 or =dev-libs/1.1.1-r3? Please make sure to *not* set any api* USE flag for openssl.
Created attachment 555688 [details] nodejs-10.13.0-with-openssl-1.1.0i-r3.build.log.gz build.log for nodejs 10.13.0 against openssl 1.1.0i-r3: two test failures related to c-ares, unrelated to this issue.
Created attachment 555690 [details] nodejs-10.13.0-with-openssl-1.1.1-r3.build.log.gz build.log for nodejs 10.13.0 against openssl 1.1.1-r3: two test failures related to c-ares, unrelated to this issue PLUS 61 new tests failures related to openssl.
note that I had to patch the two openssl -r3 versions to work around https://bugs.gentoo.org/671016 in order for them to build in the first place. I applied the recommendation in comment #2 on that above issue, replacing the DEFAULT_CFLAGS definition before the last sed at the bottom of multilib_src_configure() by: local DEFAULT_CFLAGS=$(grep ^CFLAGS= Makefile | LC_ALL=C sed \ -e 's:^CFLAGS=::' \ -e 's:\(^\| \)-fomit-frame-pointer::g' \ -e 's:\(^\| \)-O[^ ]*::g' \ -e 's:\(^\| \)-march=[^ ]*::g' \ -e 's:\(^\| \)-mcpu=[^ ]*::g' \ -e 's:\(^\| \)-m[^ ]*::g' \ -e 's:^ *::' \ -e 's: *$::' \ -e 's: \+: :g' \ -e 's:\\:\\\\:g' )
One last thing (sorry for the email flood everyone following this issue), the ebuilds I took for this were the latest ones in https://github.com/gentoo/gentoo/tree/master/dev-libs/openssl (modulo patching for issue 671016) and https://github.com/gentoo/gentoo/tree/master/net-libs/nodejs which I assumed is what you meant when you said *our* ebuilds since you committed them recently. I don't know what you meant when you said not to set any api* USE flag for openssl. For completeness, here were my USE for openssl in this case: CPU_FLAGS_X86="(sse2)" USE="asm zlib -bindist -rfc3779 -sctp -static-libs -test -tls-heartbeat -vanilla (-sslv3%)" (the test USE flag was enabled on nodejs, obviously)
All good, I requested those tests... that's no SPAM :) When I asked for api* USE flags I mixed version with an ebuild from Polynomial-C overlay where he added these USE flags to support testing of packages against a specific API. From OpenSSL 1.1.0 release notes: > Deprecated interfaces can now be disabled at build time either relative to the latest release via the "no-deprecated" Configure argument, or via the "--api=1.1.0|1.0.0|0.9.8" option. So I hoped for a moment that nodejs was failing because other testers were forcing nodejs to use API=1.1.0 or newer but because we still allow usage of previous API as long as they are present in OpenSSL there was a slight chance that it could work in Gentoo... but your testing revealed that this is a NodeJS problem (really interesting that NodeJS works with OpenSSL 1.1.0 but breaks so much with 1.1.1). Could you please test a last version for me? =net-libs/nodejs-9.11.2 seems to be the last version which compiles against openssl-1.0.x and >=1.1.x. Would be interesting to know if this version is passing runtime tests somehow. But it looks like we have to support openssl-1.1.0 and 1.1.1 in Gentoo for a while...
openssl-related tests with =net-libs/nodejs-9.11.2 * fail with openssl-1.1.1-r3 in the same fashion as with 10.13.0 * succeed mostly with openssl-1.1.0i-r3 (a single openssl-related test fails for me, seems related to decrypting the key for a certificate when it's protected with a passphrase, in case you're building a TLS server). There's still the solution I suggested in Comment #3 and Comment #4 if you're open to it. That would let nodejs use whatever bundled openssl version they're compatible with until they iron out their last remaning issues, without preventing the rest of a user's system from using a later openssl version and its benefits if desired.
Thanks for testing. For me, bundling OpenSSL library isn't an option. It is a nightmare from security point of view. In the end, maintainer has to decide but I doubt that Jeroen likes the idea (we will see). For now I will rollback openssl version constrain I removed in commit 64bc534bf4412e0088839c628ff79fa456ae60bb.
My understanding is that bundling openssl would mean that openssl gets statically linked into the resulting node binary. Running ldd on node verifies that there's no shared openssl usage if we let nodejs bundle its own. So this would at least mitigate the risk of another binary in the system using nodejs' openssl version or vice-versa. The downside I see would be on vulnerability management: in case a vulnerability needs to be addressed in nodejs' bundled openssl version, we'd need to count on them for patching their bundled version quickly, and for Gentoo to keep an eye on nodejs release so ebuilds can come quickly after. Considering the size of nodejs' community, I'm not worried about their ability to patch fast. And since the impact of their included openssl seems limited to nodejs (and they have to support it as they currently do) without impacting the rest of the system, this seems manageable. What am I missing?
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=e578686bca187ee1e8bbc5a41d0439aa47532c59 commit e578686bca187ee1e8bbc5a41d0439aa47532c59 Author: Jeroen Roovers <jer@gentoo.org> AuthorDate: 2018-11-21 16:05:34 +0000 Commit: Jeroen Roovers <jer@gentoo.org> CommitDate: 2018-11-21 16:06:15 +0000 net-libs/nodejs: Revision bumps 1. The dev-libs/openssl change broke crypto functions, so everyone affected needs to recompile and record proper deps again. 2. The net-dns/c-ares dependency needs a revision bump, too. Bug: https://bugs.gentoo.org/670574 Package-Manager: Portage-2.3.52, Repoman-2.3.12 Signed-off-by: Jeroen Roovers <jer@gentoo.org> net-libs/nodejs/{nodejs-10.13.0.ebuild => nodejs-10.13.0-r1.ebuild} | 0 net-libs/nodejs/{nodejs-11.2.0.ebuild => nodejs-11.2.0-r1.ebuild} | 0 net-libs/nodejs/{nodejs-8.13.0.ebuild => nodejs-8.13.0-r1.ebuild} | 0 net-libs/nodejs/{nodejs-9.11.2.ebuild => nodejs-9.11.2-r1.ebuild} | 2 +- 4 files changed, 1 insertion(+), 1 deletion(-) https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=7aff0f0339d3bdeb6fc22975d54f960a62be7528 commit 7aff0f0339d3bdeb6fc22975d54f960a62be7528 Author: Jeroen Roovers <jer@gentoo.org> AuthorDate: 2018-11-21 15:41:26 +0000 Commit: Jeroen Roovers <jer@gentoo.org> CommitDate: 2018-11-21 16:06:15 +0000 net-libs/nodejs: Revert dev-libs/openssl-1.1* dep change With openssl-1.1.1a I see lots and lots of test failures that I do not see with 1.1.0* -- these reflect actual errors in using crypto functions. While there, resolve an implicit dependency on net-dns/c-ares that was missed in the 8, 9, 10 and 11 branch version bumps. Fixes: 64bc534bf4412e0088839c628ff79fa456ae60bb Bug: https://bugs.gentoo.org/670574 Package-Manager: Portage-2.3.52, Repoman-2.3.12 Signed-off-by: Jeroen Roovers <jer@gentoo.org> net-libs/nodejs/nodejs-10.13.0.ebuild | 2 +- net-libs/nodejs/nodejs-11.2.0.ebuild | 5 +++-- net-libs/nodejs/nodejs-8.13.0.ebuild | 3 ++- net-libs/nodejs/nodejs-9.11.2.ebuild | 3 ++- net-libs/nodejs/nodejs-99999999.ebuild | 3 ++- 5 files changed, 10 insertions(+), 6 deletions(-)
(In reply to Guillaume Ceccarelli from comment #2) > The problem is that nodejs itself isn't compatible with openssl 1.1.1, but > is compatible with openssl 1.1.0. Correct, so I don't see what comment #5 was trying for. > If you try to compile nodejs with FEATURES="test" enabled, about 65 > openssl-related tests fail when using openssl 1.1.1. Worse still, it would break people's applications and not just tests. > Nodejs has an issue open for this: > https://github.com/nodejs/node/issues/18770 Thanks for the pointer, but do assume that this will likely trickle back into upstream LTS/Gentoo stable rather slowly. @Lars: I don't know what to do with this bug report now. There appears to be no tracker, so I am unsure whether to CANTFIX or INVALID or UPSTREAM or leave it open until upstream finally implements it. Should I be fixing their incompatibilities instead? Or should dev-libs/openssl be configured with old API compatibility through --api=<...>?
(In reply to Jeroen Roovers from comment #17) > > @Lars: I don't know what to do with this bug report now. There appears to be > no tracker, so I am unsure whether to CANTFIX or INVALID or UPSTREAM or > leave it open until upstream finally implements it. Should I be fixing their > incompatibilities instead? Or should dev-libs/openssl be configured with old > API compatibility through --api=<...>? openssl-1.1.0 is no LTS version and thus I'd like to get rid of openssl-1.1.0* ebuilds in favor of openssl-1.1.1* ASAP to reduce our (base-system team) workload.
*** Bug 671638 has been marked as a duplicate of this bug. ***
(In reply to Jeroen Roovers from comment #17) > I don't know what to do with this bug report now. There appears to be > no tracker, so I am unsure whether to CANTFIX or INVALID or UPSTREAM or > leave it open until upstream finally implements it. Should I be fixing their > incompatibilities instead? Or should dev-libs/openssl be configured with old > API compatibility through --api=<...>? 1) Looks like you misunderstood OpenSSL's "--api" parameter. It only controls *the deprecation level*. To quote from 1.1.0 release notes: > In environments in which all applications have been ported to > not use any deprecated interfaces OpenSSL's Configure script > should be used with the --api=1.1.0 option to entirely remove > support for the deprecated features from the library and > unconditionally disable them in the installed headers. > Essentially the same effect can be achieved with the "no-deprecated" > argument to Configure, except that this will always restrict > the build to just the latest API, rather than a fixed API > version. 2) If you can because there's a patch or you know how to fix it on your own, please fix it. But nobody is expecting that you can do that. :) 3) To proceed with this bug please decide if you want to keep what you are doing with nodejs-9.x, e.g. set only a lower version constrain even if you know that compilation will succeed but tests will fail (which indicates that you can expect real runtime errors) _or_ if you care about runtime. In this case you also have to set an upper version constrain (in case of 10.x and 11.x you would have to keep =dev-libs/openssl-1.1.0* like previous set because these versions don't compile with <openssl-1.1.0 and show same runtime failures with >=openssl-1.1.1).
Created attachment 555896 [details, diff] nodejs-10.13.0-openssl-compat.patch I adapted Shigeki Ohtsu's work (nodejs contributor working on the openssl 1.1.1 upgrade) from https://github.com/shigeki/node/tree/WIP_upgrade_openssl111_tls12_only and came up with this patch. It fixes the issue for me on 10.13.0 by making node compatible with OpenSSL 1.1.1. Tests pass, and I can probably do something similar for 11.2.0. Note that TLS 1.3 won't work, but then again, it didn't work before either. My changes include removing the modifications on deps/openssl itself (the full openssl lib code that nodejs embeds in their own repo, i.e. the one that's used if you don't pass --shared-openssl to their configure script, which was my original suggestion) and some adaptations to fit the existing code (I suspect Shikegi branched from the project's master or in any case a version more recent than 10.13, hence the need to make minor adaptations on the code that evolved since then).
Created attachment 555900 [details, diff] nodejs-10.13.0-openssl-compat.patch Added the corresponding documentation diff on doc/api/tls.md to the patch.
Created attachment 555902 [details, diff] nodejs-11.2.0-openssl-compat.patch patch for nodejs-11.2.0
(In reply to Thomas Deutschmann from comment #20) > 3) To proceed with this bug please decide if you want to keep what you are > doing with nodejs-9.x, e.g. set only a lower version constrain even if you > know that compilation will succeed but tests will fail (which indicates that > you can expect real runtime errors) _or_ if you care about runtime. In this > case you also have to set an upper version constrain (in case of 10.x and > 11.x you would have to keep =dev-libs/openssl-1.1.0* like previous set > because these versions don't compile with <openssl-1.1.0 and show same > runtime failures with >=openssl-1.1.1).
I created a PR https://github.com/gentoo/gentoo/pull/10567 with the patches provided at https://bugs.gentoo.org/670574#c22 and https://bugs.gentoo.org/670574#c23 Unfortunately, both nodejs-10.14.0 and nodejs-11.3.0 both fail on the same test (test-http-max-http-headers.js) with this error: --- === release test-http-max-http-headers === Path: sequential/test-http-max-http-headers assert.js:127 throw err; ^ AssertionError [ERR_ASSERTION]: () => {} at /var/tmp/portage/net-libs/nodejs-10.14.0/work/node-v10.14.0/test/sequential/test-http-max-http-headers.js:89 at ClientRequest.mustNotCall (/var/tmp/portage/net-libs/nodejs-10.14.0/work/node-v10.14.0/test/common/index.js:406:12) at Object.onceWrapper (events.js:273:13) at ClientRequest.emit (events.js:182:13) at HTTPParser.parserOnIncomingClient [as onIncoming] (_http_client.js:555:21) at HTTPParser.parserOnHeadersComplete (_http_common.js:109:17) at Socket.socketOnData (_http_client.js:441:20) at Socket.emit (events.js:182:13) at addChunk (_stream_readable.js:283:12) at readableAddChunk (_stream_readable.js:264:11) at Socket.Readable.push (_stream_readable.js:219:10) Command: out/Release/node /var/tmp/portage/net-libs/nodejs-10.14.0/work/node-v10.14.0/test/sequential/test-http-max-http-headers.js [02:53|% 100|+ 2174|- 1]: Done * ERROR: net-libs/nodejs-10.14.0::gentoo failed (test phase): * (no error message) * * Call stack: * ebuild.sh, line 124: Called src_test * environment, line 3544: Called die * The specific snippet of code: * "${PYTHON}" tools/test.py --mode=${BUILDTYPE,,} -J message parallel sequential || die --- I'm using dev-libs/openssl-1.1.1a
(In reply to Craig Andrews from comment #25) > I created a PR https://github.com/gentoo/gentoo/pull/10567 with the patches > provided at https://bugs.gentoo.org/670574#c22 and > https://bugs.gentoo.org/670574#c23 > > Unfortunately, both nodejs-10.14.0 and nodejs-11.3.0 both fail on the same > test (test-http-max-http-headers.js) with this error: > --- > === release test-http-max-http-headers === > > Path: sequential/test-http-max-http-headers > assert.js:127 > throw err; > ^ > > AssertionError [ERR_ASSERTION]: () => {} at > /var/tmp/portage/net-libs/nodejs-10.14.0/work/node-v10.14.0/test/sequential/ > test-http-max-http-headers.js:89 > at ClientRequest.mustNotCall > (/var/tmp/portage/net-libs/nodejs-10.14.0/work/node-v10.14.0/test/common/ > index.js:406:12) > at Object.onceWrapper (events.js:273:13) > at ClientRequest.emit (events.js:182:13) > at HTTPParser.parserOnIncomingClient [as onIncoming] > (_http_client.js:555:21) > at HTTPParser.parserOnHeadersComplete (_http_common.js:109:17) > at Socket.socketOnData (_http_client.js:441:20) > at Socket.emit (events.js:182:13) > at addChunk (_stream_readable.js:283:12) > at readableAddChunk (_stream_readable.js:264:11) > at Socket.Readable.push (_stream_readable.js:219:10) > Command: out/Release/node > /var/tmp/portage/net-libs/nodejs-10.14.0/work/node-v10.14.0/test/sequential/ > test-http-max-http-headers.js > [02:53|% 100|+ 2174|- 1]: Done > > * ERROR: net-libs/nodejs-10.14.0::gentoo failed (test phase): > * (no error message) > * > * Call stack: > * ebuild.sh, line 124: Called src_test > * environment, line 3544: Called die > * The specific snippet of code: > * "${PYTHON}" tools/test.py --mode=${BUILDTYPE,,} -J message parallel > sequential || die > --- > > I'm using dev-libs/openssl-1.1.1a This new test failure should be unrelated to openssl but instead, should be related to the new nodejs revisions themselves. I'm getting the same test failure as you do, irrespective of openssl versions, and including when I use the openssl dependency that comes bundled with nodejs itself (the one that gets statically linked-in if one doesn't pass --shared-openssl at configure time)
Created attachment 557092 [details, diff] nodejs-10.14.0-openssl-compat.patch New compatibility patch for v10.x, based on latest upstream efforts. With the additional benefit of containing fewer changes than previously.
Created attachment 557094 [details, diff] nodejs-11.3.0-openssl-compat.patch New compatibility patch for v11.x, based on latest upstream efforts. With the additional benefit of containing fewer changes than previously.
I just tried these latest patches and I updated the PR with them as well. 10.14.0 fails to build with this error: --- /usr/lib/gcc/x86_64-pc-linux-gnu/8.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: cannot find -lhttp_parser collect2: error: ld returned 1 exit status make: *** [deps/v8/gypfiles/torque.host.mk:324: /var/tmp/portage/net-libs/nodejs-10.14.0/work/node-v10.14.0/out/Release/torque] Error 1 rm 24732aaff99cf29486a4df5a85e2642f2b821f9d.intermediate make: Leaving directory '/var/tmp/portage/net-libs/nodejs-10.14.0/work/node-v10.14.0/out' * ERROR: net-libs/nodejs-10.14.0::gentoo failed (compile phase): --- 11.3.0 fails in the same way: --- /usr/lib/gcc/x86_64-pc-linux-gnu/8.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: cannot find -lhttp_parser collect2: error: ld returned 1 exit status make: *** [deps/v8/gypfiles/torque.host.mk:162: /var/tmp/portage/net-libs/nodejs-11.3.0/work/node-v11.3.0/out/Release/torque] Error 1 rm 15616d252e84afa89c4e70bc34f6cd783df010d2.intermediate make: Leaving directory '/var/tmp/portage/net-libs/nodejs-11.3.0/work/node-v11.3.0/out' ---
*facepalm* ignore my previous comment.
Tested 10.14.0 and 11.3.0 with the new patches; they fail with the same errors as comment 25. But, based on comment 26, maybe that's not that bad :) Therefore, is the thinking that this is now ready for merging to the Gentoo tree? On another note, I couldn't find anything in https://github.com/nodejs/node/issues/ regarding the test/sequential/test-http-max-http-headers.js test failure; has this issue been reported?
(In reply to Craig Andrews from comment #31) > On another note, I couldn't find anything in > https://github.com/nodejs/node/issues/ regarding the > test/sequential/test-http-max-http-headers.js test failure; has this issue > been reported? I think the new test failure is the changes related to this commit: https://github.com/nodejs/node/commit/74e01d0020ec255673e17353a1004a8ea375fff4 not being present in: https://github.com/nodejs/http-parser/blob/master/http_parser.gyp Stock nodejs isn't affected (their tests pass for themselves) because they're bundling the parser lib with nodejs itself, as opposed to using the lib as a shared object on the user's operating system. Some related upstream http-parser PRs for reference if anyone feels like creating a Gentoo issue for that specific problem: * https://github.com/nodejs/http-parser/pull/452 * https://github.com/nodejs/http-parser/pull/453 And the PR for upstream nodejs itself: * https://github.com/nodejs/node/pull/24716
As a matter of fact, I think the commits and PRs I just mentioned might be related to CVE-2018-12121, which is tracked here https://bugs.gentoo.org/672136 . If confirmed, that'd mean Gentoo's http-parser package needs patching ( or waiting for upstream to do something about the PRs referenced within Comment #32 ) , or that the nodejs ebuild should use node's bundled http-parser dependency since the fix is already there.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=b477dde03dd2e8a3fdcf3a525e7bc27ecc38651b commit b477dde03dd2e8a3fdcf3a525e7bc27ecc38651b Author: Jeroen Roovers <jer@gentoo.org> AuthorDate: 2019-01-31 12:30:02 +0000 Commit: Jeroen Roovers <jer@gentoo.org> CommitDate: 2019-01-31 12:49:40 +0000 net-libs/nodejs: Version 11.9.0 Package-Manager: Portage-2.3.59, Repoman-2.3.12 Bug: https://bugs.gentoo.org/show_bug.cgi?id=670574 Signed-off-by: Jeroen Roovers <jer@gentoo.org> net-libs/nodejs/Manifest | 1 + net-libs/nodejs/nodejs-11.9.0.ebuild | 210 +++++++++++++++++++++++++++++++++++ profiles/package.mask | 5 + 3 files changed, 216 insertions(+)
According to node's changelog (https://github.com/nodejs/node/blob/master/doc/changelogs/CHANGELOG_V11.md#11.9.0), node 11 is working with openssl-1.1.0j. I tried to use nodejs-11.10.1 with openssl-1.1.0j and it works.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=3bd093ca276717a318818f5145df28aebc441458 commit 3bd093ca276717a318818f5145df28aebc441458 Author: Jeroen Roovers <jer@gentoo.org> AuthorDate: 2019-03-31 09:53:03 +0000 Commit: Jeroen Roovers <jer@gentoo.org> CommitDate: 2019-03-31 09:56:59 +0000 net-libs/nodejs: Adjust dev-libs/openssl version https://github.com/nodejs/node/blob/master/doc/changelogs/CHANGELOG_V11.md#notable-changes-5 Bug: https://bugs.gentoo.org/670574 Package-Manager: Portage-2.3.62, Repoman-2.3.12 Signed-off-by: Jeroen Roovers <jer@gentoo.org> net-libs/nodejs/nodejs-10.15.3.ebuild | 2 +- net-libs/nodejs/nodejs-99999999.ebuild | 4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-) https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=18d4e1f6cf11b31dd64cef490c04ec5f0218294e commit 18d4e1f6cf11b31dd64cef490c04ec5f0218294e Author: Jeroen Roovers <jer@gentoo.org> AuthorDate: 2019-03-31 09:47:32 +0000 Commit: Jeroen Roovers <jer@gentoo.org> CommitDate: 2019-03-31 09:56:59 +0000 profiles/package.mask: Drop =net-libs/nodejs-11* mask Bug: https://bugs.gentoo.org/670574 Signed-off-by: Jeroen Roovers <jer@gentoo.org> profiles/package.mask | 5 ----- 1 file changed, 5 deletions(-)
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=7946413d48cbfe39296a1665fab65cb2fcd7e087 commit 7946413d48cbfe39296a1665fab65cb2fcd7e087 Author: Jeroen Roovers <jer@gentoo.org> AuthorDate: 2019-04-24 09:22:43 +0000 Commit: Jeroen Roovers <jer@gentoo.org> CommitDate: 2019-04-24 09:24:39 +0000 net-libs/nodejs: Version 12.0.0 Package-Manager: Portage-2.3.64, Repoman-2.3.12 Bug: https://bugs.gentoo.org/670574 Signed-off-by: Jeroen Roovers <jer@gentoo.org> net-libs/nodejs/Manifest | 1 + net-libs/nodejs/nodejs-12.0.0.ebuild | 209 +++++++++++++++++++++++++++++++++++ profiles/package.mask | 5 + 3 files changed, 215 insertions(+)
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=144b5746dc7d9eda8069484f5bb0cbffbef8537f commit 144b5746dc7d9eda8069484f5bb0cbffbef8537f Author: Jeroen Roovers <jer@gentoo.org> AuthorDate: 2019-08-18 11:31:45 +0000 Commit: Jeroen Roovers <jer@gentoo.org> CommitDate: 2019-08-18 11:34:58 +0000 profiles/package.mask: Drop net-libs/nodejs mask Fixes: https://bugs.gentoo.org/show_bug.cgi?id=670574 Signed-off-by: Jeroen Roovers <jer@gentoo.org> profiles/package.mask | 7 ------- 1 file changed, 7 deletions(-)
