It has no effect with `subpixel.lcdfilter = "none"`.
If the user overrides the module's default, the correct subpixel order
depends on their actual monitor, and cannot be known by this module.
This makes it so that alternative packages, such as `pkgs.forgejo` are
able to be used instead of the default `pkgs.gitea`.
Also adds myself as a maintainer of the module.
The varible `gitea`, which was used instead of `cfg.package`, has been
replaced with the variable `exe`, and is instead the value of the main
executable, as gotten from `lib.getExe`. `cfg.package` is used when this
value is not appropriate.
Gitea spawns `gpg` processes for commit signing related actions.
Those `gpg` processes need `mlock` (probably to prevent secrets
in the memory to swap).
Blocking it (as part of the `@memlock` preset) causes any
commit signing related actions to error out as http/500
`/api/v1/signing-key.gpg` spawns a `gpg` process,
which is great to test if `gpg` is available
and can be invoked from in the unit.
Which is somewhat relevant, since `gpg` was
missing from the unit's `$PATH` until recently.
And even after adding `gpg` to the unit's `$PATH`,
configuring commit signing for a instance
resulted in http/500s nonetheless.
That's due to `@memlock` being present in
`SystemCallFilter=~` and `gpg` trying to
use `mlock` (probably to prevent secrets
in the memory to swap), resulting in an
immediate `SIGKILL` of any spawned `gpg` processes.
This makes the following work
disabledModules = [ foo.nixosModules.bar ];
even if `bar` is not a path, but rather a module such as
{ key = "/path/to/foo#nixosModules.bar"; config = ...; }
By supporting this, the user will often be able to use the same syntax
for both importing and disabling a module. This is becoming more relevant
because flakes promote the use of attributes to reference modules. Not
all of these modules in flake attributes will be identifiable, but with
the help of a framework such as flake-parts, these attributes can be
guaranteed to be identifiable (by outPath + attribute path).
adding two graphical programs makes a strong assmuption that users will
use a graphical environment.
add a command line program as an alternative suggestion that is easy to
comment in as a first-steps measure.
trying to get all of the podman functionality to work with the wrapper
is becoming more complicated with each release, it isn't sustainable
removing the wrapper does mean that using extraPackages will need to build from source
- remove unnecessary serviceConfig overrides
- set HELPER_BINARIES_DIR to libexec/podman
- use install.bin target on linux for podman/tmpfiles
- also installs quadlet/rootlessport in libexec
- symlink binaries from helpersBin into HELPER_BINARIES_DIR
- remove unnecessary rootlessport output
- remove unnecessary substituteInPlace
The defaults conflicts with the defaults of `services.httpd`:
```
error: The option `nodes.machine.services.logrotate.enable' has conflicting definition values:
- In `/home/thomas/Workspace/Packaging/nixpkgs/nixos/modules/profiles/minimal.nix': false
- In `/home/thomas/Workspace/Packaging/nixpkgs/nixos/modules/services/web-servers/apache-httpd/default.nix': true
Use `lib.mkForce value` or `lib.mkDefault value` to change the priority on any of these definitions.
(use '--show-trace' to show detailed location information)
```
`nixos/profile/minimal` is not used in the majority of the tests and it does not
seem to have a specific reason to use it for the HAProxy test.
* k3s: add environmentFile option
Enabling to include secrets through configuration such as 'sops'
* Update nixos/doc/manual/release-notes/rl-2305.section.md
Co-authored-by: Jairo Llopis <973709+yajo@users.noreply.github.com>
Nothing the script `config.sh` does prior to the final call to
`Runner.Listener configure` is relevant for the systemd service.
Particularly, we don't need (nor want) any of the artifacts the `env.sh`
script creates.
This reverts commit 2265160fc0 and
e56db577a1.
Ideally, we shouldn't cause friction for users that bump `stateVersion`,
and I'd consider having to switch and/or manually hardcode a UID/GID
to supress the warning friction. I think it'd be more beneficial to, in
this rare case of an ID being missed, just let it be until more
discussion happens surrounding this overall issue.
See https://github.com/NixOS/nixpkgs/pull/217785 for more context.
This reverts commits f5483464d5 and
6b9583e5e1.
Ideally, we shouldn't cause friction for users that bump `stateVersion`,
and I'd consider having to switch and/or manually hardcode a UID/GID
to supress the warning friction. I think it'd be more beneficial to, in
this rare case of an ID being missed, just let it be until more
discussion happens surrounding this overall issue.
See https://github.com/NixOS/nixpkgs/pull/217785 for more context.
Without this change, users that have both `initialHashedPassword` and
`hashedPassword` set will have `initialHashedPassword` take precedence,
but only for the first time `/etc/passwd` is generated. After that,
`hashedPassword` takes precedence. This is surprising behavior as it
would generally be expected for `hashedPassword` to win if both are set.
This wouldn't be a noticeable problem (and an assert could just be made
instead) if the users-groups module did not default the
`root.intialHashedPassword` value to `!`, to prevent login by default.
That means that users who set `root.hashedPassword` and use an ephemeral
rootfs (i.e. `/etc/passwd` is created every boot) are not able to log in
to the root account by default, unless they switch to a new generation
during the same boot (i.e. `/etc/passwd` already exists and
`hashedPassword` is used instead of `initialHashedPassword`) or they set
`root.initialHashedPassword = null` (which is unintuitive and seems
redundant).
Update protonmail-bridge to v3. This also rename the CLI executable from
protonmail-bridge to bridge to be more in line with upstream naming.
Co-authored-by: James Landrein <github@j4m3s.eu>
Signed-off-by: Arthur Outhenin-Chalandre <arthur.outhenin-chalandre@proton.ch>
It looks like the systemd-initrd variant of the systemd-shutdown test
(systemd-initrd-shutdown) did not actually enable the systemd-initrd and
so was just evaluating to the same store path before this change.
Since version 1.10.0 paperless-ngx depends on the NLTK library which is
used to pre-process data for machine learning. NLTK needs certain
data for stemming, stopword removal etc. This data has to be downloaded
first. This commit introduces a new systemd service that does the
downloading.
In general the man pages do not care what OS and manual they are shipped
with, so they don't get to choose the names of them. We were tempted to
do so, as we had inconsistently chosen OS names for the mandoc and
man-db/groff implementations. Since this has been rectified since, we
can just drop this boilerplate from the man pages.
Being able to override `boot.initrd.systemd.initrdBin` with `boot.initrd.systemd.extraBin` is a desirable behavior, so this PR changes the `ln -s` command to `ln -sf` to force link even if the file already exists.
The typo creates an empty directory 0755 in initrd rootfs rather than
create the Nix store directories with mode 0755.
I guess setting the mode is not strictly necessary if it worked before
this change, but I'll leave the `-m 0755` in just in case.
We’ve been having trouble figuring out which kind of token to use and
why our setup would break every few system updates.
This should clarify which options there are, and which ones lead to
better results.
Ideally there would be a manual section that has a step-by-step guide
on how to set up the github runner, with screenshots and everything.
Purge contents of `workDir` as root to also allow the removal of files
marked as read-only. It is easy to create read-only files in `workDir`,
e.g., by copying files from the Nix store.
This builds on top of nixpkgs mainline 00d8347180
with the following two PRs cherry-picked:
- https://github.com/NixOS/nixpkgs/pull/192670
- https://github.com/NixOS/nixpkgs/pull/192668
using the following command:
```
nix build -f nixos -L \
-I nixos-config=nixos/modules/installer/sd-card/sd-image-powerpc64le.nix \
config.system.build.sdImage
```
I was able to successfully boot the image, although it boots to a login prompt
rather than a shell, and won't accept the empty password for `root`. I guess
I'll have to figure out why that is.
To boot the image: `zstd`-decompress the it, mount it, and use `kexec`:
```
cd boot/nixos
kexec -l \
*-vmlinux \
--initrd *-initrd \
--dt-no-old-root \
--command-line="$(grep APPEND ../extlinux/extlinux.conf | sed 's_^ *APPEND *__')"
```
The machine I used for testing has only one storage device which is completely
allocated to LVM. It appears that the NixOS ISO loader doesn't look for
partition tables within LVM volumes. To work aroundn this, I had to extract the
`ext4` image within the partition table within the `sd-card` image and put that
in its own LVM volume. This likely won't be an obstacle for users who write the
image to a USB stick or similar.
Upstream has officially abandoned the project as of 2021 [0], there's been
no release since 2016, it uses the EoL Qt 4, and alternatives like
KeePassXC exist.
Also move KeePassXC to its own directory -- it doesn't make sense to
have it in KeePassX's folder anymore.
[0]: https://www.keepassx.org/index.html%3Fp=636.html
GDM and LightDM are already using this approach. It also allows us to
enable Kwallet integration more globally without generating stray PAM
services.
The default configuration of login service includes both options sddm
was setting explicitly.
This removes two unused service configs from /etc/pam.d/ and, more
importantly, reduces confusion.
* kdm no longer exists in nixpkgs
* `pam.d/gdm` is not used by gdm
* `pam.d/lightdm` IS used by lightdm but hardcoded using .text rather
than attrset+template.
this reproduces the docbook-generated html manual exactly enough to
appease the compare workflows while we still support both toolchains.
it's also a lot faster than the docbook toolchain, rendering the entire
html manual in about two seconds on this machine (while docbook needs
about 20).
{manpage} already exapnds to a link but akkoma wants to link to
a specific setting. split the mention for clarity.
networkd just straight up duplicated what {manpage} generates anyway, so
that link can go away completely.
the old method of pasting parts of options.json into a markdown document
and hoping for the best no longer works now that options.json contains
more than just docbook. given the infrastructure we have now we can
actually render options.md properly, so we may as well do that.
Provide a module to configure Coqui TTS, available as `tts` in nixpkgs
for a few releases already.
The module supports multiple servers in parallel, so multiple languages
and testing scenarios can be covered, without affecting any production
usage.
The test was failing because it was timing out. Turns out it was waiting
for `foo.kdbx`, which couldn't be "seen" even if it actually existed
(probably some contrast issues with the theme and OCR couldn't find it).
Fixed it by delegating the check to the next screen, where the full path
to the file is displayed in a bigger size. The test seems to pass.
Injecting configuration specific dependencies into the
propagatedBuildInputs of the home-assistant package forces alot of
rebuilds while setting up home-assistant, which is annoying.
By passing optional dependencies into home-assistant via the systemd
units PYTHONPATH environment variable, only he concatenation of
library paths in the systemd unit requires a rebuild.
This also means users can rely heavily on the cached home-assistant
package and will rarely have to build from source, if ever.
Prepare the tests for a change in dependency handling, by not relying on
bespoke files dropped into the package output.
Instead we now check the journal log for whether a configured component
was setup, once for the initial specialisation another time for the one
introducing esphome configuration.
Also improve abstractions for getting journal data relative to a cursor
and generally make a few things more concise.
options processing is pretty slow right now, mostly because the
markdown-it-py parser is pure python (and with performance
pessimizations at that). options parsing *is* embarassingly parallel
though, so we can just fork out all the work to worker processes and
collect the results.
multiprocessing probably has a greater benefit on linux than on darwin
since the worker spawning method darwin uses is less efficient than
fork() on linux. this hasn't been tested on darwin, only on linux, but
if anything darwin will be faster with its preferred method.
Since 1.2.0, kanata handles missing keyboards well:
- only one keyboard need to be present when kanata starts;
- if linux-continue-if-no-devs-found is set to yes, all keyboards can
be missing at the beginning;
- all keyboards can be (un)pluged when kanata is running.
For simplicity, linux-continue-if-no-devs-found is set to yes and
systemd patch activation is removed.
