The comment at the top of git-and-tools/default.nix said:
/* All git-relates tools live here, in a separate attribute set so that users
* can get a fast overview over what's available.
but unfortunately that hasn't actually held up in practice.
Git-related packages have continued to be added to the top level, or
into gitAndTools, or sometimes both, basically at random, so having
gitAndTools is just confusing. In fact, until I looked as part of
working on getting rid of gitAndTools, one program (ydiff) was
packaged twice independently, once in gitAndTools and once at the top
level (I fixed this in 98c34901969).
So I think it's for the best if we move away from gitAndTools, and
just put all the packages it previously contained at the top level.
I've implemented this here by just making gitAndTools an alias for the
top level -- this saves having loads of lines in aliases.nix. This
means that people can keep referring to gitAndTools in their
configuration, but it won't be allowed to be used within Nixpkgs, and
it won't be presented to new users by e.g. nix search.
The only other change here that I'm aware of is that
appendToName "minimal" is not longer called on the default git
package, because doing that would have necessitated having a private
gitBase variable like before. I think it makes more sense not to do
that anyway, and reserve the "minimal" suffix only for gitMinimal.
Now that smtp_tls_security_level is using mkDefault, and therefore can
be overridden, there's no need for an option for overriding it to a
specific value.
I run Postfix on my workstation as a smarthost, where it only ever
talks to my SMTP server. Because I know it'll only ever connect to
this server, and because I know this server supports TLS, I'd like to
set smtp_tls_security_level to "encrypt" so Postfix won't fall back to
an unencrypted connection.
With libcap 2.41 the output of cap_to_text changed, also the original
author of code hoped that this would never happen.
To counter this now the security-wrapper only relies on the syscall
ABI, which is more stable and robust than string parsing. If new
breakages occur this will be more obvious because version numbers will
be incremented.
Furthermore all errors no make execution explicitly fail instead of
hiding errors behind debug environment variables and the code style was
more consistent with no goto fail; goto fail; vulnerabilities (https://gotofail.com/)
This commits deprecates `services.xserver.libinput` for multiple
settings, one for each kind of device:
- `services.xserver.libinput.mouse`
- `services.xserver.libinput.touchpad`
Looking at `man 4 libinput`, they basically have the same options so I
simply replicated them, even if some options doesn't make sense for
mouse (`tapping` for example).
With this commit this is now possible:
```nix
{
services.xserver.libinput = {
enable = true;
mouse = {
accelProfile = "flat";
};
touchpad = {
naturalScrolling = true;
};
};
}
```
And you will have a mouse with no natural scrolling but with accel
profile flat, while touchpad will have natural scrolling but accel
profile adaptative (default).
It is possible to support more device types
(tablets/keyboards/touchscreens), but at least looking at the
libinput manual for those devices it doesn't seem that it has any
configuration options for them. They can still be configured using
`services.xserver.inputClassSections` though, and this will work now
since there is no rule by default that matches them.
Closes issue #75007, while also making configuration of mouses and
touchpads using Nix attrs possible like said in PR #73785.
I found a logical error in the bash script, but during
debugging I enabled command echoing and realised it
would be a good idea to have it enabled all the time for
ease of bug reporting.
Originally, changes to the kernel don't propagate to the other
derivation within the same package set. This commit allows for the
changes in the kernel to be propagated.
A distinct example is setting `boot.kernel.randstructSeed` to a non-zero
length string which would result in building 2 kernels, one with the
correct seed and the other with the zero length seed. Then, when using
an out-of-tree kernel driver, it would be built with the zero length
seed which differs from the non-zero length seed used to boot,
contradicting the purpose of the `boot.kernel.randstructSeed`.
