Semi-automatic update generated by https://github.com/ryantm/nixpkgs-update tools.
This update was made based on information from https://repology.org/metapackage/radicale/versions.
These checks were done:
- built on NixOS
- ran ‘/nix/store/rbymr2y0pbx8n8b8bfz2gscafmby904x-radicale-2.1.9/bin/.radicale-wrapped -h’ got 0 exit code
- ran ‘/nix/store/rbymr2y0pbx8n8b8bfz2gscafmby904x-radicale-2.1.9/bin/.radicale-wrapped --help’ got 0 exit code
- ran ‘/nix/store/rbymr2y0pbx8n8b8bfz2gscafmby904x-radicale-2.1.9/bin/.radicale-wrapped --version’ and found version 2.1.9
- ran ‘/nix/store/rbymr2y0pbx8n8b8bfz2gscafmby904x-radicale-2.1.9/bin/radicale -h’ got 0 exit code
- ran ‘/nix/store/rbymr2y0pbx8n8b8bfz2gscafmby904x-radicale-2.1.9/bin/radicale --help’ got 0 exit code
- ran ‘/nix/store/rbymr2y0pbx8n8b8bfz2gscafmby904x-radicale-2.1.9/bin/radicale --version’ and found version 2.1.9
- found 2.1.9 with grep in /nix/store/rbymr2y0pbx8n8b8bfz2gscafmby904x-radicale-2.1.9
- directory tree listing: https://gist.github.com/e41acc1e5d5f2db9d8498cf5a989eb7f
First of all let's start with a clean up the multiline string
indentation for descriptions, because having two indentation levels
after description is a waste of screen estate.
A quick survey in the form of the following also reveals that the
majority of multiline strings in nixpkgs is starting the two beginning
quotes in the same line:
$ find -name '*.nix' -exec sed -n -e '/=$/ { n; /'\'\''/p }' {} + | wc -l
817
$ find -name '*.nix' -exec grep "= *'' *\$" {} + | wc -l
14818
The next point is to get the type, default and example attributes on top
of the description because that's the way it's rendered in the manual.
Most services have their enable option close to the beginning of the
file, so let's move it to the top.
Also, I found the script attribute for dhparams-init.service a bit hard
to read as it was using string concatenation to split a "for" loop.
Now for the more substantial clean ups rather than just code style:
* Remove the "with lib;" at the beginning of the module, because it
makes it easier to do a quick check with "nix-instantiate --parse".
* Use ConditionPathExists instead of test -e for checking whether we
need to generate the dhparams file. This avoids spawning a shell if
the file exists already and it's probably more common that it will
exist, except for the initial creation of course.
* When cleaning up old dhparams file, use RemainAfterExit so that the
unit won't be triggered again whenever we stop and start a service
depending on it.
* Capitalize systemd unit descriptions to be more in par with most
other unit descriptions (also see 0c5e837b66f58265ce2b66a33d0f47a3).
* Use "=" instead of "==" for conditionals using []. It's just a very
small nitpick though and it will only fail for POSIX shells. Bash on
the other side accepts it anyway.
Signed-off-by: aszlig <aszlig@nix.build>
Cc: @Ekleog
This option allows us to turn off stateful generation of Diffie-Hellman
parameters, which in some way is still stateful as the generated DH
params file is non-deterministic.
However what we can avoid with this is to have an increased surface for
failures during system startup, because generation of the parameters is
done during build-time.
Another advantage of this is that we no longer need to take care of
cleaning up the files that are no longer used and in my humble opinion I
would have preferred that #11505 (which puts the dhparams in the Nix
store) would have been merged instead of #22634 (which we have now).
Luckily we can still change that and this change gives the user the
option to put the dhparams into the Nix store.
Beside of the more obvious advantages pointed out here, this also
effects test runtime if more services are starting to use this (for
example see #39507 and #39288), because generating DH params could take
a long time depending on the bit size which adds up to test runtime.
If we generate the DH params in a separate derivation, subsequent test
runs won't need to wait for DH params generation during bootup.
Of course, tests could still mock this by force-disabling the service
and adding a service or activation script that places pre-generated DH
params in /var/lib/dhparams but this would make tests less readable and
the workaround would have to be made for each test affected.
Note that the 'stateful' option is still true by default so that we are
backwards-compatible with existing systems.
Signed-off-by: aszlig <aszlig@nix.build>
Cc: @Ekleog, @abbradar, @fpletz
We're going to implement an option which allows us to turn off stateful
handling of Diffie-Hellman parameter files by putting them into the Nix
store.
However, modules now might need a way to reference these files, so we
add a now path option to every param specified, which carries a
read-only value of the path where to find the corresponding DH params
file.
I've also improved the description of security.dhparams.params a bit so
that it uses <warning/> and <note/>.
The NixOS VM test also reflects this change and checks whether the old
way to specify the bit size still works.
Signed-off-by: aszlig <aszlig@nix.build>
Cc: @Ekleog
We're going to make changes to the dhparams module so we really want to
make sure we don't break it, so having a NixOS VM test is to make sure
we don't blow things up and can iterate on it.
Signed-off-by: aszlig <aszlig@nix.build>
Cc: @Ekleog
Semi-automatic update generated by https://github.com/ryantm/nixpkgs-update tools.
This update was made based on information from https://repology.org/metapackage/smplayer/versions.
These checks were done:
- built on NixOS
- ran ‘/nix/store/5vy4663v65r0ks1d1jcy0p24m2lk0zmh-smplayer-18.4.0/bin/smplayer -h’ got 0 exit code
- ran ‘/nix/store/5vy4663v65r0ks1d1jcy0p24m2lk0zmh-smplayer-18.4.0/bin/smplayer --help’ got 0 exit code
- found 18.4.0 with grep in /nix/store/5vy4663v65r0ks1d1jcy0p24m2lk0zmh-smplayer-18.4.0
- directory tree listing: https://gist.github.com/25ca7c094ad35c4c5ed4c2c33dfb9be2
Semi-automatic update generated by https://github.com/ryantm/nixpkgs-update tools.
This update was made based on information from https://repology.org/metapackage/tini/versions.
These checks were done:
- built on NixOS
- ran ‘/nix/store/h0h2qyxwrvsjy47m1xyv7sxzd2j0ilsi-tini-0.18.0/bin/tini -h’ got 0 exit code
- ran ‘/nix/store/h0h2qyxwrvsjy47m1xyv7sxzd2j0ilsi-tini-0.18.0/bin/tini --version’ and found version 0.18.0
- found 0.18.0 with grep in /nix/store/h0h2qyxwrvsjy47m1xyv7sxzd2j0ilsi-tini-0.18.0
- directory tree listing: https://gist.github.com/c992fd0a24dfc0365d6b62ac567d395c
Semi-automatic update generated by https://github.com/ryantm/nixpkgs-update tools.
This update was made based on information from https://repology.org/metapackage/thefuck/versions.
These checks were done:
- built on NixOS
- ran ‘/nix/store/p0waa9llvgzfvjv05vgwvsic2xlkm4jr-thefuck-3.26/bin/.thefuck-wrapped -h’ got 0 exit code
- ran ‘/nix/store/p0waa9llvgzfvjv05vgwvsic2xlkm4jr-thefuck-3.26/bin/.thefuck-wrapped --help’ got 0 exit code
- ran ‘/nix/store/p0waa9llvgzfvjv05vgwvsic2xlkm4jr-thefuck-3.26/bin/thefuck -h’ got 0 exit code
- ran ‘/nix/store/p0waa9llvgzfvjv05vgwvsic2xlkm4jr-thefuck-3.26/bin/thefuck --help’ got 0 exit code
- found 3.26 with grep in /nix/store/p0waa9llvgzfvjv05vgwvsic2xlkm4jr-thefuck-3.26
- directory tree listing: https://gist.github.com/7fd81df3f197603f76bdf8c0ae663dcb
Semi-automatic update generated by https://github.com/ryantm/nixpkgs-update tools.
This update was made based on information from https://repology.org/metapackage/yubikey-personalization/versions.
These checks were done:
- built on NixOS
- ran ‘/nix/store/gbg5yr1p726q33f057gwcjgq35jc8qg3-yubikey-personalization-1.19.0/bin/ykpersonalize -h’ got 0 exit code
- ran ‘/nix/store/gbg5yr1p726q33f057gwcjgq35jc8qg3-yubikey-personalization-1.19.0/bin/ykpersonalize --help’ got 0 exit code
- ran ‘/nix/store/gbg5yr1p726q33f057gwcjgq35jc8qg3-yubikey-personalization-1.19.0/bin/ykpersonalize -V’ and found version 1.19.0
- ran ‘/nix/store/gbg5yr1p726q33f057gwcjgq35jc8qg3-yubikey-personalization-1.19.0/bin/ykchalresp -h’ got 0 exit code
- ran ‘/nix/store/gbg5yr1p726q33f057gwcjgq35jc8qg3-yubikey-personalization-1.19.0/bin/ykchalresp --help’ got 0 exit code
- ran ‘/nix/store/gbg5yr1p726q33f057gwcjgq35jc8qg3-yubikey-personalization-1.19.0/bin/ykchalresp -V’ and found version 1.19.0
- ran ‘/nix/store/gbg5yr1p726q33f057gwcjgq35jc8qg3-yubikey-personalization-1.19.0/bin/ykinfo -h’ got 0 exit code
- ran ‘/nix/store/gbg5yr1p726q33f057gwcjgq35jc8qg3-yubikey-personalization-1.19.0/bin/ykinfo --help’ got 0 exit code
- ran ‘/nix/store/gbg5yr1p726q33f057gwcjgq35jc8qg3-yubikey-personalization-1.19.0/bin/ykinfo help’ got 0 exit code
- ran ‘/nix/store/gbg5yr1p726q33f057gwcjgq35jc8qg3-yubikey-personalization-1.19.0/bin/ykinfo -V’ and found version 1.19.0
- found 1.19.0 with grep in /nix/store/gbg5yr1p726q33f057gwcjgq35jc8qg3-yubikey-personalization-1.19.0
- directory tree listing: https://gist.github.com/6592e44c4a66c1b7cf2c9f4c2a75c3ab
Yeah yeah, I want parallel glob expansion but you get what I mean.
These two packages like getting upgraded together so to minimize
incompatibilities I'm upgrading them both in the same commit.
Following legacy packing conventions, `isArm` was defined just for
32-bit ARM instruction set. This is confusing to non packagers though,
because Aarch64 is an ARM instruction set.
The official ARM overview for ARMv8[1] is surprisingly not confusing,
given the overall state of affairs for ARM naming conventions, and
offers us a solution. It divides the nomenclature into three levels:
```
ISA: ARMv8 {-A, -R, -M}
/ \
Mode: Aarch32 Aarch64
| / \
Encoding: A64 A32 T32
```
At the top is the overall v8 instruction set archicture. Second are the
two modes, defined by bitwidth but differing in other semantics too, and
buttom are the encodings, (hopefully?) isomorphic if they encode the
same mode.
The 32 bit encodings are mostly backwards compatible with previous
non-Thumb and Thumb encodings, and if so we can pun the mode names to
instead mean "sets of compatable or isomorphic encodings", and then
voilà we have nice names for 32-bit and 64-bit arm instruction sets
which do not use the word ARM so as to not confused either laymen or
experienced ARM packages.
[1]: https://developer.arm.com/products/architecture/a-profile
(cherry picked from commit ba52ae50488de85a9cf60a3a04f1c9ca7122ec74)
Following legacy packing conventions, `isArm` was defined just for
32-bit ARM instruction set. This is confusing to non packagers though,
because Aarch64 is an ARM instruction set.
The official ARM overview for ARMv8[1] is surprisingly not confusing,
given the overall state of affairs for ARM naming conventions, and
offers us a solution. It divides the nomenclature into three levels:
```
ISA: ARMv8 {-A, -R, -M}
/ \
Mode: Aarch32 Aarch64
| / \
Encoding: A64 A32 T32
```
At the top is the overall v8 instruction set archicture. Second are the
two modes, defined by bitwidth but differing in other semantics too, and
buttom are the encodings, (hopefully?) isomorphic if they encode the
same mode.
The 32 bit encodings are mostly backwards compatible with previous
non-Thumb and Thumb encodings, and if so we can pun the mode names to
instead mean "sets of compatable or isomorphic encodings", and then
voilà we have nice names for 32-bit and 64-bit arm instruction sets
which do not use the word ARM so as to not confused either laymen or
experienced ARM packages.
[1]: https://developer.arm.com/products/architecture/a-profile
