Nonfree files and pre-built Windows binaries in source package qt5webengine-opensource-src

Thank you for the report! However, I have one question.

Are any of those files (or references to them) installed in Trisquel when installing the corresponding package? If they are installed or referenced, then it is important that we clean that up. But otherwise, I believe the policy is to only clean visible things that any user might interact with. Cleaning up source code is an unnecessary burden when developer resources are already sparse.

No, they are not. Most of it is only relevant to Windows, macOS, Android, or iOS, or executables used as test data. unrar is used in Chromium for Google Safe Browsing, but this is not built in qtwebengine. However, I thought the policy was that there should be no proprietary software anywhere in the repository, including source packages.

I brought this to the dev meeting and you are totally right, any non-free binary should not be present in the repo, regardless of whether it is user visible or not. However, prebuilt binaries from free sources are not a problem as long as they are not installed. Cleaning those binaries does not provide any freedom improvements while adding maintenance burden.

So based on your research, can you provide a list of non-free binaries included? Or are all the binaries in the list possibly built from non-free sources?

Everything that I listed is either nonfree (no source code, or source code under a proprietary license) or a binary for Windows/macOS likely built using a nonfree compiler such as MSVC.

Work in progress: https://gitlab.trisquel.org/trisquel/package-helpers/-/merge_requests/576

Why was the nonfree unrar source not pruned? Removing it should not cause any problems.

Also, the same should be done for etiona, though the list of binaries may be different.

Edit: And some more files that I forgot:

src/3rdparty/chromium/third_party/win_build_output
src/3rdparty/chromium/build/android/CheckInstallApk-debug.apk
src/3rdparty/chromium/third_party/blink/manual_tests/accessibility/resources/AppletTest.class
src/3rdparty/chromium/third_party/blink/manual_tests/resources/ArrayParameterTestApplet.class
src/3rdparty/chromium/third_party/blink/manual_tests/resources/CheckerApplet.class
src/3rdparty/chromium/third_party/blink/manual_tests/resources/DrawMessage.class
src/3rdparty/chromium/third_party/blink/manual_tests/resources/StringTypeTest.class
src/3rdparty/chromium/third_party/blink/manual_tests/resources/TestApplet.class

I will run ungoogled-chromium's binary pruning script and see if there's anything else that I missed.

OK, so the only remaining ones I could find after running the pruning script were these:

third_party/blink/renderer/devtools/scripts/closure/closure_runner/closure_runner.jar
third_party/blink/renderer/devtools/scripts/closure/compiler.jar
third_party/blink/renderer/devtools/scripts/jsdoc_validator/jsdoc_validator.jar

The closure compiler is free software, but does not come with source code here, and it is unclear what source code corresponds to the binary. jsdoc_validator.jar also does not come with source code (though newer versions of qtwebengine seem to have it). There are other JAR files in the source tree that come without source code, but each of them comes with a URL for the source code along with the version, so I assume they are OK for now.

Meanwhile, I have also filed a bug with Debian to remove all pre-built binaries from this package: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1000620

Thanks for the input, well take a look soon.
Cheers!

This will be fixed as soon as the version,
qtwebengine-opensource-src | 5.12.8+dfsg-0ubuntu1.1+10.0trisquel2

hits the repository, there are several packages queued so it will take a bit longer.

Cheers!

But unrar still hasn't been removed.

Please specify the path.

Update: Oh!, I see now. that's an issue as it uses it to build, IIRC its signed so the file cannot be replaced.
I'll do some research.

I do not think unrar is used to build it. Also, unrar is nonfree so including it is a critical bug.

Indeed.
So far it cant' be build without it, which is a bad sign.

Do you know of a chromium build without using unrar as a third-party building block?
If you do, we might be able to replicate 'that' technique to remove it, if there is none, well the complete package falls on itself, right?

I'll keep digging, regards.

Yes, the Debian package upstream has it removed. In qtwebengine they just remove it, without applying any patch, so I assumed it was not required for the build. Meanwhile, Debian's chromium package uses this patch to disable it: https://salsa.debian.org/chromium-team/chromium/-/blob/master/debian/patches/disable/unrar.patch. Similar patches are used by Fedora and ungoogled-chromium. None of these use unrar.

Thanks, current status was half way there.
https://salsa.debian.org/chromium-team/chromium/-/blob/master/debian/patches/disable/unrar.patch

I checked the build log: https://jenkins.trisquel.org/job/binary/2989/label=amd64/artifact/qtwebengine-opensource-src_5.12.8+dfsg-0ubuntu1.1+10.0trisquel3_amd64-2021-12-01T05%3A58%3A30Z.build

And it turns out that it compiles just fine, the problem is that the list of exported symbols has changed so it fails after building the whole thing. I suspect that this may have to do with the disabling of the "proprietary-codecs" option. Actually, there is no reason to disable this because it is actually a misnomer. See Guix bugs 34605 and 46337. This actually just allows Chromium/qtwebegine to use whatever codecs are provided by FFmpeg to support patent-encumbered formats.

Also, the patch to disable unrar/safe browsing is not needed, since these components are not compiled in qtwebengine anyway.

Actually I was wrong about what I said, this older version of qtwebengine does have safe browsing and unrar enabled, while newer versions do not.

This seems to work: https://gitlab.trisquel.org/trisquel/package-helpers/-/merge_requests/594

Backported to etiona

For etiona, there are some more files that need to be removed:
src/3rdparty/chromium/third_party/webpagereplay/third_party/ipfw_win32/ipfw.exe
src/3rdparty/chromium/third_party/webpagereplay/third_party/ipfw_win32/ipfw.sys
src/3rdparty/chromium/third_party/yasm/binaries/win/yasm.exe

Also, the JAR files are in a different directory:
src/3rdparty/chromium/third_party/WebKit/Source/devtools/scripts/closure/closure_runner/closure_runner.jar
src/3rdparty/chromium/third_party/WebKit/Source/devtools/scripts/closure/compiler.jar
src/3rdparty/chromium/third_party/WebKit/Source/devtools/scripts/jsdoc_validator/jsdoc_validator.jar

If it's ok with you, if you keep them coming I'll keep testing and updating.

Yeah, fine with me. I looked through the list generated by the ungoogled-chromium scripts and I did not notice anything else that should be removed. If you want you can take a look for yourself. The update_lists.py script in the ungoogled-chromium repository generates a list of binary files. Most of these binaries seem fine (e.g. certificates or other data) but the list is not too long so it is relatively easy to find the problematic files.

Hopefully in the future Debian will be more thorough with their binary pruning so that Trisquel doesn't have to continue doing this. (The version in Debian sid removes unrar and a lot of the nonfree binaries, but not all).

By the way, I think the Triskel iso contains qtwebengine, which means that a new iso should be released.

Let's continue that on:
https://trisquel.info/es/issues/28504

As this is removed from the repositories.

Automatically closed -- issue fixed for 2 weeks with no activity.