Also removed `pkgs.hydra-flakes` since flake-support has been merged
into master[1]. Because of that, `pkgs.hydra-unstable` is now compiled
against `pkgs.nixFlakes` and currently requires a patch since Hydra's
master doesn't compile[2] atm.
[1] https://github.com/NixOS/hydra/pull/730
[2] https://github.com/NixOS/hydra/pull/732
Instead of making the configuration less portable by hard coding the number of
jobs equal to the cores we can also let nix set the same number at runtime.
Some changes might require manual migration steps:
"Due to changes to the way in which Gollum handles filenames, you may
have to change some links in your wiki when migrating from gollum 4.x.
See the release notes [0] for more details. You may find the
bin/gollum-migrate-tags script helpful to accomplish this. Also see the
--lenient-tag-lookup option for making tag lookup backwards compatible
with 4.x, though note that this will decrease performance on large wikis
with many tags." (source: [1])
[0]: https://github.com/gollum/gollum/wiki/5.0-release-notes
[1]: https://github.com/gollum/gollum/blob/v5.0.0/HISTORY.md
We have this bug https://github.com/elementary/gala/issues/636
when using notifications in gala. It's likely to not really be fixed
because all development is on the new notifications server.
Them removing cerbere and registering with the SessionManager
should make shutdown very fast. This was even done in plank [0]
which was the last factor outside cerbere causing this.
[0]]: a8d2f255b2
As discussed in https://github.com/NixOS/nixpkgs/pull/73763, prevailing
consensus is to revert that commit. People use the hardened profile on
machines and run nix builds, and there's no good reason to use
unsandboxed builds at all unless you're in a platform that doesn't
support them.
This reverts commit 00ac71ab19.
So now we have only packages for human interaction in php.packages and
only extensions in php.extensions. With this php.packages.exts have
been merged into the same attribute set as all the other extensions to
make it flat and nice.
The nextcloud module have been updated to reflect this change as well
as the documentation.
In 7f838b4dde, we dropped systemd-udev-settle.service from display-manager.service's wants.
Unfortunately, we are doing something wrong since without it both Xorg and Wayland fail to start:
Failed to open gpu '/dev/dri/card0': GDBus.Error:org.freedesktop.DBus.Error.AccessDenied: Operation not permitted
Until we sort this out, let's add systemd-udev-settle.service to GDM to unblock the channels.
In contrast to `.service`-units, it's not possible to declare an
`overrides.conf`, however this is done by `generateUnits` for `.nspawn`
units as well. This change breaks the build if you have two derivations
configuring one nspawn unit.
This will happen in a case like this:
``` nix
{ pkgs, ... }: {
systemd.packages = [
(pkgs.writeTextDir "etc/systemd/nspawn/container0.nspawn" ''
[Files]
Bind=/tmp
'')
];
systemd.nspawn.container0 = {
/* ... */
};
}
```
This allows you to specify the system-wide flake registry. One use is
to pin 'nixpkgs' to the Nixpkgs version used to build the system:
nix.registry.nixpkgs.flake = nixpkgs;
where 'nixpkgs' is a flake input. This ensures that commands like
$ nix run nixpkgs#hello
pull in a minimum of additional store paths.
You can also use this to redirect flakes, e.g.
nix.registry.nixpkgs.to = {
type = "github";
owner = "my-org";
repo = "my-nixpkgs";
};
Many options define their example to be a Nix value without using
literalExample. This sometimes gets rendered incorrectly in the manual,
causing confusion like in https://github.com/NixOS/nixpkgs/issues/25516
This fixes it by using literalExample for such options. The list of
option to fix was determined with this expression:
let
nixos = import ./nixos { configuration = {}; };
lib = import ./lib;
valid = d: {
# escapeNixIdentifier from https://github.com/NixOS/nixpkgs/pull/82461
set = lib.all (n: lib.strings.escapeNixIdentifier n == n) (lib.attrNames d) && lib.all (v: valid v) (lib.attrValues d);
list = lib.all (v: valid v) d;
}.${builtins.typeOf d} or true;
optionList = lib.optionAttrSetToDocList nixos.options;
in map (opt: {
file = lib.elemAt opt.declarations 0;
loc = lib.options.showOption opt.loc;
}) (lib.filter (opt: if opt ? example then ! valid opt.example else false) optionList)
which when evaluated will output all options that use a Nix identifier
that would need escaping as an attribute name.
This windowManager and desktopManager doesn't even have
an option to use it. git history suggests to me that there's no way anyone
finds this useful anymore.
* creating a local backup
* creating a borgbackup server
* backing up to a borgbackup server
* hints about the Vorta graphical desktop application
* Added documentation about Vorta desktop client
Tested the examples locally and with my borgbase.com account.
Upgrades Hydra to the latest master/flake branch. To perform this
upgrade, it's needed to do a non-trivial db-migration which provides a
massive performance-improvement[1].
The basic ideas behind multi-step upgrades of services between NixOS versions
have been gathered already[2]. For further context it's recommended to
read this first.
Basically, the following steps are needed:
* Upgrade to a non-breaking version of Hydra with the db-changes
(columns are still nullable here). If `system.stateVersion` is set to
something older than 20.03, the package will be selected
automatically, otherwise `pkgs.hydra-migration` needs to be used.
* Run `hydra-backfill-ids` on the server.
* Deploy either `pkgs.hydra-unstable` (for Hydra master) or
`pkgs.hydra-flakes` (for flakes-support) to activate the optimization.
The steps are also documented in the release-notes and in the module
using `warnings`.
`pkgs.hydra` has been removed as latest Hydra doesn't compile with
`pkgs.nixStable` and to ensure a graceful migration using the newly
introduced packages.
To verify the approach, a simple vm-test has been added which verifies
the migration steps.
[1] https://github.com/NixOS/hydra/pull/711
[2] https://github.com/NixOS/nixpkgs/pull/82353#issuecomment-598269471
After upgrading to NixOS 20.03, I've got the following warning:
nginx: [warn] could not build optimal types_hash, you should increase either types_hash_max_size: 2048 or types_hash_bucket_size: 64; ignoring types_hash_bucket_size
The documentation states that "if nginx emits the message requesting
to increase either hash max size or hash bucket size then the first
parameter should first be increased" (aka types_hash_max_size).
In 19.03, the size of mime.types was around 100 entries. In 20.03, we
are around 900 entries. This is due to ff0148d868 which makes nginx
use mailcap mime.types.
In ff0148d868, nginx configuration was modified to use mime.types
from mailcap package as it is more complete. However, there are two
places where mime.types is included in configuration. When the user
was setting `cfg.httpConfig`, the mime.types from nginx was still
used. This commit fix that by moving the common snippet in a variable
of its own and ensure it is used at both places.
While our ETag patch works pretty fine if it comes to serving data off
store paths, it unfortunately broke something that might be a bit more
common, namely when using regexes to extract path components of
location directives for example.
Recently, @devhell has reported a bug with a nginx location directive
like this:
location ~^/\~([a-z0-9_]+)(/.*)?$" {
alias /home/$1/public_html$2;
}
While this might look harmless at first glance, it does however cause
issues with our ETag patch. The alias directive gets broken up by nginx
like this:
*2 http script copy: "/home/"
*2 http script capture: "foo"
*2 http script copy: "/public_html/"
*2 http script capture: "bar.txt"
In our patch however, we use realpath(3) to get the canonicalised path
from ngx_http_core_loc_conf_s.root, which returns the *configured* value
from the root or alias directive. So in the example above, realpath(3)
boils down to the following syscalls:
lstat("/home", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
lstat("/home/$1", 0x7ffd08da6f60) = -1 ENOENT (No such file or directory)
During my review[1] of the initial patch, I didn't actually notice that
what we're doing here is returning NGX_ERROR if the realpath(3) call
fails, which in turn causes an HTTP 500 error.
Since our patch actually made the canonicalisation (and thus additional
syscalls) necessary, we really shouldn't introduce an additional error
so let's - at least for now - silently skip return value if realpath(3)
has failed.
However since we're using the unaltered root from the config we have
another issue, consider this root:
/nix/store/...-abcde/$1
Calling realpath(3) on this path will fail (except if there's a file
called "$1" of course), so even this fix is not enough because it
results in the ETag not being set to the store path hash.
While this is very ugly and we should fix this very soon, it's not as
serious as getting HTTP 500 errors for serving static files.
I added a small NixOS VM test, which uses the example above as a
regression test.
It seems that my memory is failing these days, since apparently I *knew*
about this issue since digging for existing issues in nixpkgs, I found
this similar pull request which I even reviewed:
https://github.com/NixOS/nixpkgs/pull/66532
However, since the comments weren't addressed and the author hasn't
responded to the pull request, I decided to keep this very commit and do
a follow-up pull request.
[1]: https://github.com/NixOS/nixpkgs/pull/48337
Signed-off-by: aszlig <aszlig@nix.build>
Reported-by: @devhell
Acked-by: @7c6f434c
Acked-by: @yorickvP
Merges: https://github.com/NixOS/nixpkgs/pull/80671
Fixes: https://github.com/NixOS/nixpkgs/pull/66532
The volumeID will now be in the format of:
nixos-$EDITON-$RELEASE-$ARCH
an example for the minimal image would look like:
nixos-minimal-20.09-x86-64-linux
