In 87a19e9048 I merged staging-next into master using the GitHub gui as intended.
In ac241fb7a5 I merged master into staging-next for the next staging cycle, however, I accidentally pushed it to master.
Thinking this may cause trouble, I reverted it in 0be87c7979. This was however wrong, as it "removed" master.
This reverts commit 0be87c7979.
I merged master into staging-next but accidentally pushed it to master.
This should get us back to 87a19e9048.
This reverts commit ac241fb7a5, reversing
changes made to 76a439239e.
Minor incompatibilities due to moving to upstream defaults:
- capabilities are used instead of systemd.socket units
- the control socket moved:
/run/kresd/control -> /run/knot-resolver/control/1
- cacheDir moved and isn't configurable anymore
- different user+group names, without static IDs
Thanks Mic92 for multiple ideas.
Before c9214c394b and
9d396d2e42 if .git is symlink the version
would gracefully default to no git revision. With those changes an
exception is thrown instead.
This introduces a new function `pathIsGitRepo` that checks if
`commitIdFromGitRepo` fails without error so we don't have to
reimplement this logic again and can fail gracefully.
lib.commitIdFromGitRepo now resolves the refs from the
parent repository in case the supplied path is a file
containing the path to said repository. this adds support
for git-worktree and things alike. see gitrepository-layout(5).
this also:
- adds a new boolean function lib.pathIsRegularFile to
check whether a path is a regular file
- patches lib.revisionWithDefault and
the revision and versionSuffix attributes in
config.system.nixos in order to support git-worktrees
A centralized list for these renames is not good because:
- It breaks disabledModules for modules that have a rename defined
- Adding/removing renames for a module means having to find them in the
central file
- Merge conflicts due to multiple people editing the central file
Any system uid will do, so we let the system allocate
one for us. The 'mailman' group is gone entirely since
we don't need it. Users who wish to run the 'mailman'
administration utility can do so via 'sudo':
$ sudo -u mailman mailman info
Also, simplify the syntax of our user.users entry to
rely on an attribute set rather than a list.
Using "builtins.currentSystem" doesn't work in pure evaluation mode,
and even when it's explicitly set (which it always is, in
nixos/lib/eval-config.nix), it breaks manual generation because the
manual tries to render the default value.
It is referenced in various places, but does not work out of the box:
$ nixos-help
/run/current-system/sw/bin/nixos-help: unable to start a web browser; please set $BROWSER
In the user-hidden fallbacks to xdg-open(1) and w3m(1), `nixos-help`
expects tools to be deliberately installed by users.
For default installations and new users in general, this is unlikely to
be the case. Conversely, chances to use `nixos-help` are even higher
in such cases.
Use w3m-nographics by default to ensure documentation is always
available. The documentation browser on ttyS8 already does so, but is
not accessible in every installation, e.g. VMs with only ttyS0 and SSH
available.
This obsoletes including it in the base profile's systemPackages,
so remove the @TODO as done.
The autoLuks module is not really compatible with the updated systemd
version anymore. We started dropping NixOS specific patches that caused
unwanted side effects that we had to work around otherwise.
This change points users towards the relevant PR and spits out a bit of
information on how to deal with the situation.
Remove the btsync module. Bittorrent Sync was renamed to Resilio Sync in
2016, which is supported by the resilio module. Since Resilio Sync had
some security updates since 2016, it is not safe to run Bittorrent Sync
anymore.
I was pointed towards a small syntax error in the `nixpkgs.overlays`
documentation. There was a trailing semicolon after the overlay
function.
I also aligned the code a bit better so opening and closing brackets can
be visually matched much better (IMO).
Before this change `man 5 configuration.nix` would only show options of modules in
the `baseModules` set, which consists only of the list of modules in
`nixos/modules/module-list.nix`
With this change applied and `documentation.nixos.includeAllModules` option enabled
all modules included in `configuration.nix` file will be used instead.
This makes configurations with custom modules self-documenting. It also means
that importing non-`baseModules` modules like `gce.nix` or `azure.nix`
will make their documentation available in `man 5 configuration.nix`.
`documentation.nixos.includeAllModules` is currently set to `false` by
default as enabling it usually uncovers bugs and prevents evaluation.
It should be set to `true` in a release or two.
This was originally implemented in #47177, edited for more configurability,
documented and rebased onto master by @oxij.
This installs the kio "man:" protocol handler, which fixes the UNIX manual
section in the KDE Help Center.
Note that kde currently parses "/etc/man.conf" manually, if `$MANPATH` is not
set, to build its man page index. (if https://bugs.kde.org/show_bug.cgi?id=404022
is addressed, the "/etc/man.conf" symlink should not be necessary anymore)
This also includes a full end-to-end CockroachDB clustering test to
ensure everything basically works. However, this test is not currently
enabled by default, though it can be run manually. See the included
comments in the test for more information.
Closes#51306. Closes#38665.
Co-authored-by: Austin Seipp <aseipp@pobox.com>
Signed-off-by: Austin Seipp <aseipp@pobox.com>
* run as user 'slurm' per default instead of root
* add user/group slurm to ids.nix
* fix default location for the state dir of slurmctld:
(/var/spool -> /var/spool/slurmctld)
* Update release notes with the above changes
This reverts commit 10addad603, reversing
changes made to 7786575c6c.
NixOS scripts should be kept in the NixOS source tree, not in
pkgs. Moving them around is just confusing and creates unnecessary
code/history churn.
This commit adds the following
* the uucp user
* options for HylaFAX server to control startup and modems
* systemd services for HylaFAX server processes
including faxgettys for modems
* systemd services to maintain the HylaFAX spool area,
including cleanup with faxcron and faxqclean
* default configuration for all server processes
for a minimal working configuration
Some notes:
* HylaFAX configuration cannot be initialized with faxsetup
(as it would be common on other Linux distributions).
The hylafaxplus package contains a template spool area.
* Modems are controlled by faxgetty.
Send-only configuration (modems controlled by faxq)
is not supported by this configuration setup.
* To enable the service, one or more modems must be defined with
config.services.hylafax.modems .
* Sending mail *should* work:
HylaFAX will use whatever is in
config.services.mail.sendmailSetuidWrapper.program
unless overridden with the sendmailPath option.
* The admin has to create a hosts.hfaxd file somewhere
(e.g. in /etc) before enabling HylaFAX.
This file controls access to the server (see hosts.hfaxd(5) ).
Sadly, HylaFAX does not permit account-based access
control as is accepts connections via TCP only.
* Active fax polling should work; I can't test it.
* Passive fax polling is not supported by HylaFAX.
* Pager transmissions (with sendpage) are disabled by default.
I have never tested or used these.
* Incoming data/voice/"extern"al calls
won't be handled by default.
I have never tested or used these.
Take two of #40708 (4fe2898608).
That PR attempted to bidirectionally default `config.nixpkgs.system` and
`config.nixpkgs.localSystem.system` to each be updated by the other. But
this is not possible with the way the module system works. Divergence in
certain cases in inevitable.
This PR is more conservative and just has `system` default `localSystem`
and `localSystem` make the final call as-is. This solves a number of
issues.
- `localSystem` completely overrides `system`, just like with nixpkgs
proper. There is no need to specify `localSystem.system` to clobber the
old system.
- `config.nixpkgs.localSystem` is exactly what is passed to nixpkgs. No
spooky steps.
- `config.nixpkgs.localSystem` is elaborated just as nixpkgs would so
that all attributes are available, not just the ones the user
specified.
The remaining issue is just that `config.nixpkgs.system` doesn't update
based on `config.nixpkgs.localSystem.system`. It should never be
referred to lest it is a bogus stale value because
`config.nixpkgs.localSystem` overwrites it.
Fixes#46320
- based on module originally written by @srhb
- complies with available options in cfssl v1.3.2
- uid and gid 299 reserved in ids.nix
- added simple nixos test case
This reverts commit 095fe5b43d.
Pointless renames considered harmful. All they do is force people to
spend extra work updating their configs for no benefit, and hindering
the ability to switch between unstable and stable versions of NixOS.
Like, what was the value of having the "nixos." there? I mean, by
definition anything in a NixOS module has something to do with NixOS...
My c6f7d43678 made the mistake of not
having enough defaults. Now both variables are default as the *explicit*
value of the other, or a fallback. The fallback of `system` is the
default of `localSystem.system`. The fallback of `localSystem` is not
the other default (projected), as that would cause a cycle, but `{
system = builtins.currentTime; }` just as nixpkgs itself does it.
lib.optional returns a singleton or an empty list. Therefore the
argument does not need to be wrapped in a list.
An alternative patch could have used lib.optionals but seems like no
more elements are going to be added to the optional list.
As suggested in https://github.com/NixOS/nixpkgs/pull/39416#discussion_r183845745
the versioning attributes in `lib` should be consistent to
`nixos/version` which implicates the following changes:
* `lib.trivial.version` -> `lib.trivial.release`
* `lib.trivial.suffix` -> `lib.trivial.versionSuffix`
* `lib.nixpkgsVersion` -> `lib.version`
As `lib.nixpkgsVersion` is referenced several times in `NixOS/nixpkgs`,
`NixOS/nix` and probably several user's setups. As the rename will cause
a notable impact it's better to keep `lib.nixpkgsVersion` as alias with
a warning yielded by `builtins.trace`.
I know that "devinfo" output does not currently exist, but so does "devman".
It is mentioned in the nixpkgs manual, but no derivation in nixpkgs actually uses it.
a) Some providers can update multiple domains - support that.
b) Make "zone" and "script" configurable. Some providers require these.
c) Instead of leaving the ddclient daemon running all the time, use a systemd
timer to kick it off.
d) Don't use a predefined user - run everything via DynamicUser
e) Add documentation
- `localSystem` is added, it strictly supercedes system
- `crossSystem`'s description mentions `localSystem` (and vice versa).
- No more weird special casing I don't even understand
TEMP
This fixes the `update-locatedb` service when using the `mlocate`
package.
The service as-is does not properly handle flags during update of the
relevant database when configured to use the `mlocate` package.
The man entry for `updatedb` associated with `mlocate` does not say
that it supports environment variables in place of command line flags,
whereas the `findutils` package's updatedb does so.
To support this distinction, we pass the relevant settings as flags to
the `updatedb` program when using the `mlocate` package.
Fixes#29279
We should be able to deploy a NixOS 18.03 system with the current nixops
stable release. Some options were renamed, so instead of
`mkRenamedOptionModule` we introduce them as read-only interal options
that won't be rendered in the manual.
Only the options that are needed to make nixops evaluations succeed were
added.
This commit should probably be reverted after or before the 18.09 release,
depending on the nixops 1.6 release.
The user will not get the warning that these have been renamed but
this change is mentioned in the release notes.
Fixes#34253.
I was mainly considering Jellyfish and Jaguar (and Jackrabbit).
Originally I was inclined for Jellyfish, but then I thought of the
release T-shirts someone makes and it didn't seem suitable...
Jaguar would keep the name referring to a car as well, but as a
not-too-old (Mac) OS version is codenamed that way, I didn't go for it.
Resolved the following conflicts (by carefully applying patches from the both
branches since the fork point):
pkgs/development/libraries/epoxy/default.nix
pkgs/development/libraries/gtk+/3.x.nix
pkgs/development/python-modules/asgiref/default.nix
pkgs/development/python-modules/daphne/default.nix
pkgs/os-specific/linux/systemd/default.nix
