Needed by newer kibana, thanks.
2020-06-02, Version 10.21.0 'Dubnium' (LTS), @BethGriggs Notable changes This is a security release. Vulnerabilities fixed: CVE-2020-8174: napi_get_value_string_*() allows various kinds of memory corruption (High). CVE-2020-10531: ICU-20958 Prevent SEGV_MAPERR in append (High). CVE-2020-11080: HTTP/2 Large Settings Frame DoS (Low). Commits [0ad7970256] - deps: fix OPENSSLDIR on Windows (Shigeki Ohtsu) #29456 [bd78c6ea46] - deps: backport ICU-20958 to fix CVE-2020-10531 (Richard Lau) #33572 [33e9a12241] - (SEMVER-MINOR) deps: update nghttp2 to 1.41.0 (James M Snell) nodejs-private/node-private#204 [881c244a4e] - (SEMVER-MINOR) http2: implement support for max settings entries (James M Snell) nodejs-private/node-private#204 [cd9827f105] - napi: fix memory corruption vulnerability (Tobias Nießen) nodejs-private/node-private#203
This builds fine on amd64: --- /usr/portage/net-libs/nodejs/nodejs-10.20.1.ebuild 2020-04-12 15:09:43.000000000 +0000 +++ nodejs-10.21.0.ebuild 2020-06-22 07:49:02.558185889 +0000 @@ -24,7 +24,7 @@ >=dev-libs/libuv-1.34.2:= >=net-dns/c-ares-1.15.0 >=net-libs/http-parser-2.9.3:= - >=net-libs/nghttp2-1.39.2 + >=net-libs/nghttp2-1.41.0 sys-libs/zlib icu? ( >=dev-libs/icu-64.2:= ) system-ssl? ( >=dev-libs/openssl-1.1.1:0= )
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=09bb6e5a78dcc24648accd1f60c8ff8e66c827b3 commit 09bb6e5a78dcc24648accd1f60c8ff8e66c827b3 Author: Tomáš Mózes <hydrapolic@gmail.com> AuthorDate: 2020-06-26 18:12:33 +0000 Commit: Thomas Deutschmann <whissi@gentoo.org> CommitDate: 2020-06-26 22:59:49 +0000 net-libs/nodejs: bump to 10.21.0 Closes: https://bugs.gentoo.org/729096 Signed-off-by: Tomáš Mózes <hydrapolic@gmail.com> Signed-off-by: Thomas Deutschmann <whissi@gentoo.org> net-libs/nodejs/Manifest | 1 + net-libs/nodejs/nodejs-10.21.0.ebuild | 205 ++++++++++++++++++++++++++++++++++ 2 files changed, 206 insertions(+)
I am considering dropping everything but the LTS and current branches, but there you went and committed something else.
(In reply to Tomáš Mózes from comment #0) > Needed by newer kibana, thanks. Does it need the 10 branch exactly?
I know that version 10 is in maintenance mode, but it's an LTS and kibana uses it too. Since our devs are still on version 10 too, I'm keeping version 10 everywhere (for our apps and kibana too). Kibana bundles version 10: https://github.com/elastic/kibana/blob/master/package.json#L511 If we remove it, I'll have to include the bundled version. Can we please keep version 10 in portage (even just in ~arch) until there are new releases for it? Thanks
(In reply to Tomáš Mózes from comment #6) > I know that version 10 is in maintenance mode, but it's an LTS and kibana > uses it too. Since our devs are still on version 10 too, I'm keeping version > 10 everywhere (for our apps and kibana too). > > Kibana bundles version 10: > https://github.com/elastic/kibana/blob/master/package.json#L511 But the kibana-bin ebuilds set no such restriction on the branch: ebuildvar RDEPEND |grep nodejs kibana-bin-6.8.8.ebuild : RDEPEND -=- >=net-libs/nodejs-10.15.2 kibana-bin-7.6.2.ebuild : RDEPEND -=- >=net-libs/nodejs-10.15.2 kibana-bin-7.7.0.ebuild : RDEPEND -=- >=net-libs/nodejs-10.19.0 kibana-bin-7.8.0.ebuild : RDEPEND -=- >=net-libs/nodejs-10.21.0 > If we remove it, I'll have to include the bundled version. I don't see a problem there. It's a non-source distribution already. > Can we please keep version 10 in portage (even just in ~arch) until there > are new releases for it? Thanks Well, we can review and discuss it and keep this bug open for that purpose, I guess.
(In reply to Jeroen Roovers from comment #7) > (In reply to Tomáš Mózes from comment #6) > > I know that version 10 is in maintenance mode, but it's an LTS and kibana > > uses it too. Since our devs are still on version 10 too, I'm keeping version > > 10 everywhere (for our apps and kibana too). > > > > Kibana bundles version 10: > > https://github.com/elastic/kibana/blob/master/package.json#L511 > > But the kibana-bin ebuilds set no such restriction on the branch: > > ebuildvar RDEPEND |grep nodejs > kibana-bin-6.8.8.ebuild : RDEPEND -=- >=net-libs/nodejs-10.15.2 > kibana-bin-7.6.2.ebuild : RDEPEND -=- >=net-libs/nodejs-10.15.2 > kibana-bin-7.7.0.ebuild : RDEPEND -=- >=net-libs/nodejs-10.19.0 > kibana-bin-7.8.0.ebuild : RDEPEND -=- >=net-libs/nodejs-10.21.0 Kibana may work with newer nodejs versions, but we had reports from the past that some plugins were broken afterwards. That's why I set the version from the release, but accept newer too if it works for someone. > > > If we remove it, I'll have to include the bundled version. > > I don't see a problem there. It's a non-source distribution already. > > > Can we please keep version 10 in portage (even just in ~arch) until there > > are new releases for it? Thanks > > Well, we can review and discuss it and keep this bug open for that purpose, > I guess. If you don't want to keep up version 10, I can do the version bumps (keeping just ~arch). I think it's better to have a single version in portage than a few in random overlays.
Closing as it's in tree. Jeroen, feel free to ping me about the 10.x branch in Gentoo.
