The rsync binary was previously built without iconv support which is needed
for utf-8 conversions on darwin. Fixes#26864.
Additionally rsync used to be built with bundled versions of zlib and popt
that were outdated. This decreases the size of the rsync binary by ~82KB.
The following errors occur when you start Chromium prior to this commit:
[2534:2534:0625/202928.673160:ERROR:gl_implementation.cc(246)] Failed to
load .../libexec/chromium/swiftshader/libGLESv2.so:
../libexec/chromium/swiftshader/libGLESv2.so: cannot open shared object
file: No such file or directory
[2534:2534:0625/202928.674434:ERROR:gpu_child_thread.cc(174)] Exiting
GPU process due to errors during initialization
While in theory we do not strictly need libGLESv2.so, in practice this
means that the GPU process isn't starting up at all which in turn leads
to crawling rendering performance on some sites.
So let's install all shared libraries in swiftshader.
I've tested this with the chromium.stable NixOS VM test and also locally
on my machine and the errors as well as the performance issues are gone.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
First of all, we need a newer version of Vc, because at least version
1.1.0 is required for Krita 3.1.3.
Also, qtmultimedia and qtx11extras were missing.
Built and tested successfully on my machine.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Cc: @abbradar
The merge of the version bump in
6fb9f89238 didn't take care of our patch
for the hardening mode and thus enabling VirtualBox without also
force-disabling hardening mode will result in a build error.
While the patch is largely identical with the old version, I've removed
one particular change around the following code:
if (pFsObjState->Stat.st_mode & S_IWOTH)
return supR3HardenedSetError3(VERR_SUPLIB_WORLD_WRITABLE, pErrInfo,
"World writable: '", pszPath, "'");
In the old version of the patch we have checked whether the path is
within the Nix store and suppressed the error return if that's the case.
The reason why I did that in the first place was because we had a bunch
of symlinks which were writable.
In VirtualBox 5.1.22 the code specifically checks whether the file is a
symlink, so we can safely drop our change.
Tested via all of the "virtualbox" NixOS VM subtests and they now all
succeed.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
