Fixes issue #33231 and makes it possible to enable Plasma and KDE at the same time.
Previously, this worked like this:
- The gdk-pixbuf package comes with a cache file covering the modules bundled
with gdk-pixbuf.
- The librsvg package comes with a cache covering modules from gdk-pixbuf as
well as librsvg.
- plasma5 and xfce modules set the environment variable GDK_PIXBUF_MODULE_FILE
to the one from librsvg, so that SVG was supported in addition to the
formats supported by gdk-pixbuf. However if both were enabled a configuration
conflict would result (despite setting to the same value).
While this sort of worked (ignoring the conflict which perhaps could be hacked
around), it is unscalable and a hack, as there would be a real problem when one
wanted to add a third package that supports additional image formats.
A new NixOS module (gdk-pixbuf) is added with a configuration option
(modulePackages) that other modules use to request specific packages to be
included in the loaders cache. When any package is present in the list, the
module generates a system-wide loaders cache which includes the requested
packages (and always gdk-pixbuf itself), and sets the environment variable
GDK_PIXBUF_MODULE_FILE to point to the generated cache file.
The plasma5 and xfce modules are updated to add librsvg to modulePackages
instead of setting GDK_PIXBUF_MODULE_FILE.
Note that many packages create wrappers that set GDK_PIXBUF_MODULE_FILE,
some directly to the one from librsvg. Therefore this change does not
change the existing hack in the librsvg package which ensures that
file is generated. This change aims only to solve the conflict in the
global environent variable configuration.
Bazel is a build tool, much like Make and many others. Like Make, it
should be agnostic to the compiler toolchains the user brings into
scope. Bazel has special rules that encode domain specific knowledge
for how to compile a C++ program, or indeed a Java program and a few
others. But that's not to say that at runtime Bazel should assume
a specific C++ compiler or Java compiler anymore than Make does.
The main impact of this change is that packages that build with Bazel
will have to list the compilers they want in their `buildInputs` or
similar, rather than relying on the `bazel` package pulling them in
transitively.
* rpcs3: 0.0.4-8032 -> 0.0.5-6884
* rpcs3: update hash
* rpcs3: 0.0.5-6884 -> 0.0.5-6925
* rpcs3: 0.0.5-6925 -> 0.0.5-6938
* rpcs3: 0.0.5-6938 -> 0.0.5-6980
Manually write version header instead of generating it with git, which required leaveDotGit to be enabled.
This caused some hash mismatches (see #8567) has thus been disabled.
gopass tries to write a version number to it's configuaration, even when
just generating the shell completion scripts. This fails, as
/homeless-shelter is read-only inside the sandbox.
As error messages are printed to stdout instead of stderr
(see https://github.com/gopasspw/gopass/issues/877), the error message
lands inside the completion script, thus breaking it.
Workaround that by setting GOPASS_CONFIG to `/dev/null`
