NixOS should be able to support the Nintendo Switch Pro controller for
steam and non-steam at the same time. Currently there are two mutually
exclusive ways to support the Pro Controller: Steam and `hid-nintendo`.
Unfortunately these don't work together, but there's a workaround in
newer versions of `joycond` (described [here](https://wiki.archlinux.org/title/Gamepad#Using_hid-nintendo_pro_controller_with_Steam_Games_(with_joycond))). To use this
workaround `hid-nintendo` and `joycond` need to be updated, and the
systemd and udev configuration needs to be made available in NixOS.
We have no usecase for manually/selectively starting or stopping VLANs
in integration tests.
By starting and stopping the VLANs with the constructor and destructor
of VLAN objects, we remove the obligation and complexity to maintain
network lifetime separately.
This commit encapsulates the involved domain into classes and
defines explicit and typed arguments where untyped dicts where used.
It preserves backwards compatibility through legacy wrappers.
* less: enable by default and set LESS=-R via lesskey
* since we set PAGER=less, programs.less.enable should default to
true.
* some programs, notably git, set a custom LESS environment if none is
present. using the lesskey mechanism to set LESS=-R lets such
programs continue to run less as they see fit.
This reverts commit 0e7b4e60a8.
* less: remove use of deprecated lesskey binary format
* less: enable in environment.nix rather than less.nix
per discussion in #139988
This module allows setting global configuration for htop in /etc/htoprc,
for example to disable showing userland threads by default
Co-authored-by: pennae <82953136+pennae@users.noreply.github.com>
Co-authored-by: Aaron Andersen <aaron@fosslib.net>
This is the first version of the mautrix-facebook module. Due to lack of secret support on NixOS as well as the requirement of a homeserver domain it requires some setup. For completeness here is my working config using NixOps secrets:
```nix
deployment.keys."mautrix-facebook-config.env" = {
text = ''
MAUTRIX_FACEBOOK_APPSERVICE_AS_TOKEN=${secrets.as_token}
MAUTRIX_FACEBOOK_APPSERVICE_HS_TOKEN=${secrets.hs_token}
'';
destDir = "/var/keys";
};
deployment.keys."mautrix-facebook-registration.yaml" = {
text = builtins.toJSON config.services.mautrix-facebook.registrationData;
destDir = "/var/keys";
user = "matrix-synapse";
};
users.users.matrix-synapse.extraGroups = ["keys"];
systemd.services.matrix-synapse.after = ["keys.service"];
systemd.services.matrix-synapse.wants = ["keys.service"];
services.mautrix-facebook = {
enable = true;
settings = {
homeserver.domain = "bots.kevincox.ca";
bridge = {
displayname_template = "{displayname}";
permissions = {
"@kevincox:matrix.org" = "admin";
};
};
};
environmentFile = "/var/keys/mautrix-facebook-config.env";
registrationData = {
as_token = secrets.as_token;
hs_token = secrets.hs_token;
};
};
systemd.services.mautrix-facebook = rec {
wants = ["keys.target"];
after = wants;
};
services.matrix-synapse.app_service_config_files = [
"/var/keys/mautrix-facebook-registration.yaml"
];
```
Previously, the `nix_read_pwd` function was only used for reading the
`dbpassFile`, however it has since been refactored to handle reading
other secret files too. This fixes the message of the exception that is
thrown in the case that the file is not present so that it no longer
refers specifically to the `dbpass` file.
Removes the submodule in favour of using an attrset.
Also:
- Makes better use of nix's laziness in config expansion.
- Makes use of `boolToString` where applicable.
We should discourage users from adding secrets in a way that allows for
them to end up in the globally readable `/nix/store`. Users should use
the `objectstore.s3.secretFile` option instead.
This allows to declaratively configure an S3 class object storage as the
primary storage for the nextcloud service. Previously, this could only
be achieved by manually editing the `config.php`.
I've started testing this today with my own digitalocean nextcloud
instance, which now points to my digitalocean S3-compatible "Space" and
all appears to be working smoothly.
My motivation for this change is my recent discovery of how much cheaper
some S3-compatible object storage options are compared to digitalocean's
"Volume" options.
Implementation follows the "Simple Storage Service" instructions here:
https://docs.nextcloud.com/server/latest/admin_manual/configuration_files/primary_storage.html
I have neglected to implement a submodule for the OpenStack Swift
object storage as I don't personally have a use case for it or a method
to test it, however the new `nextcloud.objectstore.s3` submodule should
act as a useful guide for anyone who does wish to implement it.
The MariaDB version 10.6 doesn't seem supported with current Nextcloud
versions and the test fails with the following error[1]:
nextcloud # [ 14.950034] nextcloud-setup-start[1001]: Error while trying to initialise the database: An exception occurred while executing a query: SQLSTATE[HY000]: General error: 4047 InnoDB refuses to write tables with ROW_FORMAT=COMPRESSED or KEY_BLOCK_SIZE.
According to a support-thread in upstream's Discourse[2] this is because
of a missing support so far.
Considering that we haven't received any bugreports so far - even though
the issue already exists on master - and the workaround[3] appears to
work fine, an evaluation warning for administrators should be
sufficient.
[1] https://hydra.nixos.org/build/155015223
[2] https://help.nextcloud.com/t/update-to-next-cloud-21-0-2-has-get-an-error/117028/15
[3] setting `innodb_read_only_compressed=0`
Move to a forefront launch of the daemon. Doing so allowed us
to move the service from forking to simple to avoid the
missing pid error log.
Also:
- Make the dbus dependency explicit.
The MemoryDenyWriteExecute systemd option is widely known to be
incompatible with nodejs, and causes service crashes as reported in #119687.
Fixes #119687.
In opencv 2.x, unfree libraries are built by default. The package
should therefore have been marked as unfree, but wasn't.
I've disabled the non-free libraries by default, and added an option
to enable them. There are three programs in Nixpkgs that depend on
opencv2: mathematica, pfstools, and p2pvc. pfstools requires the
non-free libraries if it's built with opencv support, so I've disabled
opencv by default there and added an option to enable it. p2pvc links
fine, so presumably doesn't need the non-free libraries. I can't test
mathematica, so I'm just going to leave it alone.
This is to address a regression introduced in #131118.
When syncing the first dataset, syncoid expects that the target
dataset doesn't exist to have a clean slate to work with. So during
runtime we'll check if the target dataset does exist and if it doesn't
- delegate the permissions to the parent dataset instead.
But then, on unallow, we do the unallow on both the target and the
parent since the target dataset should have been created at this
point, so the unallow can't know which dataset that got permissions
just by which datasets exists.
