During the refactor of the networkd stuff in f8dbe5f, a lot of the
options are now needed by systemd.nix as well as networkd.nix but
weren't moved by that commit as well.
For now, this fixes all networkd VM tests except for the macvlan one and
thus it should fix#7505 for at least DHCP-based configuration.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
In f8dbe5f, the default value for networking unit "enabled" option
suddenly flipped to false. I have no idea of whether this happened by
accident, but I'm setting it to true again, because it essentially
breaks systemd networking support and we have systemd.network.enable to
have a "turn the world off" switch.
And of course, because the mentioned commit obviously wasn't done with
even a run of the simplest run of one of the network VM tests, we now
get an evaluation error if we switch useNetworkd to true.
Fixes the core issue of #7505.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
- Pass the gstreamer plugins as a list attribute instead of
individual attributes.
+ This should allow for greater customization (e.g.: a
user can add / remove plugins by overriding
the plugin list attribute).
This is the same technique as used for wrapping chrome
with gstreamer plugins.
- Moved integration of gstreamer plugins, spotify
library and clementine into a wrapper derivation.
+ This should allow a user to change the gstreamer
plugin set and activate / deactivate the spotify
plugin without triggering a whole rebuild of the
clementine sources (which is pretty long).
It used to be a symlink, but now it is a link script. It's crucial to get
proper linking, specially on amrv5tel, where libgcc contains lot of code
related to the limited instruction set of the platform.
Without this fix, g++ shared lib linking was broken, because a "-lgcc" was
not propagated wherever "-lgcc_s" was required. The g++ spec only mentions
"-lgcc_s" and the "-lgcc" is introduced with the libgcc_s.so link script,
only available in the glibc path after this fix.
As a reminder, we put libgcc* in the glibc output to avoid having a
runtime dependency on the gcc path only because of the everywhere linked
libgcc. This problem was specially visible in platforms like armv5tel,
where most programs end up linked to libgcc. Platforms with a more rich
instruction set may rarely end up requiring a link to libgcc.
Jascha Geerds