the electron does not build

[Dirli]

the electron does not build with ffmpeg-4 (the decision: to turn off the flag system-ffmpeg) or openssl-1.1.0. the logs are not preserved(

[Reinis]

There are patches for building electron with ffmpeg-4 at [1]. But it still fails to build the bundled nodejs with openssl-1.1.0.

[1] https://bugs.gentoo.org/672226

[Reinis]

AFAIK, openssl-1.1.0 is supported in nodejs-10 and latter, which is included in electron-4.0.0, but even recently released atom-1.33.1 supports only electron-2.0.16, so it will be still some time before this issue can be properly fixed unless someone backports openssl-1.1.0 patches for the bundled nodejs.

In the mean time electron ebuild should be updated to reflect its dependency on older openssl version.

I tried to pick the patches from nodejs upstream [1], but the last three patches mentioned there [2-4] were not quite enough.

[1] nodejs/node#8491
[2] nodejs/node@ec349b4
[3] nodejs/node@f00d758
[4] nodejs/node@c2106e4

[ghost]

But it still fails to build the bundled nodejs with openssl-1.1.0.

At least in Arch Linux land, they don't list any dependency on OpenSSL. So I believe the nodejs part is build without --shared-openssl, which in turn uses the bundled OpenSSL. That's how I've built electron in a LibreSSL environment.

Of course, building this way won't pass Gentoo's QA, and probably has some security implications. OTOH, the official binaries are also build this way, so as long you keep using the latest version, you'll be somewhat safe.

[ExecutorElassus]

has there been any change on this? electron is now the only package on my system that needs old openssl.

[elprans]

Moving on to 3.0 and later is the only reasonable way to fix this.

[Reinis]

Using the bundled openssl is also an option, which I'm using on my computer.

…

On Mon, Feb 25, 2019, 17:04 Elvis Pranskevichus ***@***.***> wrote: Moving on to 3.0 and later is the only reasonable way to fix this. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#35 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABMTRe2E0P1S2sgYL1r_vBtHFanH85Dpks5vQ_tvgaJpZM4Zk37U> .

[ExecutorElassus]

dumb question: how do you instruct electron to use bundled openssl?

[Reinis]

You have to edit the ebuild since there is no "system-openssl" USE flag at this time:

--- /var/lib/layman/atom/dev-util/electron/electron-2.0.17.ebuild	2019-02-03 16:33:35.499130151 +0200
+++ /usr/local/portage/dev-util/electron/electron-2.0.17.ebuild	2019-02-14 16:41:48.829035173 +0200
@@ -100,7 +100,6 @@
 	dev-libs/libxslt:=
 	dev-libs/nspr:=
 	>=dev-libs/nss-3.14.3:=
-	<dev-libs/openssl-1.1:0=
 	>=dev-libs/re2-0.2016.05.01:=
 	gconf? ( >=gnome-base/gconf-2.24.0:= )
 	gnome-keyring? ( >=gnome-base/libgnome-keyring-3.12:= )
@@ -688,7 +687,7 @@
 	# --shared-libuv cannot be used as electron's node fork
 	# patches uv_loop structure.
 	./configure --shared --without-bundled-v8 \
-		--shared-openssl --shared-http-parser --shared-zlib \
+		--shared-http-parser --shared-zlib \
 		--shared-nghttp2 --shared-cares \
 		--without-npm --with-intl=system-icu --without-dtrace \
 		--dest-cpu=${target_arch} --prefix="" || die

[ExecutorElassus]

that patch solved compilation for me, so I guess that'll be the workaround until upstream sorts it out. Thanks.

[Tatsh]

Will have to skip this package (and VS Code) for now since the Electron ebuild is requesting <openssl-1.1:0= (despite not building at this time and not actually using system openssl). More packages are asking for openssl:0/1.1 than the reverse. I hope to see the issue resolved with using system openssl as Gentoo upstream would never accept a vendored openssl in a source-based package.

[elprans]

The current versions of the :2.0 and :3.1 ebuilds have the "system-ssl" use flag to control the OpenSSL dependency.

[PF4Public]

Shouldn't -system-ssl be by default if there are such diffuculties with ssl and electron?