Hi,
there are several packages in the distribution which require FFMPEG (libavformat, libavcodec, etc.), one of them being chromium. The package could be created in a way that you can easily replace it with a version from rpmfusion to get to the full encoder/decoder set including H264 etc.
This is working fine with openSUSE and packages from Packman.
https://build.opensuse.org/package/show/multimedia:libs/ffmpeg-4 https://pmbs.links2linux.org/package/show/Essentials/A_tw-ffmpeg
The Packman version always has a higher release version than the one in the distribution.
I'm interested in this, as I try to package electron for Fedora. The big problem is the included ffmpeg. With openSUSE I can just use the system ffmpeg, with Fedora I have to do some source code voodoo which I really would like to avoid.
Thanks for considering!
Best regards
Andreas
On Monday, 08 November 2021 at 10:12, Andreas Schneider wrote:
Hi,
there are several packages in the distribution which require FFMPEG (libavformat, libavcodec, etc.), one of them being chromium. The package could be created in a way that you can easily replace it with a version from rpmfusion to get to the full encoder/decoder set including H264 etc.
This is working fine with openSUSE and packages from Packman.
https://build.opensuse.org/package/show/multimedia:libs/ffmpeg-4 https://pmbs.links2linux.org/package/show/Essentials/A_tw-ffmpeg
The Packman version always has a higher release version than the one in the distribution.
I'm interested in this, as I try to package electron for Fedora. The big problem is the included ffmpeg. With openSUSE I can just use the system ffmpeg, with Fedora I have to do some source code voodoo which I really would like to avoid.
Maintaining such package would require keeping watch for any new files you'd need to include and going through legal review each time you do.
IMO it's much less work to just maintain everything that depends on FFmpeg in RPM Fusion.
If you're determined, however, you could start with what Chromium does: https://src.fedoraproject.org/rpms/chromium/blob/rawhide/f/clean_ffmpeg.sh
Feel free to flag me for package review. I one of the maintainers of the ffmpeg package in RPM Fusion.
Regards, Dominik
On Monday, November 8, 2021 10:55:32 AM CET Dominik 'Rathann' Mierzejewski wrote:
On Monday, 08 November 2021 at 10:12, Andreas Schneider wrote:
Hi,
there are several packages in the distribution which require FFMPEG (libavformat, libavcodec, etc.), one of them being chromium. The package could
be created in a way that you can easily replace it with a version
from rpmfusion to get to the full encoder/decoder set including H264 etc.
This is working fine with openSUSE and packages from Packman.
https://build.opensuse.org/package/show/multimedia:libs/ffmpeg-4 https://pmbs.links2linux.org/package/show/Essentials/A_tw-ffmpeg
The Packman version always has a higher release version than the one in the
distribution.
I'm interested in this, as I try to package electron for Fedora. The big problem is the included ffmpeg. With openSUSE I can just use the system ffmpeg, with Fedora I have to do some source code voodoo which I really would
like to avoid.
Maintaining such package would require keeping watch for any new files you'd need to include and going through legal review each time you do.
Did you take a look how they solved it at SUSE?
You have list for encoder and decoders which are allowed to be built. So if a new encoder or decoder would be added, it would just not be built. You will just always end up with the same set of encoders/decoders with every update.
Packman uses the exact same package as openSUSE and all it does it to enable all encoders and decoders.
All packages requiring ffmpeg can just always be built against the system version.
It should be less legal work, as you have to check just one package and not several which might include it as third_party source code.
IMO it's much less work to just maintain everything that depends on FFmpeg in RPM Fusion.
If you're determined, however, you could start with what Chromium does: https://src.fedoraproject.org/rpms/chromium/blob/rawhide/f/clean_ffmpeg.sh
How is it less work if you need to clean ffmpeg source codes in several projects which include it instead of just linking the system one? It is more prone to errors to remove sources and you have to track it instead of just having a fixed decoder/encoder set you build.
Feel free to flag me for package review. I
Best regards
Andreas
On Mon, Nov 8, 2021 at 11:51 AM Andreas Schneider asn@redhat.com wrote:
On Monday, November 8, 2021 10:55:32 AM CET Dominik 'Rathann' Mierzejewski wrote:
On Monday, 08 November 2021 at 10:12, Andreas Schneider wrote:
Hi,
there are several packages in the distribution which require FFMPEG (libavformat, libavcodec, etc.), one of them being chromium. The package could
be created in a way that you can easily replace it with a version
from rpmfusion to get to the full encoder/decoder set including H264 etc.
This is working fine with openSUSE and packages from Packman.
https://build.opensuse.org/package/show/multimedia:libs/ffmpeg-4 https://pmbs.links2linux.org/package/show/Essentials/A_tw-ffmpeg
The Packman version always has a higher release version than the one in the
distribution.
I'm interested in this, as I try to package electron for Fedora. The big problem is the included ffmpeg. With openSUSE I can just use the system ffmpeg, with Fedora I have to do some source code voodoo which I really would
like to avoid.
Maintaining such package would require keeping watch for any new files you'd need to include and going through legal review each time you do.
Did you take a look how they solved it at SUSE?
You have list for encoder and decoders which are allowed to be built. So if a new encoder or decoder would be added, it would just not be built. You will just always end up with the same set of encoders/decoders with every update.
Packman uses the exact same package as openSUSE and all it does it to enable all encoders and decoders.
All packages requiring ffmpeg can just always be built against the system version.
It should be less legal work, as you have to check just one package and not several which might include it as third_party source code.
IMO it's much less work to just maintain everything that depends on FFmpeg in RPM Fusion.
If you're determined, however, you could start with what Chromium does: https://src.fedoraproject.org/rpms/chromium/blob/rawhide/f/clean_ffmpeg.sh
How is it less work if you need to clean ffmpeg source codes in several projects which include it instead of just linking the system one? It is more prone to errors to remove sources and you have to track it instead of just having a fixed decoder/encoder set you build.
It's not the point that it's easier.
If I understand correctly, any official ffmpeg package distributed by Fedora would not be allowed to contain even the *source code* for patent-encumbered or redistribution-limited codecs in its source package (because those sources are redistributed too). So the only way to achieve that would be to use "clean" tarballs - and a hardcoded list of "allowed codecs to build" alone is not enough to satisfy that requirement.
Fabio
On Monday, 08 November 2021 at 12:01, Fabio Valentini wrote:
On Mon, Nov 8, 2021 at 11:51 AM Andreas Schneider asn@redhat.com wrote:
On Monday, November 8, 2021 10:55:32 AM CET Dominik 'Rathann' Mierzejewski wrote:
On Monday, 08 November 2021 at 10:12, Andreas Schneider wrote:
Hi,
there are several packages in the distribution which require FFMPEG (libavformat, libavcodec, etc.), one of them being chromium. The package could
be created in a way that you can easily replace it with a version
from rpmfusion to get to the full encoder/decoder set including H264 etc.
This is working fine with openSUSE and packages from Packman.
https://build.opensuse.org/package/show/multimedia:libs/ffmpeg-4 https://pmbs.links2linux.org/package/show/Essentials/A_tw-ffmpeg
The Packman version always has a higher release version than the one in the
distribution.
I'm interested in this, as I try to package electron for Fedora. The big problem is the included ffmpeg. With openSUSE I can just use the system ffmpeg, with Fedora I have to do some source code voodoo which I really would
like to avoid.
Maintaining such package would require keeping watch for any new files you'd need to include and going through legal review each time you do.
Did you take a look how they solved it at SUSE?
You have list for encoder and decoders which are allowed to be built. So if a new encoder or decoder would be added, it would just not be built. You will just always end up with the same set of encoders/decoders with every update.
Packman uses the exact same package as openSUSE and all it does it to enable all encoders and decoders.
All packages requiring ffmpeg can just always be built against the system version.
It should be less legal work, as you have to check just one package and not several which might include it as third_party source code.
IMO it's much less work to just maintain everything that depends on FFmpeg in RPM Fusion.
If you're determined, however, you could start with what Chromium does: https://src.fedoraproject.org/rpms/chromium/blob/rawhide/f/clean_ffmpeg.sh
How is it less work if you need to clean ffmpeg source codes in several projects which include it instead of just linking the system one? It is more prone to errors to remove sources and you have to track it instead of just having a fixed decoder/encoder set you build.
It's not the point that it's easier.
If I understand correctly, any official ffmpeg package distributed by Fedora would not be allowed to contain even the *source code* for patent-encumbered or redistribution-limited codecs in its source package (because those sources are redistributed too). So the only way to achieve that would be to use "clean" tarballs - and a hardcoded list of "allowed codecs to build" alone is not enough to satisfy that requirement.
That's what I meant although I haven't said so explicitly. The chromium script does what you've described.
Regards, Dominik
On Monday, 08 November 2021 at 11:51, Andreas Schneider wrote:
On Monday, November 8, 2021 10:55:32 AM CET Dominik 'Rathann' Mierzejewski wrote:
On Monday, 08 November 2021 at 10:12, Andreas Schneider wrote:
Hi,
there are several packages in the distribution which require FFMPEG (libavformat, libavcodec, etc.), one of them being chromium. The package could
be created in a way that you can easily replace it with a version
from rpmfusion to get to the full encoder/decoder set including H264 etc.
This is working fine with openSUSE and packages from Packman.
https://build.opensuse.org/package/show/multimedia:libs/ffmpeg-4 https://pmbs.links2linux.org/package/show/Essentials/A_tw-ffmpeg
The Packman version always has a higher release version than the one in the
distribution.
I'm interested in this, as I try to package electron for Fedora. The big problem is the included ffmpeg. With openSUSE I can just use the system ffmpeg, with Fedora I have to do some source code voodoo which I really would
like to avoid.
Maintaining such package would require keeping watch for any new files you'd need to include and going through legal review each time you do.
Did you take a look how they solved it at SUSE?
Actually, yes. We cannot do the same as we cannot distribute the full upstream source.
You have list for encoder and decoders which are allowed to be built. So if a new encoder or decoder would be added, it would just not be built. You will just always end up with the same set of encoders/decoders with every update.
Sometimes new dependencies get added to existing decoders/encoders which would require legal review.
Packman uses the exact same package as openSUSE and all it does it to enable all encoders and decoders.
All packages requiring ffmpeg can just always be built against the system version.
It should be less legal work, as you have to check just one package and not several which might include it as third_party source code.
Chromium was checked by legal. I'm not aware of any other Fedora packages bundling a subset of FFmpeg.
IMO it's much less work to just maintain everything that depends on FFmpeg in RPM Fusion.
If you're determined, however, you could start with what Chromium does: https://src.fedoraproject.org/rpms/chromium/blob/rawhide/f/clean_ffmpeg.sh
How is it less work if you need to clean ffmpeg source codes in several projects which include it instead of just linking the system one? It is more prone to errors to remove sources and you have to track it instead of just having a fixed decoder/encoder set you build.
I agree it would be better to have one system package that others would link against but as with everything, it's not always possible. You're welcome to try.
Regards, Dominik
On 11/8/21 13:37, Dominik 'Rathann' Mierzejewski wrote:
On Monday, 08 November 2021 at 11:51, Andreas Schneider wrote:
On Monday, November 8, 2021 10:55:32 AM CET Dominik 'Rathann' Mierzejewski wrote:
On Monday, 08 November 2021 at 10:12, Andreas Schneider wrote:
Hi,
there are several packages in the distribution which require FFMPEG (libavformat, libavcodec, etc.), one of them being chromium. The package could
be created in a way that you can easily replace it with a version
from rpmfusion to get to the full encoder/decoder set including H264 etc.
This is working fine with openSUSE and packages from Packman.
https://build.opensuse.org/package/show/multimedia:libs/ffmpeg-4 https://pmbs.links2linux.org/package/show/Essentials/A_tw-ffmpeg
The Packman version always has a higher release version than the one in the
distribution.
I'm interested in this, as I try to package electron for Fedora. The big problem is the included ffmpeg. With openSUSE I can just use the system ffmpeg, with Fedora I have to do some source code voodoo which I really would
like to avoid.
Maintaining such package would require keeping watch for any new files you'd need to include and going through legal review each time you do.
Did you take a look how they solved it at SUSE?
Actually, yes. We cannot do the same as we cannot distribute the full upstream source.
You have list for encoder and decoders which are allowed to be built. So if a new encoder or decoder would be added, it would just not be built. You will just always end up with the same set of encoders/decoders with every update.
Sometimes new dependencies get added to existing decoders/encoders which would require legal review.
Packman uses the exact same package as openSUSE and all it does it to enable all encoders and decoders.
All packages requiring ffmpeg can just always be built against the system version.
It should be less legal work, as you have to check just one package and not several which might include it as third_party source code.
Chromium was checked by legal. I'm not aware of any other Fedora packages bundling a subset of FFmpeg.
Firefox ships bundled ffmpeg with VP8/9 and maybe some other codecs.
On 08/11/2021 10:12, Andreas Schneider wrote:
I'm interested in this, as I try to package electron for Fedora.
Electron can't be build completely from sources without downloading pre-built binaries/blobs from npm.
On Mon, Nov 8, 2021 at 9:16 AM Vitaly Zaitsev via devel devel@lists.fedoraproject.org wrote:
On 08/11/2021 10:12, Andreas Schneider wrote:
I'm interested in this, as I try to package electron for Fedora.
Electron can't be build completely from sources without downloading pre-built binaries/blobs from npm.
This is not true anymore.
On 08/11/2021 15:25, Neal Gompa wrote:
This is not true anymore.
Have you tested the build without network access? Because even Flatpaks download everything from npm.
On Mon, Nov 8, 2021 at 9:34 AM Vitaly Zaitsev via devel devel@lists.fedoraproject.org wrote:
On 08/11/2021 15:25, Neal Gompa wrote:
This is not true anymore.
Have you tested the build without network access? Because even Flatpaks download everything from npm.
I've done an offline build with some prep work upfront, yes. It's not automatically a thing, but it is possible.
On 08/11/2021 15:35, Neal Gompa wrote:
I've done an offline build with some prep work upfront, yes.
Fully offline with rebuilding all JS dependencies from sources?
All minified JS blobs must be rebuild from sources on Fedora infra instead of downloading them from npm with direct links.
It's not automatically a thing, but it is possible.
Can you show the SPEC please?
On Mon, Nov 8, 2021 at 9:44 AM Vitaly Zaitsev via devel devel@lists.fedoraproject.org wrote:
On 08/11/2021 15:35, Neal Gompa wrote:
I've done an offline build with some prep work upfront, yes.
Fully offline with rebuilding all JS dependencies from sources?
All minified JS blobs must be rebuild from sources on Fedora infra instead of downloading them from npm with direct links.
It's not automatically a thing, but it is possible.
Can you show the SPEC please?
I haven't done it in the form of a spec file recently. It hasn't been worth my time to do that yet with other blockers. I don't have anything I can share at this time.
-- 真実はいつも一つ!/ Always, there's only one truth!
On Monday, November 8, 2021 3:43:37 PM CET Vitaly Zaitsev via devel wrote:
On 08/11/2021 15:35, Neal Gompa wrote:
I've done an offline build with some prep work upfront, yes.
Fully offline with rebuilding all JS dependencies from sources?
All minified JS blobs must be rebuild from sources on Fedora infra instead of downloading them from npm with direct links.
It's not automatically a thing, but it is possible.
Can you show the SPEC please?
I have electron building offline for Fedora, you can find it here:
https://build.opensuse.org/package/show/network:im:signal/nodejs-electron
Andreas Schneider wrote:
I have electron building offline for Fedora, you can find it here:
https://build.opensuse.org/package/show/network:im:signal/nodejs-electron
I see from the presence of electron-13-openh264-format-security.patch that you are building the bundled OpenH264. This is not going to be allowed on Fedora: only the openh264 repository provided by Cisco is allowed to distribute OpenH264 for Fedora due to how the H.264 patent license works. And as I understand it, you cannot even build against a system OpenH264 (because that repository is not enabled in the build system). The only packages that support OpenH264 within Fedora are those that can dlopen it at runtime, which Chromium cannot.
The build of openh264 is also controlled by enable_proprietary_codecs, which you unconditionally set to true. So your approach is not going to work on Fedora. In fact, you are not even supposed to include openh264 in the tarball at all. At least in qt5-qtwebengine, I added an rm -rf line to the tarball cleanup script that removes it (some time ago, back when upstream had added the bundled copy), I have not checked whether the chromium package does that too, but in any case, it should.
This is also another reason why just swapping out ffmpeg will not give you fully working support for patent-encumbered codecs, whereas the qt5- qtwebengine-freeworld approach (just rebuilding the whole thing) will. (qt5- qtwebengine-freeworld in RPM Fusion does include the bundled OpenH264, as there is nothing preventing shipping non-Cisco builds there, the copyright license is perfectly fine, it is the patent license that only applies to builds shipped by Cisco.) FFmpeg does not include a H.264 encoder at all. It has support for using an external libx264, but Chromium does not support using that libx264 support, nor using libx264 directly. Instead, Chromium relies on OpenH264 for encoding (probably because that ensures that the bitstream will only use features that are also supported by the OpenH264 decoder used by some other browsers, even though Chromium does not use the decoder from OpenH264, only the encoder). Hence, Chromium uses OpenH264 directly (for encoding), which is a compile-time decision based on enable_proprietary_codecs and not affected by replacing FFmpeg at all.
Kevin Kofler
On Monday, November 8, 2021 6:04:12 PM CET Kevin Kofler via devel wrote:
Andreas Schneider wrote:
I have electron building offline for Fedora, you can find it here:
https://build.opensuse.org/package/show/network:im:signal/nodejs-electron
I see from the presence of electron-13-openh264-format-security.patch that you are building the bundled OpenH264.
Oh, good catch. I've removed it from the source tarball and disabled it.
On 08/11/2021 16:47, Andreas Schneider wrote:
I have electron building offline for Fedora, you can find it here: https://build.opensuse.org/package/show/network:im:signal/nodejs-electron
Electron core packaging is a quite trivial task (Arch Linux and Debian have already done this), but what about Electron applications (VS Code for example)?
Most of them download tons of bundled JS blobs from npm during the build. I don't think it will be easy (or even possible) to build everything from sources.
Vitaly Zaitsev via devel devel@lists.fedoraproject.org writes:
On 08/11/2021 16:47, Andreas Schneider wrote:
I have electron building offline for Fedora, you can find it here: https://build.opensuse.org/package/show/network:im:signal/nodejs-electron
Electron core packaging is a quite trivial task (Arch Linux and Debian have already done this), but what about Electron applications (VS Code for example)?
They have? What's it called? Asking because I don't see it:
rharwood@eesha:~$ aptitude search electron | grep -v electronics p node-electron-to-chromium - Provides a list of electron-to-chromium version mappings rharwood@eesha:~$
Be well, --Robbie
Nov 9, 2021 9:06:58 AM Robbie Harwood rharwood@redhat.com:
Vitaly Zaitsev via devel devel@lists.fedoraproject.org writes:
On 08/11/2021 16:47, Andreas Schneider wrote:
I have electron building offline for Fedora, you can find it here: https://build.opensuse.org/package/show/network:im:signal/nodejs-electron
Electron core packaging is a quite trivial task (Arch Linux and Debian have already done this), but what about Electron applications (VS Code for example)?
They have? What's it called? Asking because I don't see it:
rharwood@eesha:~$ aptitude search electron | grep -v electronics p node-electron-to-chromium - Provides a list of electron-to-chromium version mappings rharwood@eesha:~$
Be well, --Robbie
Hi Robbie,
It looks like you're right. According to pkgs.org[1], Electron is only packaged in Archlinux, Tumbleweed, and a couple more obscure distros (or at least obscure to me 😀).
Thanks, Maxwell
[1]: https://pkgs.org/search/?q=electron -- Maxwell G (@gotmax23) Pronouns: He/Him/His PGP Key Fingerprint: f57c76e5a238fe0a628e2ecef79e4e25e8c661f8 gotmax@e.email
On 09/11/2021 16:06, Robbie Harwood wrote:
They have? What's it called? Asking because I don't see it:
Sorry, my mistake. Only Arch Linux[1] and openSUSE[2].
[1]: https://archlinux.org/packages/community/x86_64/electron/ [2]: https://software.opensuse.org/package/nodejs-electron
On Tuesday, November 9, 2021 10:28:12 AM CET Vitaly Zaitsev via devel wrote:
On 08/11/2021 16:47, Andreas Schneider wrote:
I have electron building offline for Fedora, you can find it here: https://build.opensuse.org/package/show/network:im:signal/nodejs-electron
Electron core packaging is a quite trivial task (Arch Linux and Debian have already done this), but what about Electron applications (VS Code for example)?
As I've done the packaging, I strongly disagree!
Most of them download tons of bundled JS blobs from npm during the build. I don't think it will be easy (or even possible) to build everything from sources.
Can you point me to those tons of bundled JS blobs in the source tarball from the above link please? I don't see them.
Thanks for your help!
Andreas
On 10/11/2021 08:01, Andreas Schneider wrote:
Can you point me to those tons of bundled JS blobs in the source tarball from the above link please? I don't see them.
https://github.com/microsoft/vscode/blob/main/yarn.lock - 11K lines of external dependencies.
All of them must be compiled from source on Fedora's infra.
On Wednesday, November 10, 2021 8:55:53 AM CET Vitaly Zaitsev via devel wrote:
On 10/11/2021 08:01, Andreas Schneider wrote:
Can you point me to those tons of bundled JS blobs in the source tarball from
the above link please? I don't see them.
https://github.com/microsoft/vscode/blob/main/yarn.lock - 11K lines of external dependencies.
I'm sorry, but didn't we talk about electron and you're pointing to vscode?
On 10/11/2021 09:44, Andreas Schneider wrote:
I'm sorry, but didn't we talk about electron and you're pointing to vscode?
My previous message was:
Electron core packaging is a quite trivial task (Arch Linux and Debian have already done this), but what about Electron applications (VS Code for example)?
By the way, which Electron app do you want to package?
Le 10/11/2021 à 11:27, Vitaly Zaitsev via devel a écrit :
On 10/11/2021 09:44, Andreas Schneider wrote:
Electron core packaging is a quite trivial task (Arch Linux and Debian have already done this), but what about Electron applications (VS Code for example)?
By the way, which Electron app do you want to package?
Just wanted to add that if Electron is packaged for Fedora, packaging the rest of the electron apps would not necessarily happen in the official repos (due to the enormous work needed). I could very well imagine a properly maintained Electron in the repos, including the patches for Wayland & Pipewire, and then some packagers/users building everything in COPR disregarding some of the Guidelines in instances where it is too hard to apply them. I could even imagine someone creating a repo (not in COPR hopefully, due to legal issues) replacing in proprietary apps like Discord (or Slack which happens to be relevant to other discussions here) the bundled electron with Fedora's making things like Desktop sharing (not sure if it requires more changes) and Wayland working natively, packaged in a convenient RPM, a bit like what is currently available in the AUR.
Hi Lyes,
Nov 10, 2021 9:34:17 AM Lyes Saadi fedora@lyes.eu:
Le 10/11/2021 à 11:27, Vitaly Zaitsev via devel a écrit :
On 10/11/2021 09:44, Andreas Schneider wrote:
Electron core packaging is a quite trivial task (Arch Linux and Debian have already done this), but what about Electron applications (VS Code for example)?
By the way, which Electron app do you want to package?
Just wanted to add that if Electron is packaged for Fedora, packaging the rest of the electron apps would not necessarily happen in the official repos (due to the enormous work needed). I could very well imagine a properly maintained Electron in the repos, including the patches for Wayland & Pipewire, and then some packagers/users building everything in COPR disregarding some of the Guidelines in instances where it is too hard to apply them. I could even imagine someone creating a repo (not in COPR hopefully, due to legal issues) replacing in proprietary apps like Discord (or Slack which happens to be relevant to other discussions here) the bundled electron with Fedora's making things like Desktop sharing (not sure if it requires more changes) and Wayland working natively, packaged in a convenient RPM, a bit like what is currently available in the AUR.
That sounds like an intriguing proposal. Perhaps this would be appropriate for RPM Fusion?
Thanks, Maxwell -- Maxwell G (@gotmax23) Pronouns: He/Him/His PGP Key Fingerprint: f57c76e5a238fe0a628e2ecef79e4e25e8c661f8 gotmax@e.email
On 10/11/2021 17:34, Maxwell G (@gotmax23) via devel wrote:
Perhaps this would be appropriate for RPM Fusion?
RPM Fusion doesn't allow network access during the build either.
On 10/11/2021 16:33, Lyes Saadi wrote:
I could even imagine someone creating a repo (not in COPR hopefully, due to legal issues) replacing in proprietary apps like Discord (or Slack which happens to be relevant to other discussions here) the bundled electron with Fedora's making things like Desktop sharing (not sure if it requires more changes) and Wayland working natively, packaged in a convenient RPM, a bit like what is currently available in the AUR.
Proprietary apps don't allow patching of their code. Recently discussed in #flatpak:matrix.org.
I could very well imagine a properly maintained Electron in the repos, including the patches for Wayland & Pipewire, and then some packagers/users building everything in COPR disregarding some of the Guidelines in instances where it is too hard to apply them.
Yes, COPR packages can use npm/etc. to download all the required dependencies.
Just wanted to add that if Electron is packaged for Fedora, packaging the rest of the electron apps would not necessarily happen in the official repos (due to the enormous work needed).
We will have another problem - different Electron apps require different major versions of Electron engine.
Nov 10, 2021 10:47:59 AM Vitaly Zaitsev via devel devel@lists.fedoraproject.org:
On 10/11/2021 16:33, Lyes Saadi wrote:
[snip]
Just wanted to add that if Electron is packaged for Fedora, packaging the rest of the electron apps would not necessarily happen in the official repos (due to the enormous work needed).
We will have another problem - different Electron apps require different major versions of Electron engine.
This would obviously be more effort, but Arch resolves this issue by packaging multiple versions of Electron [1].
Thanks, Maxwell
[1]: https://archlinux.org/packages/?q=electron -- Maxwell G (@gotmax23) Pronouns: He/Him/His PGP Key Fingerprint: f57c76e5a238fe0a628e2ecef79e4e25e8c661f8 gotmax@e.email
Le 10/11/2021 à 17:47, Vitaly Zaitsev via devel a écrit :
On 10/11/2021 16:33, Lyes Saadi wrote:
I could even imagine someone creating a repo (not in COPR hopefully, due to legal issues) replacing in proprietary apps like Discord (or Slack which happens to be relevant to other discussions here) the bundled electron with Fedora's making things like Desktop sharing (not sure if it requires more changes) and Wayland working natively, packaged in a convenient RPM, a bit like what is currently available in the AUR.
Proprietary apps don't allow patching of their code. Recently discussed in #flatpak:matrix.org.
That's why I said « not in COPR hopefully » ^_^. Client modification is prohibited by Discord, but it is not really acting on that unless it harms them (the AUR repo is an example of that). I wonder what is Slack's TOS? Maybe with their approval, a COPR could be maintained without any issue?
(Also, I just want to insist I am not pushing nor advising anyone to do something breaking Discord's TOS without their approval, I'm just thinking of examples of external demand for a Discord package in Fedora.)
Just wanted to add that if Electron is packaged for Fedora, packaging the rest of the electron apps would not necessarily happen in the official repos (due to the enormous work needed).
We will have another problem - different Electron apps require different major versions of Electron engine.
That is true. Though, compat-packages could be an option for the main repository anyway.
Hi
On Wed, Nov 10, 2021 at 12:05 PM Lyes Saadi wrote:
(Also, I just want to insist I am not pushing nor advising anyone to do something breaking Discord's TOS without their approval, I'm just thinking of examples of external demand for a Discord package in Fedora.)
https://fedoraproject.org/wiki/Changes/Filtered_Flathub_Applications is intended to address that
Rahul
On 10/11/2021 18:04, Lyes Saadi wrote:
I wonder what is Slack's TOS? Maybe with their approval, a COPR could be maintained without any issue?
COPR can't be used for building non-free software: https://docs.pagure.org/copr.copr/user_documentation.html#what-i-can-build-i...
I wonder what is Slack's TOS? Maybe with their approval, a COPR could be maintained without any issue?
COPR can't be used for building non-free software: https://docs.pagure.org/copr.copr/user_documentation.html#what-i-can-build-i...
Indeed, forgot about that when writing my e-mail ^^'!
I guess someone volunteering to properly package it in RPM Fusion could do it (if they got Slack's approval), since Slack seems to be no longer willing to ship it themselves.
Vitaly Zaitsev via devel wrote:
On 10/11/2021 16:33, Lyes Saadi wrote:
I could even imagine someone creating a repo (not in COPR hopefully, due to legal issues) replacing in proprietary apps like Discord (or Slack which happens to be relevant to other discussions here) the bundled electron with Fedora's making things like Desktop sharing (not sure if it requires more changes) and Wayland working natively, packaged in a convenient RPM, a bit like what is currently available in the AUR.
Proprietary apps don't allow patching of their code. Recently discussed in #flatpak:matrix.org.
You would not actually be patching the proprietary code, but the bundled Electron. Considering that essential parts of libchromiumcontent (the Blink code derived from WebKit, itself derived from KHTML) are under the LGPL, the proprietary applications are actually *required* to allow you to replace the LGPL library with a modified and/or updated version. If they attempt to sue you for it, *they* are violating the LGPL license of WebKit. (You will probably also be able to find some KDE developers whose LGPLed KHTML code ended up in Blink and who may be more willing to cooperate with you in the case of a lawsuit than Google or Apple.)
Kevin Kofler
On Wednesday, November 10, 2021 11:27:32 AM CET Vitaly Zaitsev via devel wrote:
On 10/11/2021 09:44, Andreas Schneider wrote:
I'm sorry, but didn't we talk about electron and you're pointing to vscode?
My previous message was:
Electron core packaging is a quite trivial task (Arch Linux and Debian have already done this), but what about Electron applications (VS Code for example)?
By the way, which Electron app do you want to package?
I'm packaging Signal-Desktop completely built from source.
On 11/11/2021 11:08, Andreas Schneider wrote:
I'm packaging Signal-Desktop completely built from source.
https://build.opensuse.org/package/view_file/network:im:signal/signal-deskto...
Does this script simply download assets from npm using the "yarn install" command?
On Thursday, November 11, 2021 11:28:42 AM CET Vitaly Zaitsev via devel wrote:
On 11/11/2021 11:08, Andreas Schneider wrote:
I'm packaging Signal-Desktop completely built from source.
https://build.opensuse.org/package/view_file/network:im:signal/signal-deskto p/prepare_vendor.sh?expand=1
Does this script simply download assets from npm using the "yarn install" command?
Does it look like it only calls 'yarn install' and does nothing else?
Maybe look through the "echo" commands to see what it does. Are you looking for the `echo ">>>>>> Cleanup object files"` section?
On Thu, 2021-11-11 at 11:08 +0100, Andreas Schneider wrote:
On Wednesday, November 10, 2021 11:27:32 AM CET Vitaly Zaitsev via devel wrote:
On 10/11/2021 09:44, Andreas Schneider wrote:
I'm sorry, but didn't we talk about electron and you're pointing to vscode?
My previous message was:
Electron core packaging is a quite trivial task (Arch Linux and Debian have already done this), but what about Electron applications (VS Code for example)?
By the way, which Electron app do you want to package?
I'm packaging Signal-Desktop completely built from source.
https://build.opensuse.org/project/show/network:im:signal
https://build.opensuse.org/package/view_file/network:im:signal/signal-deskto...
All of them must be compiled from source on Fedora's infra.
No, they don't. https://fedoraproject.org/wiki/Changes/NodejsLibrariesBundleByDefault#Detail...
Have you tested the build without network access? Because even Flatpaks download everything from npm.
"Flatpaks" using flatpak-node-generator for downloading modules but doesn't requires network access during build. Builds also reproducible.
On 10/11/2021 10:07, Artem Tim wrote:
No, they don't.https://fedoraproject.org/wiki/Changes/NodejsLibrariesBundleByDefault#Detail...
Yes, bundling is allowed only for sources. You can package all dependencies in source form into a single vendored tarball.
"Flatpaks" using flatpak-node-generator for downloading modules but doesn't requires network access during build.
Flathub != Fedora. All Fedora packages must be built from sources (except firmware).
Yes, bundling is allowed only for sources. You can package all dependencies in source form into a single vendored tarball.
OP never talked about bundling blobs, only you. Also OP never talked about vscode.
Flathub != Fedora. All Fedora packages must be built from sources (except firmware).
Indeed, and they are built from sources on Flathub and that exactly the point. We can do the same for Fedora.
Keep mislead people and twisting things if this helps you with packaging electron apps on Fedora.
On 10/11/2021 11:54, Artem Tim wrote:
Indeed, and they are built from sources on Flathub and that exactly the point. We can do the same for Fedora.
As far as I know, they just parsing yarn.lock file and downloading assets. This is not suitable for Fedora.
Keep mislead people and twisting things if this helps you with packaging electron apps on Fedora.
I think it will be very difficult or even impossible to build Electron apps completely from sources without using pre-built assets from npm (or parsing and downloading content from yarn.lock).
On Wednesday, November 10, 2021 3:39:42 PM CET Vitaly Zaitsev via devel wrote:
Keep mislead people and twisting things if this helps you with packaging electron apps on Fedora.
I think it will be very difficult or even impossible to build Electron apps completely from sources without using pre-built assets from npm (or parsing and downloading content from yarn.lock).
It is a pain, but doable. I have it working for Signal-Desktop.
Neal Gompa wrote:
On Mon, Nov 8, 2021 at 9:16 AM Vitaly Zaitsev via devel devel@lists.fedoraproject.org wrote:
On 08/11/2021 10:12, Andreas Schneider wrote:
I'm interested in this, as I try to package electron for Fedora.
Electron can't be build completely from sources without downloading pre-built binaries/blobs from npm.
This is not true anymore.
As I understand it, it was never true, in the sense that it was always *possible* to build Electron completely from sources. The issue was that the upstream build system worked against you there and that you had to jump through a lot of hoops to use components built from source instead of blobs downloaded from somewhere. Each of the Electron stages was just downloading the next lower layer as a blob, which in turn included the next lower layer as a blob. In particular, each Electron app bundled the Electron blob which was just downloaded from Electron at build time, and each Electron build bundled the Chromium fork blob which was also downloaded as a blob during the build. (I think there were even one or two additional blob layers that I have forgotten. The minified JavaScript blobs you mention were probably also already part of it.) I do not know to what extent, if at all, this has been improved since last I checked.
Kevin Kofler
On Mon, Nov 8, 2021 at 11:50 AM Kevin Kofler via devel devel@lists.fedoraproject.org wrote:
Neal Gompa wrote:
On Mon, Nov 8, 2021 at 9:16 AM Vitaly Zaitsev via devel devel@lists.fedoraproject.org wrote:
On 08/11/2021 10:12, Andreas Schneider wrote:
I'm interested in this, as I try to package electron for Fedora.
Electron can't be build completely from sources without downloading pre-built binaries/blobs from npm.
This is not true anymore.
As I understand it, it was never true, in the sense that it was always *possible* to build Electron completely from sources. The issue was that the upstream build system worked against you there and that you had to jump through a lot of hoops to use components built from source instead of blobs downloaded from somewhere. Each of the Electron stages was just downloading the next lower layer as a blob, which in turn included the next lower layer as a blob. In particular, each Electron app bundled the Electron blob which was just downloaded from Electron at build time, and each Electron build bundled the Chromium fork blob which was also downloaded as a blob during the build. (I think there were even one or two additional blob layers that I have forgotten. The minified JavaScript blobs you mention were probably also already part of it.) I do not know to what extent, if at all, this has been improved since last I checked.
Electron can use vanilla Chromium source trees to build now rather than a prebuilt libchromiumcontent library.
Andreas Schneider wrote:
there are several packages in the distribution which require FFMPEG (libavformat, libavcodec, etc.), one of them being chromium. The package could be created in a way that you can easily replace it with a version from rpmfusion to get to the full encoder/decoder set including H264 etc.
And does Chromium fully work with HTML5 video if you do that? In particular, does it correctly report the list of supported codecs to the website? Last I checked, Chromium hardcoded the list of supported codecs at compile time (and there were actually only 2 hardcoded lists in the source code, one of which was selected at compile time depending on whether the "proprietary_codecs" flag was set at compile time or not; no attempt whatsoever was made to query ffmpeg for what codecs it actually supports, neither at compile time nor at runtime), so the only way to replace the list was to replace the entire Chromium (which is what qt5-qtwebengine-freeworld does for qt5-qtwebengine: it replaces the entire QtWebEngine shared libraries including the entire bundled Chromium).
Kevin Kofler
Kevin Kofler via devel wrote:
And does Chromium fully work with HTML5 video if you do that? In particular, does it correctly report the list of supported codecs to the website? Last I checked, Chromium hardcoded the list of supported codecs at compile time (and there were actually only 2 hardcoded lists in the source code, one of which was selected at compile time depending on whether the "proprietary_codecs" flag was set at compile time or not; no attempt whatsoever was made to query ffmpeg for what codecs it actually supports, neither at compile time nor at runtime), so the only way to replace the list was to replace the entire Chromium (which is what qt5-qtwebengine-freeworld does for qt5-qtwebengine: it replaces the entire QtWebEngine shared libraries including the entire bundled Chromium).
PS: And, also last I checked, even MP3 (whose patents expired a few years ago) was still considered a "proprietary codec" by Chromium. (The Fedora Chromium package, but not the qt5-qtwebengine one, has a patch to enable MP3 support, but I think it does not actually touch the supported codec list, it only enables the codec in the bundled ffmpeg. And to do so, it also requires several files related, according to their names, to other patent-encumbered codecs such as AAC, files that I was not comfortable with shipping in qt5- qtwebengine when I last looked into the issue, which was before I handed over qt5-qtwebengine maintenance to Rex Dieter.)
Kevin Kofler
On Mon, 2021-11-08 at 10:12 +0100, Andreas Schneider wrote:
Hi,
there are several packages in the distribution which require FFMPEG (libavformat, libavcodec, etc.), one of them being chromium. The package could be created in a way that you can easily replace it with a version from rpmfusion to get to the full encoder/decoder set including H264 etc.
This is working fine with openSUSE and packages from Packman.
https://build.opensuse.org/package/show/multimedia:libs/ffmpeg-4 https://pmbs.links2linux.org/package/show/Essentials/A_tw-ffmpeg
Also Debian have ffmpeg package
you may try : dget https://deb.debian.org/debian/pool/main/f/ffmpeg/ffmpeg_4.4.1-1.dsc
cd ffmpeg-4.4.1/debian vi README.Debian etc
The Packman version always has a higher release version than the one in the distribution.
I'm interested in this, as I try to package electron for Fedora. The big problem is the included ffmpeg. With openSUSE I can just use the system ffmpeg, with Fedora I have to do some source code voodoo which I really would like to avoid.
Thanks for considering!
Best regards
Andreas
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Sérgio Basto wrote:
Also Debian have ffmpeg package
you may try : dget https://deb.debian.org/debian/pool/main/f/ffmpeg/ffmpeg_4.4.1-1.dsc
cd ffmpeg-4.4.1/debian vi README.Debian etc
Debian has much less strict rules for multimedia patents than Fedora. E.g., Debian has always held the viewpoint that codec patents are only enforcible against encoders, not decoders, and was happily shipping MP3 decoders back when the MP3 patent(s) had not yet expired.
Kevin Kofler