New package suggestion: jitsi-meet-electron

[darkbasic]

It would be nice to have an ebuild for the open source video conferencing software jitsi-meet-electron. There is already one available but it doesn't use system electron, so it ships binaries and it's basically useless on anything but x86.

[PF4Public]

All the ebuilds in my overlay are those which I personally use; thus it is rather trivial for me to verify their functionality. For this reason I tend not to pull other ebuilds in.

Do you use the proposed software? Will you be able from time to time to verify if it functions?

[darkbasic]

Do you use the proposed software? Will you be able from time to time to verify if it functions?

I use the jitsi-meet website mostly, but that's because I can't use the electron version on ppc64 yet.
With an ebuild which uses system electron I will definitely be able to test it from time to time to ensure it keeps working.

[PF4Public]

They seem to be using npm, which, compared to yarn, cannot be tricked to be using DISTDIR as a cache. Which means inability to build with active network sandbox.

[darkbasic]

Ouch... I thought you managed to solve the +network-sandbox issue but that was apparently only for yarn.
I've tried to migrate the lockfile to yarn (yarn migrate && yarn install) but yarn build fails. I've also tried yarn berry but it fails as well. I hate node.js in Gentoo so much :(

[darkbasic]

By the way, does the "DISTDIR as a cache" trick works with pnpm? If so we could try with that as well.

[PF4Public]

By the way, does the "DISTDIR as a cache" trick works with pnpm?

Absolutely no idea and I'm not willing to investigate pnpm further because:

[darkbasic]

I didn't manage to build it with pnpm anyway...

[PF4Public]

Well, even if there is no way of making it behave, creating ebuild for it would still be beneficial compared to building manually since the former provides some kind of automation and package management of sorts.

[darkbasic]

Yeah I guess we could also add per package -network-sandbox via package.env.

[darkbasic]

I was looking at the element-desktop ebuild to figure out how to possibly build this and the first difference I've noticed is that jitsi-meet-electron also runs electron-builder install-app-deps (https://github.com/jitsi/jitsi-meet-electron/blob/master/package.json#L14), which obviously fails:

niko@talos2 ~/devel/jitsi-meet-electron $ npm install

> jitsi-meet-electron@2022.11.0 postinstall
> patch-package && electron-builder install-app-deps

patch-package 6.2.2
Applying patches...
No patch files found
electron-builder install-app-deps

Install app deps

Options:
  --version   Show version number                                      [boolean]
  --help      Show help                                                [boolean]
  --platform  The target platform
                        [choices: "linux", "darwin", "win32"] [default: "linux"]
  --arch      The target arch
           [choices: "ia32", "x64", "armv7l", "arm64", "all"] [default: "ppc64"]

Invalid values:
  Argument: arch, Given: "ppc64", Choices: "ia32", "x64", "armv7l", "arm64", "all"

Any idea how to work it around?

[PF4Public]

Could it be due to arch "ppc64". Maybe there are some platform-specific patches needed expected, which it cannot find.

Sorry, I was willing to check this package, but unfortunately till now had no time to spare at all :(

[PF4Public]

It might be possible that this package will require a similar hack as element-desktop on ppc64: #173

[PF4Public]

It just occurred to me that yarn can consume package-lock.json from npm and create yarn.lock out of it. This might be handy for trying yarn instead of npm.

[darkbasic]

Uhm... I'm pretty sure I've tried that route already and it didn't work either.

[PF4Public]

They might've improved the logic since then, so maybe worth another shot.