- Enable the shared library build on darwin by default to match other
platforms.
- Fix the dylib file's name in the store
- Symlink a versioned name as some tooling expects this.
Before commit 54fa0cfe4e, the `redshift`
service was run with the environment variable `DISPLAY` set to `:0`.
Commit 54fa0cfe4e changed this to
instead use the value of the `services.xserver.display` configuration
option in the value of the `DISPLAY` variable. In so doing, no default
value was provided for the case where `services.xserver.display` is
`null`.
While the default value of `services.xserver.display` is `0`, use of
which by the `redshift` module would result in `DISPLAY` again being
set to `:0`, `services.xserver.display` may also be `null`, to which
value it is set by, e.g., the `lightdm` module.
In the case that `services.xserver.display` is `null`, with the change
made in commit 54fa0cfe4e, the `DISPLAY`
variable in the environment of the `redshift` service would be set to
`:` (a single colon), which, according to my personal experience,
would result in —
- the `redshift` service failing to start; and
- systemd repeatedly attempting to restart the `redshift` service,
looping indefinitely, while the hapless `redshift` spews error
messages into the journal.
It can be observed that the malformed value of `DISPLAY` is likely at
fault for this issue by executing the following commands in an
ordinary shell, with a suitable `redshift` executable, and the X11
display not already tinted:
- `redshift -O 2500` — This command should reduce the color
temperature of the display (making it more reddish).
- `DISPLAY=':' redshift -O 6500` — This command should raise the
color temperature back up, were it not for the `DISPLAY`
environment variable being set to `:` for it, which should cause
it to, instead, fail with several error messages.
This commit attempts to fix this issue by having the `DISPLAY`
environment variable for the `redshift` service default to its old
value of `:0` in the case that `services.xserver.display` is `null`.
I have tested this solution on NixOS, albeit without the benefit of a
system with multiple displays.
This reverts commit 86caec1be1.
In this commit tests were re-enabled, but without correctly testing whether it could.
When a package builds it doesn't mean the tests are actually run. This is often seen when it says that 0 tests were run.
Typically this is because the test runner was invoked incorrectly.
By re-enabling the tests, a false impression is generated that the package is tested while in fact it isn't. Furthermore, the Python 3.5
package broke because the tests are invoked incorrectly.
cc @abbradar
(cherry picked from commit 93d8ab8007102e0e4d7f23cf25bb353d1cc5bced)
I checked with kdenlive people, and they say that we should always use the
latest mlt possible; that it should not be any problem, and provide only
improvements.
gdnc is a user process and can't be made into a NixOS module very
easily. It can still be put in the user's login script. According to the
GNUstep documentation it will be started as soon as it is needed.
Meta data like maintainers, license, and homepage is shared throughout the
"gnustep" project. Everything going through "gsmakeDerivation" now
shares overridable metadata.
This should make merge conflicts easier to
handle. "gnustep" prefix has been removed to
make thing simpler. So "gnustep_make" is now
"make" within the gnustep scope.
Packaging some basic GNUstep apps: GWorkspace and SystemPreferences.
Unfortunately, GWorkspace doesn't work well, because gdomap, gdnc, gpbs
are not started. Also, there is some issue with fonts not being found.
Cleaning up. Adding GNUstep package builder for abstracting out GNUstep
compilation specifics (with thanks to GitHub user lethalman).
The rules for using build_gnustep_package are as simple: any
GNUstep-based package that the package being compiled depends upon are
to be put in [deps] (this is used for setting up a buildEnv), while
other dependencies are put into [buildInputs] as usual.
