Support for *runner registration tokens* is deprecated since GitLab
16.0, has been disabled by default in GitLab 17.0 and will be removed in
GitLab 18.0, as outlined in the [GitLab documentation].
It is possible to [re-enable support for runner registration tokens]
until GitLab 18.0, to prevent the registration workflow from
breaking.
*Runner authentication tokens*, the replacement for registration tokens,
have been available since GitLab 16.0 and are expected to be defined in
the `CI_SERVER_TOKEN` environment variable, instead of the previous
`REGISTRATION_TOKEN` variable.
This commit adds a new option
`services.gitlab-runner.services.<name>.authenticationTokenConfigFile`.
Defining such option next to
`services.gitlab-runner.services.<name>.registrationConfigFile` brings
the following benefits:
- A warning message can be emitted to notify module users about the
upcoming breaking change with GitLab 17.0, where *runner registration
tokens* will be disabled by default, potentially disrupting
operations.
- Some configuration options are no longer supported with *runner
authentication tokens* since they will be defined when creating a new
token in the GitLab UI instead. New warning messages can be emitted to
notify users to remove the affected options from their configuration.
- Once support for *registration tokens* has been removed in GitLab 18,
we can remove
`services.gitlab-runner.services.<name>.registrationConfigFile` as
well and make module users configure an *authentication token*
instead.
This commit changes the option type of
`services.gitlab-runner.services.<name>.registrationConfigFile` to
`with lib.types; nullOr str` to allow configuring an authentication
token in
`services.gitlab-runner.services.<name>.authenticationTokenConfigFile`
instead.
A new assertion will make sure that
`services.gitlab-runner.services.<name>.registrationConfigFile` and
`services.gitlab-runner.services.<name>.authenticationTokenConfigFile`
are mutually exclusive. Setting both at the same time would not make
much sense in this case.
[GitLab documentation]: https://docs.gitlab.com/17.0/ee/ci/runners/new_creation_workflow.html#estimated-time-frame-for-planned-changes
[re-enable support for runner registration tokens]: https://docs.gitlab.com/17.0/ee/ci/runners/new_creation_workflow.html#prevent-your-runner-registration-workflow-from-breaking
My reasons following Mint are:
1. Geary signed https://stopthemingmy.app, per request we shouldn't pre-ship it under a themed desktop environment.
See also b7937b4509
2. Hexchat is still gtk2 and is not maintained anymore, Mint encourages switching to Matrix instead.
See also https://blog.linuxmint.com/?p=4675 ("Joining the Matrix")
frenck/spook includes a second manifest for an integration. The current
copyCustomComponents script assumed that only one component directory
will be found, which in this case resulted in a malformed symlink
destination:
lrwxrwxrwx 1 hass hass 224 Jun 23 17:23 spook -> '/nix/store/r41ics22zs578avzqf7x86plcgn2q71h-python3.12-frenck-spook-v3.0.1/custom_components/spook/integrations/spook_inverse'$'\n''/nix/store/r41ics22zs578avzqf7x86plcgn2q71h-python3.12-frenck-spook-v3.0.1/custom_components/spook'
Since stalwart-mail 0.6.0, queue and report files are located in
the shared `storage.{data,blob}` stores. The `{queue,report}.path`
settings no longer had any effect since then.
I'm also removing the creation of the associated extra directories
in the `preStart` script. This should not cause any issue with old
setups since 0.6.0 was already packaged when 24.05 was released.
There are several GPUs that ROCm doesn't officially support but
will work correctly if ROCm is directed to treat the GPU as a different
one that is supported and has a similar architecture.
This can be done by setting `HSA_OVERRIDE_GFX_VERSION`.
Ollama has documentation on this topic: https://github.com/ollama/ollama/blob/main/docs/gpu.md#amd-radeon
Originally, I wanted to execute `nextcloud-occ` with a higher memory
limit because I needed to trigger an expensive operation by hand,
regenerating a bunch of previews.
While doing so, I realized how painful it is to put an invocation of
nextcloud-occ together for that, especially when you need to put it
into another systemd unit in Nix code.
That's why I decided to use the memory limit now for every
CLI invocation just in case. The stuff you do in those units (e.g.
running background jobs) is something you can also do by hand with
`nextcloud-occ` and you'll most likely want to have the same memory
limit there.
This option is actually useful when having a systemd unit invoking
`nextcloud-occ`, then you want to do something like
path = [ config.services.nextcloud.occ ]
This is possible today, but not documented (and the option completion
from nil doesn't pick it up as a result).
debug_level 65510 (0x3f7f0) is _extremely_ verbose, far more than one
would want in normal operation. Setting these in the default config
also makes it difficult to override in a user config. Anyone who needs
greater verbosity can add these options to their own sssd config, or
adjust them at runtime with `sssctl debug-level`.
