It had confusing semantics, being somewhere between a boolean option and
a FontPath specification. Introduce fontPath to replace it and mark the
old option as removed.
As of version 1.18.0 Appindicator support is available in the official
network-manager-applet package. To use nm-applet in an Appindicator
environment the applet should be started with the following command:
$ nm-applet --indicator
Without this option it does appear in the Enlightenment panel systray,
for instance.
Regression introduced by 053b05d14d.
The commit in question essentially removed the "with pkgs;" from the
scope around the various packages added to environment.systemPackages.
Since services.colord.enable and services.xserver.wacom.enable are false
by default, the change above didn't directly result in an evaluation
error.
Tested evaluation before and after this change via:
for cfg in hardware.bluetooth.enable \
networking.networkmanager.enable \
hardware.pulseaudio.enable \
powerManagement.enable \
services.colord.enable \
services.samba.enable \
services.xserver.wacom.enable; do
nix-instantiate --eval nixos --arg configuration '{
services.xserver.desktopManager.plasma5.enable = true;
'"$cfg"' = true;
}' -A config.environment.systemPackages > /dev/null
done
Signed-off-by: aszlig <aszlig@nix.build>
Cc: @ttuegel
In version 2.0.15 `gotify` switched to `packr` at 2.x which is why the
UI can't be served properly via HTTP and causes an empty 500 response and
the following errors in `journald`:
```
2020/09/12 19:18:33 [Recovery] 2020/09/12 - 19:18:33 panic recovered:
GET / HTTP/1.1
Host: localhost:8080
Accept: */*
User-Agent: curl/7.72.0
stat /home/ma27/Projects/ui/build/index.html: no such file or directory
```
This wasn't caught by the VM-test as it only tested the REST and push
APIs. Using their internal `packr.go` script in our build as it's the
case in the upstream build-system[1] fixes the issue.
[1] https://github.com/gotify/server/pull/277/files#diff-b67911656ef5d18c4ae36cb6741b7965R48
ecb73fd555 introduced a new keepVmState
CLI flag for test-driver.py. This CLI flags gets forwarded to the
Machine class through create_machine.
It created a regression for the boot tests where __main__ end up not
being evaluated. See
https://github.com/NixOS/nixpkgs/pull/97346#issuecomment-690951837 for
bug report.
Defaulting keepVmState to false when __main__ ends up not being
evaluated.
This reverts commit 42eebd7ade, reversing
changes made to b169bfc9e2.
This breaks nfs3.simple test and even current PR #97656 wouldn't fix it.
Therefore let's revert for now to unblock the channels.
This is a temporary fix for #97433. A more proper fix has been
implemented upstream in systemd/systemd#17001, however until it gets
backported, we are stuck with ignoring the error.
After the backport lands, this commit should be reverted.
`rngd` seems to be the root cause for slow boot issues, and its functionality is
redundant since kernel v3.17 (2014), which introduced a `krngd` task (in kernel
space) that takes care of pulling in data from hardware RNGs:
> commit be4000bc4644d027c519b6361f5ae3bbfc52c347
> Author: Torsten Duwe <duwe@lst.de>
> Date: Sat Jun 14 23:46:03 2014 -0400
>
> hwrng: create filler thread
>
> This can be viewed as the in-kernel equivalent of hwrngd;
> like FUSE it is a good thing to have a mechanism in user land,
> but for some reasons (simplicity, secrecy, integrity, speed)
> it may be better to have it in kernel space.
>
> This patch creates a thread once a hwrng registers, and uses
> the previously established add_hwgenerator_randomness() to feed
> its data to the input pool as long as needed. A derating factor
> is used to bias the entropy estimation and to disable this
> mechanism entirely when set to zero.
Closes: #96067
This commit fixes the ejabberd tests for hydra:
mod_http_upload and mod_disco need to be explicitly enabled, and a
handler needs to be setup to make it work. Also, the client needs to be
able to contact the server.
The commit also fixes the situation where http upload failed: in that
case the client would wait forever because nothing catched the error.
Finally, there remains a non-reproducible error where ejabberd server
fails to start with an error like:
format: "Failed to create cookie file '/var/lib/ejabberd/.erlang.cookie': eacces"
(happens ~15%) I tried to check existence of /var/lib/ejabberd/ in
pre-start script and saw nothing that would explain this error, so I
gave up about this error in particular.