The current `remotes` option is a string option containing nullmailer remote
definitions. However, those definitions may contain secret credentials and
should therefore not be put world-readable in the nix store.
I added a `remotesFile` option, which allows to specify a path to the remotes
definition file instead. This way, the definitions can be kept outside of the
nix store with more secure file permissions.
(cherry picked from commit e741cc4881)
Apparently gwrap will not compile with guile-2.2 [1], even though the
news for version 1.9.15 says it "allows" Guile 2.2 [2]:
> it will _not_ compile using 2.2
Furthermore, it seems like it isn't being developed anymore either [1]:
> Also note that g-wrap itself is not being further developed anymore,
> it is recommended for new projects to use Guile's dynamic FFI.
Also, guile-gnome-2.16.5 is apparently compatible with guile-2.2 [3],
but I'm not sure how they built it with guile-2.2 because gwrap 1.9.15
(latest release) apparently doesn't build with guile-2.2. (And certainly
when I try to build gwrap 1.9.15 with guile-2.2 it doesn't work. Maybe
it can be made to work with certain compile flags, but I haven't pursued
that further due to [1] anyway.) This is why guile-gnome is still on
2.16.4 here. Because, although 2.16.5 can still (apparently) build with
guile-2.0.14, guile_2_0 is only at guile-2.0.13.
So to update guile-gnome to 2.16.5, guile_2_0 would first have to be
updated to 2.0.14.
[1]: http://lists.nongnu.org/archive/html/g-wrap-dev/2016-08/msg00001.html
[2]: http://www.nongnu.org/g-wrap/news.html
[3]: https://www.gnu.org/software/guile-gnome/news.html
(cherry picked from commit f1b7d0a54f)
This also upgrades the hsevm package from v0.6.4 to v0.8.5.
The project `dapp` which depends on hsevm was also updated to use the
new name, so I have also upgraded that package from version v0.5.3 to
v0.5.7.
I also added a `dontCheck` to a Hackage dependency because its test
suite depends on Git and runs a bunch of Git repository manipulations.
(cherry picked from commit 74edd2c5db)
building
Extracting Bazel installation...
Loading:
Analyzing: target //source/exe:envoy-static
ERROR: java.io.IOException: Could not read the crosstool configuration file 'CROSSTOOL file /tmp/nix-build-envoy-1.3.0.drv-0/envoy-v1.3.0-src/.home/.cache/bazel/_bazel_nixbld1/cbe181aaebf3d7253cbcf6057028e514/external/local_config_cc/CROSSTOOL', because of a parser error (945:1: Expected identifier. Found '%')
INFO: Elapsed time: 3.065s
FAILED: Build did NOT complete successfully
builder for ‘/nix/store/09wh9hd81529pgr3ddwfw68higfzkfgr-envoy-1.3.0.drv’ failed with exit code 2
error: build of ‘/nix/store/09wh9hd81529pgr3ddwfw68higfzkfgr-envoy-1.3.0.drv’ failed
(cherry picked from commit 49a060ea1f)
The build provides as text a summary of the build, including the
absolute path of the compiler used for compilation. Unfortunately, this
pulls in stdenv.cc as a transitive closure.
So this change just calls remove-references-to as a postInstall step for
the one stdenv.cc dependency.
See #29889 for details.
(cherry picked from commit 405c7f9e437a89bbebc3e2663e8fcc74e69783d6)
Consul is a service you typically want to have running all the time;
it's not supposed to quit by itself.
(cherry picked from commit f4c53f1940)
Closes#29861.
We now wait for dhcpcd to acquire a lease but dhcpcd is restarted on
system activation. As wpa_supplicant is stopped while dhcpcd is
restarting a significant delay is introduced on systems with wireless
network connections only. This changes the wpa_supplicant service to
also be restarted together with dhcpcd in case both services were
changed.
(cherry picked from commit 725dee203a)
This reverts commit 0c81594a29.
It's no longer needed since systemd-vconsole-setup enumerates all ttys
until it finds a suitable one since systemd v234.
(cherry picked from commit 4a2442032e)
The current version is broken:
- there's no `openFirewall` attribute directly in the `cfg` set
- the `port` option is an attribute of the `confOptions` set
I used the proper attribute for the firewall port and moved the `openFirewall`
option directly up to the `services.znc` set, as it's rather a general option
for the whole service than a znc-specific option (which are located inside the
`confOptions` set).
Unfortunately wlc 0.0.10 seems to be the cause for segfaults on sway,
way-cooler and orbment.
This will also build wlc with all optional packages (i.e. zlib,
valgrind and doxygen).
(cherry picked from commit 2d640b9d6e)
* Grants enough privileges to the configured user so that it can run
mysqldump.
* Adds a nixos test.
* Use systemd timers instead of a cronjob (by @fadenb).
* Creates a new user for backups by default, instead of using mysql
user.
* Ensures that backup user has write permissions on backup location.
* Write backup to a temporary file before renaming so that a failed
backup won't overwrite the previous backup, and so that the backup
location will never contain a partial backup.
Breaking changes:
* Renamed period to calendar to reflect the change in how to
configure the backup time.
* A failed backup will no longer result in cron sending an e-mail --
users' monitoring systems must be updated.
Resolves#24728
(cherry picked from commit 56eba66f77)
tinc can figure this out based on DeviceType.
I also got `/dev/net/tun FD in bad state` after a particular upgrade.
(cherry picked from commit ad8cb0917f)
While it's annoying to pollute the user database with a lot of nixbld*
users, 10 users is really too low for many modern systems.
(cherry picked from commit 79d547b4bb)
* openjdk 8: code cleanup
as recommended by 0xABAB in #27194
* openjdk 9: init at ea build 176
this starts with copy of 8.nix and just updates hashes and replaces 8
with 9. it also tweaks the version handling because we aren't dealing
with an update version yet.
* openjdk 9: adapt patches from openjdk 8
fix-java-home: surrounding code changed slightly
swing-use-gtk-jdk9: location of the file being patched changed due to
modularization
read-truststore-from-env: the code that handles the trustStore was
refactored out into a helper class in upstream commit
http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/904861872c0e
adlc_updater: this isn't present anymore
* openjdk 9: make two more warnings-as-errors non-fatal
this requires that we switch to configureFlagsArray to deal with
whitespace
the errors being suppressed are show below:
* For target support_native_java.desktop_libawt_xawt_awt_Robot.o:
/tmp/nix-build-openjdk-9ea-b176.drv-0/jdk9-jdk-9+176/jdk/src/java.desktop/unix/native/libawt_xawt/awt/awt_Robot.c: In function 'isXCompositeDisplay':
/tmp/nix-build-openjdk-9ea-b176.drv-0/jdk9-jdk-9+176/jdk/src/java.desktop/unix/native/libawt_xawt/awt/awt_Robot.c:152:50: error: embedded '\0' in format
[-Werror=format-contains-nul]
snprintf(NET_WM_CM_Sn, sizeof(NET_WM_CM_Sn), "_NET_WM_CM_S%d\0", screenNumber);
^
/tmp/nix-build-openjdk-9ea-b176.drv-0/jdk9-jdk-9+176/jdk/src/java.desktop/unix/native/libawt_xawt/awt/awt_Robot.c:152:50: error: embedded '\0' in format
[-Werror=format-contains-nul]
cc1: all warnings being treated as errors
* For target support_native_jdk.hotspot.agent_libsa_ps_core.o:
/tmp/nix-build-openjdk-9ea-b176.drv-0/jdk9-jdk-9+176/hotspot/src/jdk.hotspot.agent/linux/native/libsaproc/ps_core.c: In function 'read_exec_segments':
/tmp/nix-build-openjdk-9ea-b176.drv-0/jdk9-jdk-9+176/hotspot/src/jdk.hotspot.agent/linux/native/libsaproc/ps_core.c:834:7: error: ignoring return value of 'pread', declared
with attribute warn_unused_result [-Werror=unused-result]
pread(ph->core->exec_fd, interp_name, exec_php->p_filesz, exec_php->p_offset);
^
cc1: all warnings being treated as errors
* openjdk 9: ea+176 -> ea+180
* openjdk 9: TODO disable infinality patches, at least to start
the code being patched here seems to have changed substantially or
perhaps even disappeared altogether. need to investigate whether
these patches are still relevant.
* openjdk 9: update installPhase for modularization
* separate jdk and jre images are now present under build/*/images
* samples have been removed (JEP 298)
-- TODO that JEP says demos will be gone too, but it seems some are still present?
* bina directory is no longer present
* openjdk 9: TODO handle *.pf files or purge this code completely
* openjdk 9: update minimal jre components
in particular, the name of the config option for headless has changed,
per https://bugs.openjdk.java.net/browse/JDK-8163102
* TODO about echo -n vs printWords, #27427
(cherry picked from commit 02fe1207ab)
Spamassassin expects its system-wide configuration at /etc/spamassassin, and
some user tools (like sa-learn) need to read those configuration files.
Therefore, we provide a symlink from /etc/spamassassin to the appropriate Nix
store path to make sure those tools work without the user having to pass an
elaborate --siteconfig path that, potentially, changes every time the system
updates.
Fixes https://github.com/NixOS/nixpkgs/issues/29414.
(cherry picked from commit bfab392e6e)
Storing the build configuration caused Firefox to retain a dependency
on gcc, glibc.dev and icu4c.dev.
This reduces the size of the firefox closure from 587 to 415 MiB.
(cherry picked from commit c03326445b)
This reduces the closure size of Emacs from 575 to 279 MiB. Dumping
Emacs had a chance of leaking parts of the environment (such as $PATH)
into the dumped executable. This hopefully fixes it. (It's a bit hard
to tell since the effect is not deterministic.)
(cherry picked from commit cf599d3f99)
In particular, this moves share/kf5 to the "out" output. This prevents
kdelibs4support from pulling kdoctools.dev into its closure (via
share/kf5/kdoctools/customization/dtd/kdex.dtd, which references
${kdoctools}/share/kf5).
This reduces the closure size of kdelibs4support by 156 MiB.
(cherry picked from commit b790a31204)
While the last wlc upgrade (05d79c03ec)
makes it possible to build sway 0.14.0 it also breaks the current build
of sway 0.13.0.
Unfortunately sway 0.14.0 segfaults on launch and I couldn't fix it yet
(there are multiple upstream issues as well). I'll overwrite the wlc
version for sway in order to have a usable version in nixpkgs for the
meantime.
(cherry picked from commit 676f5cb02c)
The code was a bit messy (unused parameters, etc.) and caused some
warnings/errors which could potentially cause some problems.
(cherry picked from commit 4b85b23534)
Oracle JDK 9 does not seems to contain jre directory, so oraclejre9
package now uses a dedicated archive file.
There is no 32-bit version nor arm version (yet). If Oracle releases
them, I will update the package.
(cherry picked from commit 692fcd9f53)
oslo-service:
needs to disable tests due to network errors when importing eventlet
for tests ( socket.getprotobyname('tcp') -> no such protocol )
eventlet: 0.17.4 -> 0.20.0
cannot update to 0.21.0 due to version pinning ( < 0.21.0 ) of oslo-service
monotonic: 0.4 -> 1.3
oslo-serialization: 1.10.0 -> 2.20.0
oslo-utils: 2.6.0 -> 3.29.0
oslo-concurrency: 2.7.0 -> 3.22.0
oslo-log: 1.12.1 -> 3.31.0
oslo-context: 0.7.0 -> 2.18.1
routes: 1.12.3 -> 2.4.1
webob: 1.4.1 -> 1.7.3
when updating i rewrote the package to use fetchPypi for making future
updating easier
(cherry picked from commit 78621e384c)
also updated the following dependencies:
keystoneauth1: 3.1.0 -> 3.2.0
disabled tests which require oslo-config, oslo-test or requests-kerberos
oslo-i18n: 2.7.0 -> 3.18.0
oslotest: 1.12.0 -> 2.18.0
os-client-config: 1.8.1 -> 1.28.0
needed to disable testing due to circular dependency with oslotest
mox3: 0.11.0 -> 0.23.0
disable tests for py36 due to upstream bug
debtcollector: 0.9.0 -> 1.17.0
tests enabled
extra packages:
requestsexceptions: init at 1.3.0
(cherry picked from commit 7251699081)
Add testssl.sh which is a nice utility for testing TLS/SSL
capabilities of servers without having to use any kind of
web-service. It's very useful for testing setups of services before
deployment and such.
(cherry picked from commit 02d9d40d99)
Currently, the contents closure is copied to the layer but there is no
nix database initialization. If pkgs.nix is added in the contents,
nix-store doesn't work because there is no nix database.
From the contents of the layer, this commit generates and loads the
database in the nix store of the container. This only works if there
is no parent layer that already have a nix store (to support several
nix layers, we would have to merge nix databases of parent layers).
We also add an example to play with the nix store inside the
container. Note it seems `more` is a missing dependency of the nix
package!
(cherry picked from commit df589a438e)
The openldap dependency is only used for the audisp z/OS plugin.
This is not useful on Linux, so always disable this.
(cherry picked from commit 49fc06ed0a)
Multiprocess tabs always crash, as first reported by the issue mentioned
below. It is now consistently reproducible both on NixOS and non-NixOS
for me, so I've decided to add a toggle to conveniently disable
multiprocess support as a work-around.
Closes https://github.com/NixOS/nixpkgs/issues/27759 but does
not really fix the underlying problem ...
(cherry picked from commit 69e3817eb6)
Systemd is complaining that it can't delay the startup of device units.
We have a before dependency on the respective device unit for every
netdev service, which doesn't make any sense because we create the
actual interface in this service.
(cherry picked from commit 13a110e696)
Previously, depending on the environment and the type of interface that
was created, the configured IPs of an interface wouldn't be applied on a
nixos-rebuild switch. It works after a reboot.
This patch ensures that the network-addresses service is started
either via the network-link service or if the networking target is
activated (i.e. on system activation).
Fixes#28474#16230.
(cherry picked from commit 3a670daa98)
The program `qemu-img` is needed during creation of virtual machines
with qcow2 images. Otherwise creation of such VMs (e.g. with
virt-manager) are failing.
(cherry picked from commit 32e4e2c47b)
kbfs was not working with the lastest keybase update
(ef3cb5cc47).
We should enforce update of keybase/keybase-ui and kbfs (like done here:
f74a1e6bcb)
all together to avoid API problems.
(cherry picked from commit b50ae94ed3)
* gnome3: only maintain single GNOME 3 package set
GNOME 3 was split into 3.10 and 3.12 in #2694. Unfortunately, we barely have the resources
to update a single version of GNOME. Maintaining multiple versions just does not make sense.
Additionally, it makes viewing history using most Git tools bothersome.
This commit renames `pkgs/desktops/gnome-3/3.24` to `pkgs/desktops/gnome-3`, removes
the config variable for choosing packageset (`environment.gnome3.packageSet`), updates
the hint in maintainer script, and removes the `gnome3_24` derivation from `all-packages.nix`.
Closes: #29329
* maintainers/scripts/gnome: Use fixed GNOME 3 directory
Since we now allow only a single GNOME 3 package set, specifying
the working directory is not necessary.
This commit sets the directory to `pkgs/desktops/gnome-3`.
(cherry picked from commit 69698ec11c)
- add flannel support
- remove deprecated authorizationRBACSuperAdmin option
- rename from deprecated poratalNet to serviceClusterIpRange
- add nodeIp option for kubelet
- kubelet, add br_netfilter to kernelModules
- enable firewall by default
- enable dns by default on node and on master
- disable iptables for docker by default on nodes
- dns, restart on failure
- update tests
and other minor changes
(cherry picked from commit 7dfeac88ac)
The libcrypto patch didn't work well with `salt-ssh` (that code failed on
remote machines), so let's make Nix-based library lookup as fallback.
https://github.com/saltstack/salt/issues/43350
(cherry picked from commit a5b8c0c2de)
reading the code, it's hard to see how this test was *ever* supposed to
pass. interestingly, peeking across the fence, guix have disabled this test
too for the same reason.
note that tests don't actually run *at all* on py27 but that's a problem
for another day
(cherry picked from commit 9ca4f39b97)
Error is:
ERROR: In procedure %resolve-variable:
ERROR: Unbound variable: use-syntax
FAIL: sxml.ssax.scm
Also add pkg-config so that configure script can find libguile.
Relevant to #28643
(cherry picked from commit 913e770fa8)
1. The chmod 400 with the preset cookie prevented restarts, as
on the second boot it would fail to write to the cookie. Oops.
2. As far as I can tell, sasl logs were disabled because of the
following error:
{error,{cannot_log_to_tty,sasl_report_tty_h,not_installed}}
Not because we actually wanted to disable them. This meant the
management plugin wasn't usable due to a bug set to be fixed in
3.7.0.
(cherry picked from commit f3b9ac73e2)
Add another option for debugging instead. Lots of users have been
complaining about this default behaviour.
This patch also cleans up the EFI bootloader entries in the ISO.
(cherry picked from commit 3d040f9305)
TeXLive version is effectively identical anyway, and it caused an
unneccessary file name collision.
Fixes: #29671
(cherry picked from commit 8d001911db)
This has been broken nearly all the time due to the patches needed to
iproute2 not being compatible with the newer versions we have been
shipping. As long as Ubuntu does not manage to upstream these changes
so they are maintained with iproute2 and we don't have a maintainer
updating these patches to new iproute2 versions it is not feasible to
have this available.
(cherry picked from commit 08b09fdc5c)
This reverts commit 670b4e29ad. The change
added in this commit was controversial when it was originally suggested
in https://github.com/NixOS/nixpkgs/pull/29205. Then that PR was closed
and a new one opened, https://github.com/NixOS/nixpkgs/pull/29503,
effectively circumventing the review process. I don't agree with this
modification. Adding an option 'resolveLocalQueries' to tell the locally
running name server that it should resolve local DNS queries feels
outright nuts. I agree that the current state is unsatisfactory and that
it should be improved, but this is not the right way.
This option got introduced in 7904499542
and it didn't check whether mailUser and mailGroup are null, which they
are by default.
Now we're only creating the user if createMailUser is set in conjunction
with mailUser and the group if mailGroup is set as well.
I've added a NixOS VM test so that we can verify whether dovecot works
without any additional options set, so it serves as a regression test
for issue #29466 and other issues that might come up with future changes
to the Dovecot service.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Fixes: #29466
Cc: @qknight, @abbradar, @ixmatus, @siddharthist, @peti
(cherry picked from commit 3ba2095a42)
We were using 'Combined Image JSON + Filesystem Changeset Format' [1] to
unpack and pack image and this patch switches to the format used by the registry.
We used the 'repository' file which is not generated by Skopeo when it
pulls an image. Moreover, all information of this file are also in the
manifest.json file.
We then use the manifest.json file instead of 'repository' file. Note
also the manifest.json file is required to push an image with Skopeo.
Fix#29636
[1] 749d90e10f/image/spec/v1.1.md (combined-image-json--filesystem-changeset-format)
(cherry picked from commit 35f205a4b6)
Ensure that modules required by all declared fileSystems are explicitly
loaded. A little ugly but fixes the deferred mount test.
See also https://github.com/NixOS/nixpkgs/issues/29019
(cherry picked from commit 1df6cf5d1d)
Add the `extraGitoliteRc` option to customize the `.gitolite.rc`
configuration file declaratively.
Resolves#29249.
(cherry picked from commit c73a3813fa)
* indentation, retab
* url handling for alternative version names
* handling for alt. download url format
* made unknown channel error non-fatal
(cherry picked from commit 14f2e0cd36)
Boot fails when a keyfile is configured for all encrypted filesystems
and no other luks devices are configured. This is because luks support is only
enabled in the initrd, when boot.initrd.luks.devices has entries. When a
fileystem has a keyfile configured though, it is setup by a custom
command, not by boot.initrd.luks.
This commit adds an internal config flag to enable luks support in the
initrd file, even if there are no luks devices configured.
(cherry picked from commit 2000fba561)
Currently the `rpc-gssd.service` has a `ConditionPathExists` clause that can
never be met, because it's looking for stateful data inside `/nix/store`.
`auth-rpcgss-module.service` also only starts if this file exists.
FixesNixOS/nixpkgs#29509.
(cherry picked from commit 98a2316166)
This includes fuse-common (fusePackages.fuse_3.common) as recommended by
upstream. But while fuse(2) and fuse3 would normally depend on
fuse-common we can't do that in nixpkgs while fuse-common is just
another output from the fuse3 multiple-output derivation (i.e. this
would result in a circular dependency). To avoid building fuse3 twice I
decided it would be best to copy the shared files (i.e. the ones
provided by fuse(2) and fuse3) from fuse-common to fuse (version 2) and
avoid collision warnings by defining priorities. Now it should be
possible to install an arbitrary combination of "fuse", "fuse3", and
"fuse-common" without getting any collision warnings. The end result
should be the same and all changes should be backwards compatible
(assuming that mount.fuse from fuse3 is backwards compatible as stated
by upstream [0] - if not this might break some /etc/fstab definitions
but that should be very unlikely).
My tests with sshfs (version 2 and 3) didn't show any problems.
See #28409 for some additional information.
[0]: https://github.com/libfuse/libfuse/releases/tag/fuse-3.0.0
(cherry picked from commit 351f5fc585)
This pervents the user from accidently commiting the key to the nix store.
If providing a path instead of a string.
(cherry picked from commit 8ed758696c)
The license of CompCert is not a generic "INRIA" license. It is "INRIA Non-Commercial
Agreement for the CompCert verified compiler". As unfortunate as it may seem, this
is a non-free license (clearly mentioned as such in its preamble). See also #20256.
(cherry picked from commit 8fde5790b4)
* First attempt at making elvish compile on darwin
* Fixed cyclic dependency on darwin
This fixes the "cycle detected in the references of" error when building
on darwin. The fix is based on the solution in issue #18131.
* Use version 0.10 and not 0.10.1, which is not officially released yet
(cherry picked from commit 8b8a2fd542)
It actually requires flake8-future-import but manages to download it
from the Internet when run outside the sandbox.
(cherry picked from commit 2c2cd34b54)
We cannot rely on wrapPythonPrograms to wrap the installed executables because
they are symlinks (which it ignores). Instead, we have to emulate it to make
the wrappers ourselves.
(cherry picked from commit 1e2ebee42a)
- Fix finding SDL (would previously fail unless gcc was in environment)
- Use ghostscript rather than xpdf for rendering as it has a slightly
smaller closure
- Fix broken link for reasoning behind name change
- Add self to maintainers
- Add reference to DejaVu fonts so it can always find the OSD fonts
- Install manpage into correct location
(cherry picked from commit 05101d32c0)
The getty@.service unit already has an ExecStart so we cannot simply set a new
one in order to override it or we will get this error:
systemd[1]: getty@tty1.service: Service has more than one ExecStart= setting, which is only allowed for Type=oneshot services. Refusing.
Instead "reset" ExecStart by setting it to empty which is the systemd way of
doing it.
(cherry picked from commit 6558f81bc9)
This depends ultimately on texlive which is a big build and depends on
lots of libraries which often get security updates. This triggers
mass rebuilds because systemd depends on gnutls which depends on
p11_kit.
This was introduced with 93d80f1951.
(cherry picked from commit 0a2c39e205)
properly also in case dhcpcd being used.
Without network-online.target, coturn will fail to listen on addresses that
come up with dhcpcd.
(cherry picked from commit a9f60224f8)
Previously services depending on network-online.target would wait until
dhcpcd times out if it was enabled and a static network address
configuration was used. Setting the default gateway statically is enough
for the networking to be considered online.
This also adjusts the relevant networking tests to wait for
network-online.target instead of just network.target.
(cherry picked from commit b179908414)
By default, awesome will use "devel" as a version name
(or `git describe`). This has led to awesome always
showing "devel" for its version.
Some extensions depend on version information to figure
out what features they can use.
This change overrides the version for the build from the
derivations' `version` attribute.
(cherry picked from commit 824b30a715)
If neither database.password or database.passwordFile were provided,
it would try and fail to coerce null to a string.
This fixes the situation where there is no password for the database.
Resolves#27950
(cherry picked from commit 6460e459de)
This does break the API of being able to import any lib file and get
its libs, however I'm not sure people did this.
I made this while exploring being able to swap out docFn with a stub
in #2305, to avoid functor performance problems. I don't know if that
is going to move forward (or if it is a problem or not,) but after
doing all this work figured I'd put it up anyway :)
Two notable advantages to this approach:
1. when a lib inherits another lib's functions, it doesn't
automatically get put in to the scope of lib
2. when a lib implements a new obscure functions, it doesn't
automatically get put in to the scope of lib
Using the test script (later in this commit) I got the following diff
on the API:
+ diff master fixed-lib
11764a11765,11766
> .types.defaultFunctor
> .types.defaultTypeMerge
11774a11777,11778
> .types.isOptionType
> .types.isType
11781a11786
> .types.mkOptionType
11788a11794
> .types.setType
11795a11802
> .types.types
This means that this commit _adds_ to the API, however I can't find a
way to fix these last remaining discrepancies. At least none are
_removed_.
Test script (run with nix-repl in the PATH):
#!/bin/sh
set -eux
repl() {
suff=${1:-}
echo "(import ./lib)$suff" \
| nix-repl 2>&1
}
attrs_to_check() {
repl "${1:-}" \
| tr ';' $'\n' \
| grep "\.\.\." \
| cut -d' ' -f2 \
| sed -e "s/^/${1:-}./" \
| sort
}
summ() {
repl "${1:-}" \
| tr ' ' $'\n' \
| sort \
| uniq
}
deep_summ() {
suff="${1:-}"
depth="${2:-4}"
depth=$((depth - 1))
summ "$suff"
for attr in $(attrs_to_check "$suff" | grep -v "types.types"); do
if [ $depth -eq 0 ]; then
summ "$attr" | sed -e "s/^/$attr./"
else
deep_summ "$attr" "$depth" | sed -e "s/^/$attr./"
fi
done
}
(
cd nixpkgs
#git add .
#git commit -m "Auto-commit, sorry" || true
git checkout fixed-lib
deep_summ > ../fixed-lib
git checkout master
deep_summ > ../master
)
if diff master fixed-lib; then
echo "SHALLOW MATCH!"
fi
(
cd nixpkgs
git checkout fixed-lib
repl .types
)
(cherry picked from commit 152c63c9ff)
This partially undoes the change from 8788bfe762.
The 'doBenchmark' name is more consistent with the naming scheme used for
other phases, like 'doCheck', 'doHaddock', etc.
(cherry picked from commit 33e34aa95b)
In the maintenance release bump in
90059701a8 a certain change to /test/ was
backported from Python 3:
- bpo-30207: To simplify backports from Python 3, the test.test_support
module was converted into a package and renamed to test.support. The
test.script_helper module was moved into the test.support package.
Names test.test_support and test.script_helper are left as aliases to
test.support and test.support.script_helper.
(cherry picked from commit 96d15eaddb)
The bzero-patch was merged upstream in
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@16103, so it does no
longer apply.
Additionally - to make the build succeed on darwin systems more recent
than our nixpkgs.darwin.xnu kernel version - we need to teach the build
the version of the xnu headers we provide, instead of letting the build
figure out the actual system version using `uname -r`.
(cherry picked from commit c71fd76822)
(cherry picked from commit cab5d25d3081a6d13773264000a308a7e07938b8)
When the user specifies the networking.nameservers setting in the
configuration file, it must take precedence over automatically
derived settings.
The culprit was services.bind that made the resolver set to
127.0.0.1 and ignore the nameserver setting.
This patch adds a flag to services.bind to override the nameserver
to localhost. It defaults to true. Setting this to false prevents the
service.bind and dnsmasq.resolveLocalQueries settings from
overriding the users' settings.
Also, when the user specifies a domain to search, it must be set in
the resolver configuration, even if the user does not specify any
nameservers.
This will get propagated down to other libraries loaded because
everything in nixpkgs references CF based on an rpath entry.
(cherry picked from commit cc1bfbd9a7)
New features since version 3.2.0:
* G'MIC Plugin
* Touch Painting
* Smart Patch Tool
* New Brush Presets
The full release notes can be found at:
https://krita.org/en/release-notes-for-krita-3-2/
Version 3.2.1 contains these fixes:
* Crash on startup if only OpenGL 2.1 is found: if you had to disable
opengl for 3.2.0, you can try to enable it again
* A crash when changing layer types in the gmic-qt plugin
* A bug where gmic-qt could crash on odd-sized images
* A regression where using the text tool would break the brush tool
* The option to use the native platform's file dialogs was restored
* A bug where selecting the line tool would disable the flow slider
* Some issues with the LUT docker were fixed
Upstream release notes for 3.2.1:
https://krita.org/en/item/krita-3-2-1-released/
I've dropped the patch, because it was already from the upstream
development version and thus is also included in this release.
Built and tested using a few images and just playing around with a few
new features.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Cc: @abbradar, @Mic92, @kragniz
(cherry picked from commit 8180085733)
the systemd.unit(5) discussion of wantedBy and requiredBy is in the
[Install] section, and thus focused on stateful 'systemctl enable'.
so, clarify that in NixOS, wantedBy & requiredBy are still what most
users want, and not to be confused with enabled.
(cherry picked from commit cfbac1beb4)
remove sqlite-amalgamation and put it internal to the zandronum folder,
as it is only used by zandronum. Patches needed to avoid build impurities
and to get the correct protocol version to connect to public servers.
remove zandronum_bin as it is no longer needed
(cherry picked from commit 990ea8789d)
Remove an obsolete patch
Add lassulus to maintainers
Supply the build with the correct version number and changelog
(cherry picked from commit f4dfa30d24)
This avoids running out of space in space-constrained environments,
e.g. VMs with relatively small amounts of memory and tmp on tmpfs
(cherry picked from commit 77ce02201e)
- Update to version 3.24-2, released on 2017 Aug 3
- Remove versions for GNOME 3.22 and 3.20. The version for 3.24 should
work with them as well.
(cherry picked from commit 6319210b8a)
Update physlock to a more current version which supports PAM and
systemd-logind. Amongst others, this should work now with the slim
login manager without any additional configuration, because it does
not rely on the utmp mechanism anymore.
(cherry picked from commit ae87a30a83)
* prometheus-collectd-exporter service: init module
Supports JSON and binary (optional) protocol
of collectd.
* nixos/prometheus-collectd-exporter: submodule is not needed for collectdBinary
(cherry picked from commit 334e23d244)
There are currently two ways to build Openstack image. This just picks
best of both, to keep only one!
- Image is resizable
- Cloudinit is enable
- Password authentication is disable by default
- Use the same layer than other image builders (ec2, gce...)
(cherry picked from commit 3a377e26b2)
The section was strange to read, as the initial example already used
`listOf' which is mentioned in the very first paragraph. Then you read
in a subsection about `listOf' and the exact same example is given
once again.
(cherry picked from commit 4d101993bf)
tinc prior to 1.1 doesn't have the `tinc` executable,
and `tincd` isn't of any use while the daemon already runs.
(cherry picked from commit 8cea87c1eb)
In c0cf19608f the function
`aspellWithDicts` was introduced, that allows to build a derivation
consisting of aspell and specified dictionaries. In
96457d26dd a fix was included to properly
find the dictionaries.
Issue #29429 describes that, while the current method works for the
aspell binary, it does not in case of the API.
This commit rewrites the wrapper into a single derivation, create a
single tree of symbolic references to both the binary and the
dictionaries so that its possible to find the dictionaries with the API.
Furthermore, the binary is wrapped so it can still find the dictionaries
as well.
(cherry picked from commit 91f7042aa0)
Before this patch, a VM was used to spawn docker that pulled the
VM. Now, the tool Skopeo does this job well so we can simplify our
dockerTools since we doesn't need Docker anymore:)
This also fixe the regression described in
https://github.com/NixOS/nixpkgs/issues/29271 : cntlm proxy doesn't
work in 17.09 while it worked in 17.03.
Note Skopeo doesn't produce the same output than docker pull so, we
have to update sha.
(cherry picked from commit 01174c5f4d)
Signed-off-by: Domen Kožar <domen@dev.si>
The patch was removed during chromium update.
It won't build, but the error seems the same as before chromium update...
(cherry picked from commit 9a55f74e43)
For various reasons, big Nix attrsets look ugly in the generated manual
page[1]. Use literalExample to fix it.
[1] Quotes around attribute names are lost, newlines inside multi-line
strings are shown as '\n' and attrs written on multiple lines are joined
into one.
(cherry picked from commit 6b7a9376f1)
The command `oc cluster up` mainly runs code though Docker containers.
However, in pkg/bootstrap/docker/host/host.go, nsenter is used to run
some commands on the host. For this to work on NixOS, we need to provide
the absolute path to the required programs.
(cherry picked from commit a3dde7776b)
- Updated from 1.5.0 to 3.6.0 (this is just the next version, but Red
Hat did quite the version bump there)
- Added 'v' to the version; it is used by `oc cluster up` to determine
which image should be downloaded.
- Added myself as a maintainer.
(cherry picked from commit f8a72662cf)
`qtkeyring` can use `gnome-keyring`, but it needs some help to find it.
I have not enabled this by default because not everyone who uses this will want
to pull in GNOME dependencies.
(cherry picked from commit e828dcb5cd)
This is used to platform specific library and exectuable extensions. In
the next commit I'll replace a bunch of ad-hoc logic with it.
(cherry picked from commit 741839a687)
Commit 8537cf0f81
("CONTRIBUTING.md: suggest "nixos/<module>" prefix for NixOS changes")
only changed CONTRIBUTING.md file and forgot about the Nixpkgs manual.
(I didn't know this information was stored in two places.)
(cherry picked from commit 56a047c7a1)
To wait for the docker deamon, curl requests are sent. However, if a
http proxy is set, it will respond instead of the docker daemon.
To avoid this, we send docker ps command instead of curl command.
(cherry picked from commit 132e790735)
ftfy package was added for spaCy and is only used by spaCy.
This change downgrades its version to meet the bounds specified by
spaCy (>=4.4.2,<5.0.0).
Relevant to #28643.
(cherry picked from commit 566f5e9e8d)
It's broken on all versions of Python (I've tried 2.7, 3.4, 3.5, 3.6)
I think the root cause is that PyBrain is not working with numpy >= 1.12.0 as I reported here:
https://github.com/pybrain/pybrain/issues/217
(The relevant release notes may be found here):
https://docs.scipy.org/doc/numpy-1.12.0/release.html#compatibility-notes
The PyBrain github repo does not seem very active (last commit 18 months ago, last release 3 years),
so I have some doubts as to whether this will be fixed any time soon.
I suppose an alternative solution could be to reintroduce the explicit dependency to numpy 1.11. But,
this is not entirely trivial: in c9b4a2f319, the versions 1.10, 1.11, 1.12 were folded into a single version.
Also, the numpy dependency is not a direct one, but is implied via scipy
(cherry picked from commit 50d36558a4)
Continuation of #28053
gnome-disk-image-mounter from gnome-disk-utility was not wrapped, resulting in an
error due to the inability to find gsettings schemas.
This commit replaces the manual wrapping of gnome-disks binary with wrapGAppsHook
so that all binaries are wrapped correctly.
(cherry picked from commit b64f149ea9)
https://lists.gnu.org/archive/html/emacs-devel/2017-09/msg00211.html
> This is an emergency release to fix a security vulnerability in Emacs.
>
> Enriched Text mode has its support for decoding 'x-display' disabled.
> This feature allows saving 'display' properties as part of text.
> Emacs 'display' properties support evaluation of arbitrary Lisp forms
> as part of instantiating the property, so decoding 'x-display' is
> vulnerable to executing arbitrary malicious Lisp code included in the
> text (e.g., sent as part of an email message).
(cherry picked from commit 78f457c76c)
The backslash wasn't properly escaped, and "\." is apparently equal to
".". So it's accidentally filtering out these valid file names (in
Nixpkgs):
trace: excluding clfswm
trace: excluding larswm
trace: excluding mkpasswd
While at it, turn the file filter stricter to what it was before
e2589b3ca2. That is, the file name must
start with a dot: '.swp', '.foo.swo' are filtered but 'bar.swf' is not.
(cherry picked from commit 9275c3387e)
Google publishes prebuilt tensorflow whl for python 3.4, 3.5, 3.6,
but nix expression for tensorflow only supported 3.5.
This change adds support for python-3.6.
- avr-gcc 5.3.0 -> 5.4.0
closes#28220
Since the packages do not share a common prefix anymore, you need
to define the current store paths in your project's Makefile.
Example for an atmega644 build:
CFLAGS += -I /nix/store/9rffxzds5crcpm76g3nr03jx0aa657cf-avr-libc-2.0.0/avr/include
CFLAGS += -B /nix/store/9rffxzds5crcpm76g3nr03jx0aa657cf-avr-libc-2.0.0/avr/lib/avr5
CFLAGS += -L /nix/store/9rffxzds5crcpm76g3nr03jx0aa657cf-avr-libc-2.0.0/avr/lib/avr5
CFLAGS += -L /nix/store/8409dj9js4i5901i63275wxdm783l0p6-avr-gcc-5.4.0/lib/gcc/avr/5.4.0/avr5
(cherry picked from commit 6a458c169b)
It doesn't look good when the initial admin user is named
"<hash>-gitolite-admin" and the key stored as
"<hash>-gitolite-admin.pub". Instead, make it simply "gitolite-admin"
and "gitolite-admin.pub".
(cherry picked from commit 6b9ee30672)
This updates namecoin from a legacy version from about 3 years ago
(https://github.com/namecoin/namecoin-legacy) to
the new namecoin-core.
(cherry picked from commit 8bd3664f373cb78a0526dc8a86e750f55b96420a)
(cherry picked from commit 31f349dbb4)
Use consistent no-space style. (All documentation I've seen use no
space, and the generated section headings from the NixOS module also use
no space.)
(cherry picked from commit fc02a0265a)
This is the latest release from Cadsoft, before they were bought by
Autocad. Autocad has released 8.x, but
- it requires reworking the Nix expression (different packaging)
- the paid license version requires a monthly subscription fee, you never
"own" the software (AFAICT).
Due to the licensing change in 8.x, I think keeping Eagle 7.x around is
a good idea.
(cherry picked from commit 28f780b320)
https://hydra.nixos.org/build/59943791
This package is a library and has no reverse dependencies. (It was once
used by diffoscope, but it changed to use a different library).
(cherry picked from commit 373b2231be)
This is set in the hardened linux config as well but sysctl is more
flexible & works with any boot.kernelPackages
(cherry picked from commit 2bce0b13e7)
These changes reduce file accesses outside TBB_HOME or the Nix store, as
determined by running under strace -e access,open,stat.
(cherry picked from commit f84125c3b1)
Aften is an audio encoder which generates compressed audio streams based on
ATSC A/52 specification. This type of audio is also known as AC-3 or Dolby®
Digital and is one of the audio codecs used in DVD-Video content.
Homepage: http://aften.sourceforge.net/
(cherry picked from commit 6e009edc41)
* tigervnc: correct default ssh client path
The -via command sets up an ssh tunnel, but is hardcoded to /usr/bin/ssh
upstream. This patches it to use the nixpkgs openssh client.
* tigervnc: patch ssh path correctly
(cherry picked from commit e9183fd2d4)
This fixes:
Traceback (most recent call last):
File "/nix/store/7f9arl3f9xyj8sm05mkanh2mlp217192-glusterfs-3.10.2/libexec/glusterfs/glusterfind/changelog.py", line 22, in <module>
import libgfchangelog
File "/nix/store/7f9arl3f9xyj8sm05mkanh2mlp217192-glusterfs-3.10.2/libexec/glusterfs/glusterfind/libgfchangelog.py", line 21, in <module>
libgfc = CDLL("libgfchangelog.so", use_errno=True, mode=RTLD_GLOBAL)
File "/nix/store/nlyr5ankhi7yvva8zndi718zj37js270-python-2.7.13-env/lib/python2.7/ctypes/__init__.py", line 362, in __init__
self._handle = _dlopen(self._name, mode)
OSError: libgfchangelog.so: cannot open shared object file: No such file or directory
Connection to 10.0.0.2 closed.
when running `glusterfind pre`.
Done by setting PYTHONPATH/LD_LIBRARY_PATH as for the other
Python scripts.
(cherry picked from commit abc96aae47)
Fixes error
File "/nix/store/lxpsl84km87xpk59nai6a33ihgpfs7qr-glusterfs-3.10.2/libexec/glusterfs/glusterfind/changelog.py", line 105, in populate_pgfid_and_inodegfid
file_xattrs = xattr.list(p)
AttributeError: 'module' object has no attribute 'list'
when using `glusterfind pre`.
(cherry picked from commit 8e329da496)
It seems that the recaptcha-client package is no longer maintained.
* The latest released version (1.0.6) is from the year 2011;
* The project page does not mention which Python versions are supported
* The project is hosted on google code, which is discontinued
I was able to succesfully build with Python versions 3.3, 3.4, but not
3.5, 3.6.
This is probably a fallout from #28557 merge and revert.
I can't see why exactly this happened, but it seems a safe fix.
(cherry picked from commit c86eb1da5f)
Fixes a number of CVEs:
- a DNS request hijacking vulnerability. (CVE-2017-0902)
- an ANSI escape sequence vulnerability. (CVE-2017-0899)
- a DoS vulnerability in the query command. (CVE-2017-0900)
- a vulnerability in the gem installer that allowed a malicious gem to overwrite arbitrary files. (CVE-2017-0901)
(cherry picked from commit 9f51b3c105)
Otherwise if you try to listing all available packages, you will get a
hard error on platforms not supported by this package. Consequently the
tarball job was broken.
(cherry picked from commit f9ea527a02)
Add pkgconfig as buildinput, so that the install path is correctly set
with cmake. PkgConfig is an optional dependency for rtags, but they
say it's necessary if you want to replace the prefix with
CMAKE_INSTALL_PREFIX. See:
caad9ac494/cmake/BashCompletion.cmake (L13)
Furthermore, I let the configurePhase of the rtags emacs package be a
noop.
(cherry picked from commit 311a1ee33a)
The build was failing with gcc 6.4.0; using the samee gcc6 patch Arch
Linux uses fixed the build.
This commit also refactors out the builder.sh possibly fixing the
NOGUI make flag option.
(cherry picked from commit 8b0de80e55)
Set LD=$CC to fix this build error:
...
ExtUtils::Mkbootstrap::Mkbootstrap('blib/arch/auto/Boost/Geometry/Utils/Utils.bs')
ld -shared -O2 -L/nix/store/sgjc1147vi5hd57ck9xgck5xjkydg5lz-glibc-2.25/lib -fstack-protector-strong -o blib/arch/auto/Boost/Geometry/Utils/Utils.so buildtmp/Utils.o -lstdc++
buildtmp/Utils.o: In function `_GLOBAL__sub_I_Utils.c':
Utils.c:(.text.startup+0x1a): undefined reference to `__dso_handle'
/nix/store/yf4p5w2v4h4i8rja9zw1akp007av624j-binutils-2.28.1/bin/ld: buildtmp/Utils.o: relocation R_X86_64_PC32 against undefined hidden symbol `__dso_handle' can not be used when making a shared object
/nix/store/yf4p5w2v4h4i8rja9zw1akp007av624j-binutils-2.28.1/bin/ld: final link failed: Bad value
error building blib/arch/auto/Boost/Geometry/Utils/Utils.so from buildtmp/Utils.o at /nix/store/7q2hps69zkj501lsmvnd2ry95mmdbh80-perl-5.24.2/lib/perl5/5.24.2/ExtUtils/CBuilder/Base.pm line 321.
builder for ‘/nix/store/bdwqvgxlgcqsmlqfh0d74jkpw96p78kh-perl-Boost-Geometry-Utils-0.15.drv’ failed with exit code 2
error: build of ‘/nix/store/bdwqvgxlgcqsmlqfh0d74jkpw96p78kh-perl-Boost-Geometry-Utils-0.15.drv’ failed
(cherry picked from commit c24820db93)
I realize that advanced users like to configure services with Nix
attrsets, but I don't think we should remove the option to use the
(configuration) language provided by upstream.
(cherry picked from commit eed14baec3)
This is a security release theoretically under emgargo, but leaked by
Mageia and Fedora.
We have permission to deliver this prior to public release.
(cherry picked from commit 993a83d395)
This reverts commit 0a944b345e, reversing
changes made to 61733ed6cc.
I dislike these massive stdenv changes with unclear motivation,
especially when they involve gratuitous mass renames like NIX_CC ->
NIX_BINUTILS. The previous such rename (NIX_GCC -> NIX_CC) caused
months of pain, so let's not do that again.
(cherry picked from commit ec8d41f08c)
cctool's as needs to be told use to use gnu as, or else we'd need a
dependency cycle between cctools and clang for this case.
In general, this is not a problem because clang uses its own integrated
assembler where possible, and gnu as otherwise.
(cherry picked from commit eb326c9cb7)
When keys get refreshed a folder with the permissions of the root user
get created in the home directory of the user dnscrypt-wrapper. This
prevents the service from restarting.
In addition to that the parameters of dnscrypt-wrapper have
changed in upstream and in the newly packaged software.
(cherry picked from commit ca54a86162)
@dezgeg caught my error--the issue isn't building help2man, but running
it on cross-compiled binaries.
This effectively reverts 0825f30fd2 as
far as behavior is concerned, but keeps the removal of `crossAttrs`.
(cherry picked from commit 28e4975bd1)
One of the goals of 74f5fe5 was to allow passing in a custom stdenv,
which would be used for genericBuilder's `mkDerivation` call. That does
work, but if packages takes `stdenv` as an parameter for any reason,
they'll get the default one instead. This change remedies it.
(cherry picked from commit 19de1f537e)
Add openssh as dependency for sftp-server. When connecting, x2goclient
crashes if it can't find that executable.
(cherry picked from commit a8aef188c8)
There is no maintainer for this package, probably not many users.
It requires effort to fix all third-party modules for this old kernel
versions. It might contain unpatched security holes.
For Pixel chromebooks, we have the samus-kernel.
Apart from that https://github.com/GalliumOS/linux might be a good choice.
(cherry picked from commit 44f93731d6)
This change statically links the `dhall-*` family of executables so that
they start up more quickly on NixOS. This also updates the `dhallToNix`
utility to use the statically linked `dhall-to-nix` executable
(cherry picked from commit fd2c8d0a00)
The main thing is that I'm convinced the license can't be free when it
restricts redistribution to certain platforms. That probably holds with
the usual definitions like from Debian, FSF or OSI.
(cherry picked from commit 8414d8386b)
Upstream bug fixes:
* pen and touchscreen input handling bugfixes
* fix a minor bug with save file paths in Windows (D. German)
* use GDK macros (not WIN32) to disable X11-specific code (T.
Schoonjans)
* export to PDF and printing: fix resolution loss on some pdf
backgrounds
* disable xinput during modal dialog boxes
* avoid data corruption when exporting to overwrite a PDF
* fix path search order for toolbar bitmaps
* text and image tools activate on button release instead of button
press to avoid subsequent confusion between clicks in toolbar and
drawing area
* fix "pen disable touch" when touchscreen sends prox events (A.
Kittenberger)
* fix crash when pasting text or images via xclip
* updated Italian translation (Marco Ciampa)
New upstream features:
* add space and shift-space bindings to page down/up (D. German)
* add A5 paper (D. German)
* config option to export successive layers to separate PDF pages
* config option to create new file when trying to open non-existent
.xoj
The full change log along with bug numbers can be found at:
https://sourceforge.net/p/xournal/code/ci/Release-0_4_8_2016/tree/ChangeLog
I've dropped gdk-quartz-backend.patch, because I believe it has been
fixed upstream.
Here are the upstream changes relevant for the patch (shortened, because
SourceForge has really long URLs):
http://bit.ly/2vXW8n0 -> src/Makefile.am
http://bit.ly/2gDnjl7 -> src/xo-file.c
http://bit.ly/2xJ5K7A -> src/xo-misc.c
Tested building and using the application.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Cc: @7c6f434c, @dguibert
Cc: @johbo who has introduced the patch in #21842
(cherry picked from commit 8436e9bfcd)
In Nix 1.12 sandboxed builds are performed in /build/ directory which conflicts
with the regex in docs/CMakeLists.txt, and generated documentation ends up in
wrong directory -> https://hydra.nixos.org/build/53914969/nixlog/1 -> CTRL-F
abi.txt
(cherry picked from commit e22a77217d)
See PR #28960 for details about the problem. There is some
non-determinism surrounding copies of the Speedy/Speedy11 font, so
deleting one makes it deterministic again without losing anything.
(cherry picked from commit 7d231c5435)
Did this when spliting off binutils-wrapper from cc-wrapper in
40e9b2a7e6: I deleted the file instead of
moving it.
(cherry picked from commit 3601a97e3c)
Factor a binutils wrapper out of cc-wrapper. While only LD is wrapped,
the setup hook defines environment variables on behalf of other
utilites.
(cherry picked from commit 40e9b2a7e6)
Environment variable filter in substituteAll was not precise and produced
undefined and invalid variable names. Vladimír Čunát tried to fix that in [1],
but `env -0` did not work during Darwin bootstrap, so [2] reverted this change
and replaced an error due to invalid variables with a warning. Recently in #28057
John Ericson added `set -u` to `setup.sh` and undefined variables made the setup
fail during e.g. `nix-build -A gnat` with `setup: line 519: !varName: unbound
variable`.
[1] 62fc8859c1
[2] 81df035429
(cherry picked from commit a09d9e7cd4)
This becomes necessary if more wrappers besides cc-wrapper start
supporting hardening flags. Also good to make the warning into an
error.
Also ensure interface is being used right: Not as a string, not just in
bash.
(cherry picked from commit 97a48835b7)
GCC just passes `-z ...` flags to ld unaltered, and they are already
passed to LD anyways. On the other hand, `-pie` affects gcc behavior
too.
(cherry picked from commit 822a8d0148)
I missed this in 799435b7ca.
This time I used "git grep -F pythonPackages.deluge" just to be sure :-)
Thanks a lot to @roconnor for spotting this.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Reported-by: @roconnor
(cherry picked from commit 880a0409e8)
These have been throwing exceptions since grsec was deprecated, so
potential users should have had due to time to migrate their configs.
(cherry picked from commit 5125e209a9)
Potential disadvantage: ghostscript will become visible to user,
so there may e.g. be (new) collisions in nix-env due to this.
Fixes#28411.
(cherry picked from commit 828bc3812c)
It's now the default. /cc #19456
This makes a real build simplification, because in our current
bootstrapping+aliases, `gcc6` attribute is not the default compiler
but a derivation *built by* the default compiler.
nix-exec didn't build before this commit already
(cherry picked from commit 53998f5036)
Grub configs include the NixOS version and date they were built, now
systemd can have fun too:
version Generation 99 NixOS 17.03.1700.51a83266d1, Linux Kernel 4.9.43, Built on 2017-08-30
version Generation 100 NixOS 17.03.1700.51a83266d1, Linux Kernel 4.9.43, Built on 2017-08-30
version Generation 101 NixOS 17.03.1700.51a83266d1, Linux Kernel 4.9.43, Built on 2017-08-31
version Generation 102 NixOS 17.03.1700.51a83266d1, Linux Kernel 4.9.43, Built on 2017-09-01
version Generation 103 NixOS 17.03.1700.51a83266d1, Linux Kernel 4.9.43, Built on 2017-09-02
version Generation 104 NixOS 17.09beta41.1b8c7786ee, Linux Kernel 4.9.46, Built on 2017-09-02
version Generation 105 NixOS 17.09.git.1b8c778, Linux Kernel 4.9.46, Built on 2017-09-02
(cherry picked from commit 62652be111)
pyrtlsdr needs pandoc at build time. Fixes the build since commit
f6eb190e70
("python.pkgs.pyrtlsdr: disable tests to fix build"). (That commit
bumped the package to a new version.)
(cherry picked from commit 2cf1b94b82)
Z3 has supported optimization features since the 4.4.x release, so this can be
removed.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
(cherry picked from commit 54ae0aa1b0)
Upstream changes:
* Tesseract 4.00.00alpha:
* Version parsing: Ignore suffix (so '4.00.00alpha' == (4, 0, 0))
* Libtesseract: Load libtesseract.so.4 instead of libtesseract.so.3
if available
* Support for Tesseract 3.05.00:
* Builders: Split field 'tess_conf' into 'tess_flags' and 'tess_conf'
* Libtesseract: If available, use
TessBaseAPIDetectOrientationScript() instead of
TessBaseAPIDetectOS
* Libtesseract:
* Workaround: Prevents possible segfault in image_to_string() when
the target language is not available
Full upstream change log can be found at:
https://github.com/openpaperwork/pyocr/blob/b006123d1d002711b9/ChangeLog
The tesseract.patch for supporting Tesseract version 3.05.00 has been
applied upstream and we can safely drop it.
We now use substituteInPlace in conjunction with a patch to insert the
relevant store paths instead of sed, so it's less fragile whenever we
have upstream changes in handling of these paths.
I've tested this by reverting 48a941e29f and applying a build
fix patch of Cuneiform 1.1.0 from Arch Linux, because right now
Cuneiform is an experimental version that can't be fixed on behalf of
pyocr (the reason is that pyocr needs to get a list of languages, which
doesn't work in that version anymore).
In addition to that I've successfully built paperwork-backend which by
now is the one package which depends on pyocr. However, I didn't do
runtime tests of Paperwork.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Cc: @7c6f434c
(cherry picked from commit ca1ea69972)
We already have a patch feeling lonely inside the python-modules
directory and to have everything at one place let's actually move pyocr
into its own dedicated directory so it's easier to patch it up (which
we're going to).
Right now, the package fails to build because of a few test failures, so
I haven't tested this apart from evaluating.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
(cherry picked from commit 3086fc7f83)
In order to run the tests for the external plugins of beets, we need to
have beets itself as a dependency. So in order to do that, we now pass
beets without plugins and tests to the nativeBuildInputs of the plugins
so that we can run them.
As soon as the plugins are built they become part of the final beets,
which also has tests enabled, so disabling the tests for beets
derivation that is used for external plugin tests is a non-issue here
because they're going to be executed anyway.
Enabling tests for the alternatives plugin is pretty straightforward,
but in order to run tests for the copyartifacts plugin, we need to bump
the source code to the latest Git master.
The reason for this is that the version that was in use until now
required to have the beets source directory alongside of the
copyartifacts source code, but we already have beets available as a
normal dependency.
Updating copyartifacts to latest master largely consists of unit test
changes and a few Python 3 compatibility changes. However, one change
has the biggest stat, which is
sbarakat/beets-copyartifacts@1a0c281da0.
Fortunately, the last change is just moving the implementation to a
newer API from upstream beets and by the looks of the implementation it
seems to break support for moving files. However, reverting this commit
also reveals that moving files was already broken before, so it wouldn't
matter much whether we have this version bump or not.
Tested with the following command:
nix-build -E '(import ./. {}).beets.override {
enableAlternatives = true;
enableCopyArtifacts = true;
}'
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Cc: @domenkozar, @pjones, @Profpatsch, @michalrus
(cherry picked from commit 40b76c8809)
Regression introduced by 94351197cd.
Running the tests results in the following traceback:
...
File ".../unittest/loader.py", line 91, in loadTestsFromName
module = __import__('.'.join(parts_copy))
File ".../test/regrtest.py", line 184, in <module>
for module in sys.modules.itervalues():
RuntimeError: dictionary changed size during iteration
The reason for this is that the test directory itself is called "test"
and the package including regrtest.py is also called "test", so the
loader tries to load tests from its own implementation.
We could fix this by changing PYTHONPATH and/or making the test
directory a proper package, but we'd still have failing tests because
beets itself is required to run the tests.
However for now I'm just removing the unit_tests kwarg in setup.py so
that we have the same behaviour as before the initially mentioned
commit.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
(cherry picked from commit bd2aeb4883)
- Update to version 2.0.10
- Use wrapGAppsHook to wrap binaries
- Use gstreamer-1.0
- Add dependence on libappindicator
(cherry picked from commit 1f48ad8699)
Regression introduced by fa5e343242.
The deluge package no longer resides in pythonPackages but now is a
top-level package.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Cc: @grantwwu, @fpletz
(cherry picked from commit 799435b7ca)
This has been introduced in 6a6fb6d31c.
Relying on non-free software by default is probably a bad idea. Apart
from the fact that (sane) people usually don't want to have it sitting
on their system even people who don't care will have to set
"allowUnfree" to true in order to install conky.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Cc: @canndrew, @Mic92
(cherry picked from commit 7f99876f50)
previous mkDefault did not work as expected,
as it did not overwrite the original submodule's defaults when the user
did not specify any custom options at all.
(cherry picked from commit 786e9711f5)
GMime home has moved to Github as the list of commits clearly shows,
i.e.:
b5cbc68a67
The description is updated as well to be closer to the one used there
and over at gnome.org.
(cherry picked from commit ddaa696a4e)
The newer DEB packages have a setuid file, creating an error when
unpacking the source during the build phase.
As dpkg doesn't have a way to pass parameters to tar, dpkg is then
told to just extract the filesystem tar file and that is unpacked by
tar directly.
Fixes#28494
(cherry picked from commit fae458c5e7)
@@ -12,11 +12,11 @@ under the terms of [COPYING](../COPYING), which is an MIT-like license.
## Submitting changes
* Format the commit messages in the following way:
* Format the commits in the following way:
```
(pkg-name | nixos/<module>): (from -> to | init at version | refactor | etc)
(Motivation for change. Additional information.)
```
@@ -25,21 +25,18 @@ under the terms of [COPYING](../COPYING), which is an MIT-like license.
* nginx: init at 2.0.1
* firefox: 54.0.1 -> 55.0
* nixos/hydra: add bazBaz option
Dual baz behavior is needed to do foo.
* nixos/nginx: refactor config generation
The old config generation system used impure shell scripts and could break in specific circumstances (see #1234).
* `meta.description` should:
* Be capitalized.
* Not start with the package name.
* Not have a period at the end.
* `meta.license` must be set and fit the upstream license.
* If there is no upstream license, `meta.license` should default to `stdenv.lib.licenses.unfree`.
* `meta.maintainers` must be set.
* Be capitalized
* Not start with the package name
* Not have a dot at the end
See the nixpkgs manual for more details on [standard meta-attributes](https://nixos.org/nixpkgs/manual/#sec-standard-meta-attributes) and on how to [submit changes to nixpkgs](https://nixos.org/nixpkgs/manual/#chap-submitting-changes).
See the nixpkgs manual for more details on how to [Submit changes to nixpkgs](https://nixos.org/nixpkgs/manual/#chap-submitting-changes).
- [ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside [nixos/tests](https://github.com/NixOS/nixpkgs/blob/master/nixos/tests))
- [ ] Tested compilation of all pkgs that depend on this change using `nix-shell -p nox --run "nox-review wip"`
- [ ] Tested execution of all binary files (usually in `./result/bin/`)
* [Nix Wiki](https://nixos.org/wiki/) (deprecated, see milestone ["Move the Wiki!"](https://github.com/NixOS/nixpkgs/issues?q=is%3Aopen+is%3Aissue+milestone%3A%22Move+the+wiki%21%22))
* [Continuous package builds for unstable/master](https://hydra.nixos.org/jobset/nixos/trunk-combined)
* [Continuous package builds for 17.09 release](https://hydra.nixos.org/jobset/nixos/release-17.09)
* [Continuous package builds for 17.03 release](https://hydra.nixos.org/jobset/nixos/release-17.03)
* [Tests for unstable/master](https://hydra.nixos.org/job/nixos/trunk-combined/tested#tabs-constituents)
* [Tests for 17.09 release](https://hydra.nixos.org/job/nixos/release-17.09/tested#tabs-constituents)
* [Tests for 17.03 release](https://hydra.nixos.org/job/nixos/release-17.03/tested#tabs-constituents)
For example, a typical use of cross compilation is to compile programs for embedded devices.
These devices often don't have the computing power and memory to compile their own programs.
One might think that cross-compilation is a fairly niche concern, but there are advantages to being rigorous about distinguishing build-time vs run-time environments even when one is developing and deploying on the same machine.
Nixpkgs is increasingly adopting the opinion that packages should be written with cross-compilation in mind, and nixpkgs should evaluate in a similar way (by minimizing cross-compilation-specific special cases) whether or not one is cross-compiling.
Nixpkgs is increasingly adopting this opinion in that packages should be written with cross-compilation in mind, and nixpkgs should evaluate in a similar way (by minimizing cross-compilation-specific special cases) whether or not one is cross-compiling.
</para>
<para>
@@ -30,11 +30,11 @@
<section>
<title>Platform parameters</title>
<para>
Nixpkgs follows the <linkxlink:href="https://gcc.gnu.org/onlinedocs/gccint/Configure-Terms.html">common historical convention of GNU autoconf</link> of distinguishing between 3 types of platform:<wordasword>build</wordasword>, <wordasword>host</wordasword>, and <wordasword>target</wordasword>.
In summary, <wordasword>build</wordasword> is the platform on which a package is being built, <wordasword>host</wordasword> is the platform on which it is to run. The third attribute, <wordasword>target</wordasword>, is relevant only for certain specific compilers and build tools.
The three GNU Autoconf platforms,<wordasword>build</wordasword>, <wordasword>host</wordasword>, and <wordasword>target</wordasword>, are historically the result of much confusion.
<linkxlink:href="https://gcc.gnu.org/onlinedocs/gccint/Configure-Terms.html"/> clears this up somewhat but there is more to be said.
An important advice to get out the way is, unless you are packaging a compiler or other build tool, just worry about the build and host platforms.
Dealing with just two platforms usually better matches people's preconceptions, and in this case is completely correct.
</para>
<para>
In Nixpkgs, these three platforms are defined as attribute sets under the names <literal>buildPlatform</literal>, <literal>hostPlatform</literal>, and <literal>targetPlatform</literal>.
All three are always defined as attributes in the standard environment, and at the top level. That means one can get at them just like a dependency in a function that is imported with <literal>callPackage</literal>:
@@ -52,7 +52,7 @@
<varlistentry>
<term><varname>hostPlatform</varname></term>
<listitem><para>
The "host platform" is the platform on which a package will be run.
The "host platform" is the platform on which a package is run.
This is the simplest platform to understand, but also the one with the worst name.
</para></listitem>
</varlistentry>
@@ -60,24 +60,22 @@
<term><varname>targetPlatform</varname></term>
<listitem>
<para>
The "target platform" attribute is, unlike the other two attributes, not actually fundamental to the process of building software.
Instead, it is only relevant for compatibility with building certain specific compilers and build tools.
It can be safely ignored for all other packages.
The "target platform" is black sheep.
The other two intrinsically apply to all compiled software—or any build process with a notion of "build-time" followed by "run-time".
The target platform only applies to programming tools, and even then only is a good for for some of them.
Briefly, GCC, Binutils, GHC, and certain other tools are written in such a way such that a single build can only compile code for a single platform.
Thus, when building them, one must think ahead about which platforms they wish to use the tool to produce machine code for, and build binaries for each.
</para>
<para>
The build process of certain compilers is written in such a way that the compiler resulting from a single build can itself only produce binaries for a single platform.
The task specifying this single "target platform" is thus pushed to build time of the compiler.
The root cause of this mistake is often that the compiler (which will be run on the host) and the the standard library/runtime (which will be run on the target) are built by a single build process.
There is no fundamental need to think about the target ahead of time like this.
LLVM, for example, was designed from the beginning with cross-compilation in mind, and so a normal LLVM binary will support every architecture that LLVM supports.
If the tool supports modular or pluggable backends, one might imagine specifying a <emphasis>set</emphasis> of target platforms / backends one wishes to support, rather than a single one.
</para>
<para>
There is no fundamental need to think about a single target ahead of time like this.
If the tool supports modular or pluggable backends, both the need to specify the target at build time and the constraint of having only a single target disappear.
An example of such a tool is LLVM.
</para>
<para>
Although the existance of a "target platfom" is arguably a historical mistake, it is a common one: examples of tools that suffer from it are GCC, Binutils, GHC and Autoconf.
Nixpkgs tries to avoid sharing in the mistake where possible.
Still, because the concept of a target platform is so ingrained, it is best to support it as is.
The biggest reason for mess, if there is one, is that many compilers have the bad habit a build process that builds the compiler and standard library/runtime together.
Then the specifying target platform is essential, because it determines the host platform of the standard library/runtime.
Nixpkgs tries to avoid this where possible too, but still, because the concept of a target platform is so ingrained now in Autoconf and other tools, it is best to support it as is.
Tools like LLVM that don't need up-front target platforms can safely ignore it like normal packages, and it will do no harm.
</para>
</listitem>
</varlistentry>
@@ -157,22 +155,14 @@
<section>
<title>Specifying Dependencies</title>
<para>
In this section we explore the relationship between both runtime and buildtime dependencies and the 3 Autoconf platforms.
</para>
<para>
A runtime dependency between 2 packages implies that between them both the host and target platforms match.
This is directly implied by the meaning of "host platform" and "runtime dependency":
The package dependency exists while both packages are running on a single host platform.
</para>
<para>
A build time dependency, however, implies a shift in platforms between the depending package and the depended-on package.
The meaning of a build time dependency is that to build the depending package we need to be able to run the depended-on's package.
The depending package's build platform is therefore equal to the depended-on package's host platform.
Analogously, the depending package's host platform is equal to the depended-on package's target platform.
</para>
<para>
In this manner, given the 3 platforms for one package, we can determine the three platforms for all its transitive dependencies.
As mentioned in the introduction to this chapter, one can think about a buildtime vs run time distinction whether cross-compiling or not.
In the case of cross-compilation, this corresponds with whether a derivation running on the native or foreign platform is produced.
An interesting thing to think about is how this corresponds with the three Autoconf platforms.
In the run-time case, the depending and depended-on package simply have matching build, host, and target platforms.
But in the build-time case, one can imagine "sliding" the platforms one over.
The depended-on package's host and target platforms (respectively) become the depending package's build and host platforms.
This is the most important guiding principle behind cross-compilation with Nixpkgs, and will be called the <wordasword>sliding window principle</wordasword>.
In this manner, given the 3 platforms for one package, we can determine the three platforms for all its transitive dependencies.
</para>
<para>
Some examples will probably make this clearer.
@@ -187,58 +177,19 @@
How does this work in practice? Nixpkgs is now structured so that build-time dependencies are taken from <varname>buildPackages</varname>, whereas run-time dependencies are taken from the top level attribute set.
For example, <varname>buildPackages.gcc</varname> should be used at build time, while <varname>gcc</varname> should be used at run time.
Now, for most of Nixpkgs's history, there was no <varname>buildPackages</varname>, and most packages have not been refactored to use it explicitly.
Instead, one can use the six (<emphasis>gasp</emphasis>) attributes used for specifying dependencies as documented in <xreflinkend="ssec-stdenv-dependencies"/>.
Instead, one can use the four attributes used for specifying dependencies as documented in <xreflinkend="ssec-stdenv-attributes"/>.
We "splice" together the run-time and build-time package sets with <varname>callPackage</varname>, and then <varname>mkDerivation</varname> for each of four attributes pulls the right derivation out.
This splicing can be skipped when not cross compiling as the package sets are the same, but is a bit slow for cross compiling.
Because of this, a best-of-both-worlds solution is in the works with no splicing or explicit access of <varname>buildPackages</varname> needed.
For now, feel free to use either method.
</para>
<note><para>
There is also a "backlink" <varname>targetPackages</varname>, yielding a package set whose <varname>buildPackages</varname> is the current package set.
There is also a "backlink" <varname>__targetPackages</varname>, yielding a package set whose <varname>buildPackages</varname> is the current package set.
This is a hack, though, to accommodate compilers with lousy build systems.
Please do not use this unless you are absolutely sure you are packaging such a compiler and there is no other way.
</para></note>
</section>
<section>
<title>Cross packagaing cookbook</title>
<para>
Some frequently problems when packaging for cross compilation are good to just spell and answer.
Ideally the information above is exhaustive, so this section cannot provide any new information,
but its ludicrous and cruel to expect everyone to spend effort working through the interaction of many features just to figure out the same answer to the same common problem.
Feel free to add to this list!
</para>
<qandaset>
<qandaentry>
<question><para>
What if my package's build system needs to build a C program to be run under the build environment?
or also with <varname>crossSystem</varname>, in which case packages run on the latter, but all building happens on the former.
Both parameters take the same schema as the 3 (build, host, and target) platforms defined in the previous section.
As mentioned above, <literal>lib.systems.examples</literal> has some platforms which are used as arguments for these parameters in practice.
You can use them programmatically, or on the command line: <programlisting>
nix-build <nixpkgs> --arg crossSystem '(import <nixpkgs/lib>).systems.examples.fooBarBaz' -A whatever</programlisting>
You can use them programmatically, or on the command line like <command>nix-build <nixpkgs> --arg crossSystem '(import <nixpkgs/lib>).systems.examples.fooBarBaz'</command>.
</para>
<note>
<para>
Eventually we would like to make these platform examples an unnecessary convenience so that <programlisting>
nix-build <nixpkgs> --arg crossSystem.config '<arch>-<os>-<vendor>-<abi>' -A whatever</programlisting>
works in the vast majority of cases.
The problem today is dependencies on other sorts of configuration which aren't given proper defaults.
We rely on the examples to crudely to set those configuration parameters in some vaguely sane manner on the users behalf.
Issue <linkxlink:href="https://github.com/NixOS/nixpkgs/issues/34274">#34274</link> tracks this inconvenience along with its root cause in crufty configuration options.
</para>
</note>
<para>
While one is free to pass both parameters in full, there's a lot of logic to fill in missing fields.
As discussed in the previous section, only one of <varname>system</varname>, <varname>config</varname>, and <varname>parsed</varname> is needed to infer the other two.
is for <emphasis>developer</emphasis> documentation. Currently we count gtk-doc and devhelp books in there. It goes to <varname>devdoc</varname> or is removed (!) by default. This is because e.g. gtk-doc tends to be rather large and completely unused by nixpkgs users.
is for <emphasis>developer</emphasis> documentation. Currently we count gtk-doc in there. It goes to <varname>devdoc</varname> or is removed (!) by default. This is because e.g. gtk-doc tends to be rather large and completely unused by nixpkgs users.
As described in the Nix manual, almost any <filename>*.drv</filename> store path in a derivation's attribute set will induce a dependency on that derivation.
<varname>mkDerivation</varname>, however, takes a few attributes intended to, between them, include all the dependencies of a package.
This is done both for structure and consistency, but also so that certain other setup can take place.
For example, certain dependencies need their bin directories added to the <envar>PATH</envar>.
That is built-in, but other setup is done via a pluggable mechanism that works in conjunction with these dependency attributes.
See <xreflinkend="ssec-setup-hooks"/> for details.
</para>
<para>
Dependencies can be broken down along three axes: their host and target platforms relative to the new derivation's, and whether they are propagated.
The platform distinctions are motivated by cross compilation; see <xreflinkend="chap-cross"/> for exactly what each platform means.
<footnote><para>
The build platform is ignored because it is a mere implementation detail of the package satisfying the dependency:
As a general programming principle, dependencies are always <emphasis>specified</emphasis> as interfaces, not concrete implementation.
</para></footnote>
But even if one is not cross compiling, the platforms imply whether or not the dependency is needed at run-time or build-time, a concept that makes perfect sense outside of cross compilation.
For now, the run-time/build-time distinction is just a hint for mental clarity, but in the future it perhaps could be enforced.
</para>
<para>
The extension of <envar>PATH</envar> with dependencies, alluded to above, proceeds according to the relative platforms alone.
The process is carried out only for dependencies whose host platform matches the new derivation's build platform–i.e. which run on the platform where the new derivation will be built.
<footnote><para>
Currently, that means for native builds all dependencies are put on the <envar>PATH</envar>.
But in the future that may not be the case for sake of matching cross:
the platforms would be assumed to be unique for native and cross builds alike, so only the <varname>depsBuild*</varname> and <varname>nativeBuildDependencies</varname> dependencies would affect the <envar>PATH</envar>.
</para></footnote>
For each dependency <replaceable>dep</replaceable> of those dependencies, <filename><replaceable>dep</replaceable>/bin</filename>, if present, is added to the <envar>PATH</envar> environment variable.
</para>
<para>
The dependency is propagated when it forces some of its other-transitive (non-immediate) downstream dependencies to also take it on as an immediate dependency.
Nix itself already takes a package's transitive dependencies into account, but this propagation ensures nixpkgs-specific infrastructure like setup hooks (mentioned above) also are run as if the propagated dependency.
</para>
<para>
It is important to note dependencies are not necessary propagated as the same sort of dependency that they were before, but rather as the corresponding sort so that the platform rules still line up.
The exact rules for dependency propagation can be given by assigning each sort of dependency two integers based one how it's host and target platforms are offset from the depending derivation's platforms.
Those offsets are given are given below in the descriptions of each dependency list attribute.
Algorithmically, we traverse propagated inputs, accumulating every propagated dep's propagated deps and adjusting them to account for the "shift in perspective" described by the current dep's platform offsets.
This results in sort a transitive closure of the dependency relation, with the offsets being approximately summed when two dependency links are combined.
We also prune transitive deps whose combined offsets go out-of-bounds, which can be viewed as a filter over that transitive closure removing dependencies that are blatantly absurd.
</para>
<para>
We can define the process precisely with <linkxlink:href="https://en.wikipedia.org/wiki/Natural_deduction">Natural Deduction</link> using the inference rules.
This probably seems a bit obtuse, but so is the bash code that actually implements it!
<footnote><para>
The <function>findInputs</function> function, currently residing in <filename>pkgs/stdenv/generic/setup.sh</filename>, implements the propagation logic.
</para></footnote>
They're confusing in very different ways so...hopefully if something doesn't make sense in one presentation, it does in the other!
<programlisting>
let mapOffset(h, t, i) = i + (if i <= 0 then h else t - 1)
let mapOffset(h, t, i) = i + (if i <= 0 then h else t - 1)
dep(h0, _, A, B)
propagated-dep(h1, t1, B, C)
h0 + h1 in {-1, 0, 1}
h0 + t1 in {-1, 0, -1}
-------------------------------------- Take immediate deps' propagated deps
propagated-dep(mapOffset(h0, t0, h1),
mapOffset(h0, t0, t1),
A, C)</programlisting>
<programlisting>
propagated-dep(h, t, A, B)
-------------------------------------- Propagated deps count as deps
dep(h, t, A, B)</programlisting>
Some explanation of this monstrosity is in order.
In the common case, the target offset of a dependency is the successor to the target offset: <literal>t = h + 1</literal>.
That means that:
<programlisting>
let f(h, t, i) = i + (if i <= 0 then h else t - 1)
let f(h, h + 1, i) = i + (if i <= 0 then h else (h + 1) - 1)
let f(h, h + 1, i) = i + (if i <= 0 then h else h)
let f(h, h + 1, i) = i + h
</programlisting>
This is where the "sum-like" comes from above:
We can just sum all the host offset to get the host offset of the transitive dependency.
The target offset is the transitive dep is simply the host offset + 1, just as it was with the dependencies composed to make this transitive one;
it can be ignored as it doesn't add any new information.
</para>
<para>
Because of the bounds checks, the uncommon cases are <literal>h = t</literal> and <literal>h + 2 = t</literal>.
In the former case, the motivation for <function>mapOffset</function> is that since its host and target platforms are the same, no transitive dep of it should be able to "discover" an offset greater than its reduced target offsets.
<function>mapOffset</function> effectively "squashes" all its transitive dependencies' offsets so that none will ever be greater than the target offset of the original <literal>h = t</literal> package.
In the other case, <literal>h + 1</literal> is skipped over between the host and target offsets.
Instead of squashing the offsets, we need to "rip" them apart so no transitive dependencies' offset is that one.
</para>
<para>
Overall, the unifying theme here is that propagation shouldn't be introducing transitive dependencies involving platforms the needing package is unaware of.
The offset bounds checking and definition of <function>mapOffset</function> together ensure that this is the case.
Discovering a new offset is discovering a new platform, and since those platforms weren't in the derivation "spec" of the needing package, they cannot be relevant.
From a capability perspective, we can imagine that the host and target platforms of a package are the capabilities a package requires, and the depending package must provide the capability to the dependency.
</para>
<variablelist>
<title>Variables specifying dependencies</title>
<varlistentry>
<term><varname>depsBuildBuild</varname></term>
<listitem>
<para>
A list of dependencies whose host and target platforms are the new derivation's build platform.
This means a <literal>-1</literal> host and <literal>-1</literal> target offset from the new derivation's platforms.
They are programs/libraries used at build time that furthermore produce programs/libraries also used at build time.
If the dependency doesn't care about the target platform (i.e. isn't a compiler or similar tool), put it in <varname>nativeBuildInputs</varname>instead.
The most common use for this <literal>buildPackages.stdenv.cc</literal>, the default C compiler for this role.
That example crops up more than one might think in old commonly used C libraries.
</para>
<para>
Since these packages are able to be run at build time, that are always added to the <envar>PATH</envar>, as described above.
But since these packages are only guaranteed to be able to run then, they shouldn't persist as run-time dependencies.
This isn't currently enforced, but could be in the future.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term><varname>nativeBuildInputs</varname></term>
<listitem>
<para>
A list of dependencies whose host platform is the new derivation's build platform, and target platform is the new derivation's host platform.
This means a <literal>-1</literal> host offset and <literal>0</literal> target offset from the new derivation's platforms.
They are programs/libraries used at build time that, if they are a compiler or similar tool, produce code to run at run time—i.e. tools used to build the new derivation.
If the dependency doesn't care about the target platform (i.e. isn't a compiler or similar tool), put it here, rather than in <varname>depsBuildBuild</varname> or <varname>depsBuildTarget</varname>.
This would be called <varname>depsBuildHost</varname> but for historical continuity.
</para>
<para>
Since these packages are able to be run at build time, that are added to the <envar>PATH</envar>, as described above.
But since these packages only are guaranteed to be able to run then, they shouldn't persist as run-time dependencies.
This isn't currently enforced, but could be in the future.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term><varname>depsBuildTarget</varname></term>
<listitem>
<para>
A list of dependencies whose host platform is the new derivation's build platform, and target platform is the new derivation's target platform.
This means a <literal>-1</literal> host offset and <literal>1</literal> target offset from the new derivation's platforms.
They are programs used at build time that produce code to run at run with code produced by the depending package.
Most commonly, these would tools used to build the runtime or standard library the currently-being-built compiler will inject into any code it compiles.
In many cases, the currently-being built compiler is itself employed for that task, but when that compiler won't run (i.e. its build and host platform differ) this is not possible.
Other times, the compiler relies on some other tool, like binutils, that is always built separately so the dependency is unconditional.
</para>
<para>
This is a somewhat confusing dependency to wrap ones head around, and for good reason.
As the only one where the platform offsets are not adjacent integers, it requires thinking of a bootstrapping stage <emphasis>two</emphasis> away from the current one.
It and it's use-case go hand in hand and are both considered poor form:
try not to need this sort dependency, and try not avoid building standard libraries / runtimes in the same derivation as the compiler produces code using them.
Instead strive to build those like a normal library, using the newly-built compiler just as a normal library would.
In short, do not use this attribute unless you are packaging a compiler and are sure it is needed.
</para>
<para>
Since these packages are able to be run at build time, that are added to the <envar>PATH</envar>, as described above.
But since these packages only are guaranteed to be able to run then, they shouldn't persist as run-time dependencies.
This isn't currently enforced, but could be in the future.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term><varname>depsHostHost</varname></term>
<listitem><para>
A list of dependencies whose host and target platforms match the new derivation's host platform.
This means a both <literal>0</literal> host offset and <literal>0</literal> target offset from the new derivation's host platform.
These are packages used at run-time to generate code also used at run-time.
In practice, that would usually be tools used by compilers for metaprogramming/macro systems, or libraries used by the macros/metaprogramming code itself.
It's always preferable to use a <varname>depsBuildBuild</varname> dependency in the derivation being built than a <varname>depsHostHost</varname> on the tool doing the building for this purpose.
</para></listitem>
</varlistentry>
<varlistentry>
<term><varname>buildInputs</varname></term>
<listitem>
<para>
A list of dependencies whose host platform and target platform match the new derivation's.
This means a <literal>0</literal> host offset and <literal>1</literal> target offset from the new derivation's host platform.
This would be called <varname>depsHostTarget</varname> but for historical continuity.
If the dependency doesn't care about the target platform (i.e. isn't a compiler or similar tool), put it here, rather than in <varname>depsBuildBuild</varname>.
</para>
<para>
These often are programs/libraries used by the new derivation at <emphasis>run</emphasis>-time, but that isn't always the case.
For example, the machine code in a statically linked library is only used at run time, but the derivation containing the library is only needed at build time.
Even in the dynamic case, the library may also be needed at build time to appease the linker.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term><varname>depsTargetTarget</varname></term>
<listitem><para>
A list of dependencies whose host platform matches the new derivation's target platform.
This means a <literal>1</literal> offset from the new derivation's platforms.
These are packages that run on the target platform, e.g. the standard library or run-time deps of standard library that a compiler insists on knowing about.
It's poor form in almost all cases for a package to depend on another from a future stage [future stage corresponding to positive offset].
Do not use this attribute unless you are packaging a compiler and are sure it is needed.
The propagated equivalent of <varname>nativeBuildInputs</varname>.
This would be called <varname>depsBuildHostPropagated</varname> but for historical continuity.
For example, if package <varname>Y</varname> has <literal>propagatedNativeBuildInputs = [X]</literal>, and package <varname>Z</varname> has <literal>buildInputs = [Y]</literal>, then package <varname>Z</varname> will be built as if it included package <varname>X</varname> in its <varname>nativeBuildInputs</varname>.
If instead, package <varname>Z</varname> has <literal>nativeBuildInputs = [Y]</literal>, then <varname>Z</varname> will be built as if it included <varname>X</varname> in the <varname>depsBuildBuild</varname> of package <varname>Z</varname>, because of the sum of the two <literal>-1</literal> host offsets.
@@ -450,12 +188,57 @@ From a capability perspective, we can imagine that the host and target platforms
<varlistentry>
<term><varname>NIX_DEBUG</varname></term>
<listitem><para>If set, <literal>stdenv</literal> will print some
debug information during the build. In particular, the
<command>gcc</command> and <command>ld</command> wrapper scripts
will print out the complete command line passed to the wrapped
tools.</para></listitem>
</varlistentry>
</variablelist>
<variablelist>
<title>Variables specifying dependencies</title>
<varlistentry>
<term><varname>nativeBuildInputs</varname></term>
<listitem><para>
A natural number indicating how much information to log.
If set to 1 or higher, <literal>stdenv</literal> will print moderate debug information during the build.
In particular, the <command>gcc</command> and <command>ld</command> wrapper scripts will print out the complete command line passed to the wrapped tools.
If set to 6 or higher, the <literal>stdenv</literal> setup script will be run with <literal>set -x</literal> tracing.
If set to 7 or higher, the <command>gcc</command> and <command>ld</command> wrapper scripts will also be run with <literal>set -x</literal> tracing.
A list of dependencies used by the new derivation at <emphasis>build</emphasis>-time.
I.e. these dependencies should not make it into the package's runtime-closure, though this is currently not checked.
For each dependency <replaceable>dir</replaceable>, the directory <filename><replaceable>dir</replaceable>/bin</filename>, if it exists, is added to the <envar>PATH</envar> environment variable.
Other environment variables are also setup via a pluggable mechanism.
For instance, if <varname>buildInputs</varname> contains Perl, then the <filename>lib/site_perl</filename> subdirectory of each input is added to the<envar>PERL5LIB</envar> environment variable.
See <xreflinkend="ssec-setup-hooks"/> for details.
</para></listitem>
</varlistentry>
<varlistentry>
<term><varname>buildInputs</varname></term>
<listitem><para>
A list of dependencies used by the new derivation at <emphasis>run</emphasis>-time.
Currently, the build-time environment is modified in the exact same way as with <varname>nativeBuildInputs</varname>.
This is problematic in that when cross-compiling, foreign executables can clobber native ones on the <envar>PATH</envar>.
Even more confusing is static-linking.
A statically-linked library should be listed here because ultimately that generated machine code will be used at run-time, even though a derivation containing the object files or static archives will only be used at build-time.
Like <varname>nativeBuildInputs</varname>, but these dependencies are <emphasis>propagated</emphasis>:
that is, the dependencies listed here are added to the <varname>nativeBuildInputs</varname> of any package that uses <emphasis>this</emphasis> package as a dependency.
So if package Y has <literal>propagatedBuildInputs = [X]</literal>, and package Z has <literal>buildInputs = [Y]</literal>, then package X will appear in Z’s build environment automatically.
<para>If set to <literal>true</literal>, <literal>stdenv</literal> will
pass specific flags to <literal>make</literal> and other build tools to
enable parallel building with up to <literal>build-cores</literal>
workers.</para>
<para>Unless set to <literal>false</literal>, some build systems with good
support for parallel building including <literal>cmake</literal>,
<literal>meson</literal>, and <literal>qmake</literal> will set it to
<literal>true</literal>.</para>
</listitem>
<listitem><para>If set, <literal>stdenv</literal> will pass specific
flags to <literal>make</literal> and other build tools to enable
parallel building with up to <literal>build-cores</literal>
workers.</para></listitem>
</varlistentry>
<varlistentry>
@@ -871,7 +647,7 @@ script) if it exists.</para>
By default, when cross compiling, the configure script has <option>--build=...</option> and <option>--host=...</option> passed.
Packages can instead pass <literal>[ "build" "host" "target" ]</literal> or a subset to control exactly which platform flags are passed.
Compilers and other tools should use this to also pass the target platform, for example.
<footnote><para>Eventually these will be passed when in native builds too, to improve determinism: build-time guessing, as is done today, is a risk of impurity.</para></footnote>
Note eventually these will be passed when in native builds too, to improve determinism: build-time guessing, as is done today, is a risk of impurity.
</para></listitem>
</varlistentry>
@@ -921,14 +697,8 @@ nothing.</para>
<listitem><para>A list of strings passed as additional flags to
<command>make</command>. These flags are also used by the default
install and check phase. For setting make flags specific to the
build phase, use <varname>buildFlags</varname> (see below).
<programlisting>
makeFlags = [ "PREFIX=$(out)" ];
</programlisting>
<note><para>The flags are quoted in bash, but environment variables can
be specified by using the make syntax.</para></note></para></listitem>
build phase, use <varname>buildFlags</varname> (see
below).</para></listitem>
</varlistentry>
<varlistentry>
@@ -995,14 +765,13 @@ but only if the <varname>doCheck</varname> variable is enabled.</para>
<varlistentry>
<term><varname>doCheck</varname></term>
<listitem><para>
Controls whether the check phase is executed.
By default it is skipped, but if <varname>doCheck</varname> is set to true, the check phase is usually executed.
Thus you should set <programlisting>doCheck = true;</programlisting> in the derivation to enable checks.
The exception is cross compilation.
Cross compiled builds never run tests, no matter how <varname>doCheck</varname> is set,
as the newly-built program won't run on the platform used to build it.
</para></listitem>
<listitem><para>If set to a non-empty string, the check phase is
executed, otherwise it is skipped (default). Thus you should set
<programlisting>
doCheck = true;</programlisting>
in the derivation to enable checks.</para></listitem>
</varlistentry>
<varlistentry>
@@ -1139,20 +908,6 @@ following:
<listitem><para>If set, libraries and executables are not
stripped. By default, they are.</para></listitem>
</varlistentry>
<varlistentry>
<term><varname>dontStripHost</varname></term>
<listitem><para>
Like <varname>dontStripHost</varname>, but only affects the <command>strip</command> command targetting the package's host platform.
Useful when supporting cross compilation, but otherwise feel free to ignore.
</para></listitem>
</varlistentry>
<varlistentry>
<term><varname>dontStripTarget</varname></term>
<listitem><para>
Like <varname>dontStripHost</varname>, but only affects the <command>strip</command> command targetting the packages' target platform.
Useful when supporting cross compilation, but otherwise feel free to ignore.
Nix itself considers a build-time dependency merely something that should previously be built and accessible at build time—packages themselves are on their own to perform any additional setup.
In most cases, that is fine, and the downstream derivation can deal with it's own dependencies.
But for a few common tasks, that would result in almost every package doing the same sort of setup work---depending not on the package itself, but entirely on which dependencies were used.
</para>
<para>
In order to alleviate this burden, the <firstterm>setup hook></firstterm>mechanism was written, where any package can include a shell script that [by convention rather than enforcement by Nix], any downstream reverse-dependency will source as part of its build process.
That allows the downstream dependency to merely specify its dependencies, and lets those dependencies effectively initialize themselves.
No boilerplate mirroring the list of dependencies is needed.
</para>
<para>
The Setup hook mechanism is a bit of a sledgehammer though: a powerful feature with a broad and indiscriminate area of effect.
The combination of its power and implicit use may be expedient, but isn't without costs.
Nix itself is unchanged, but the spirit of adding dependencies being effect-free is violated even if the letter isn't.
For example, if a derivation path is mentioned more than once, Nix itself doesn't care and simply makes sure the dependency derivation is already built just the same—depending is just needing something to exist, and needing is idempotent.
However, a dependency specified twice will have its setup hook run twice, and that could easily change the build environment (though a well-written setup hook will therefore strive to be idempotent so this is in fact not observable).
More broadly, setup hooks are anti-modular in that multiple dependencies, whether the same or different, should not interfere and yet their setup hooks may well do so.
</para>
<para>
The most typical use of the setup hook is actually to add other hooks which are then run (i.e. after all the setup hooks) on each dependency.
For example, the C compiler wrapper's setup hook feeds itself flags for each dependency that contains relevant libaries and headers.
This is done by defining a bash function, and appending its name to one of
<envar>envBuildBuildHooks</envar>`,
<envar>envBuildHostHooks</envar>`,
<envar>envBuildTargetHooks</envar>`,
<envar>envHostHostHooks</envar>`,
<envar>envHostTargetHooks</envar>`, or
<envar>envTargetTargetHooks</envar>`.
These 6 bash variables correspond to the 6 sorts of dependencies by platform (there's 12 total but we ignore the propagated/non-propagated axis).
</para>
<para>
Packages adding a hook should not hard code a specific hook, but rather choose a variable <emphasis>relative</emphasis> to how they are included.
Returning to the C compiler wrapper example, if it itself is an <literal>n</literal> dependency, then it only wants to accumulate flags from <literal>n + 1</literal> dependencies, as only those ones match the compiler's target platform.
The <envar>hostOffset</envar> variable is defined with the current dependency's host offset <envar>targetOffset</envar> with its target offset, before it's setup hook is sourced.
Additionally, since most environment hooks don't care about the target platform,
That means the setup hook can append to the right bash array by doing something like
<programlistinglanguage="bash">
addEnvHooks "$hostOffset" myBashFunction
</programlisting>
</para>
<para>
The <emphasis>existence</emphasis> of setups hooks has long been documented and packages inside Nixpkgs are free to use these mechanism.
Other packages, however, should not rely on these mechanisms not changing between Nixpkgs versions.
Because of the existing issues with this system, there's little benefit from mandating it be stable for any period of time.
</para>
<para>
Here are some packages that provide a setup hook.
Since the mechanism is modular, this probably isn't an exhaustive list.
Then again, since the mechanism is only to be used as a last resort, it might be.
<para>The following packages provide a setup hook:
<variablelist>
<varlistentry>
<term>Bintools Wrapper</term>
<term>CC Wrapper</term>
<listitem>
<para>
Bintools Wrapper wraps the binary utilities for a bunch of miscellaneous purposes.
These are GNU Binutils when targetting Linux, and a mix of cctools and GNU binutils for Darwin.
[The "Bintools" name is supposed to be a compromise between "Binutils" and "cctools" not denoting any specific implementation.]
Specifically, the underlying bintools package, and a C standard library (glibc or Darwin's libSystem, just for the dynamic loader) are all fed in, and dependency finding, hardening (see below), and purity checks for each are handled by Bintools Wrapper.
Packages typically depend on CC Wrapper, which in turn (at run time) depends on Bintools Wrapper.
CC Wrapper wraps a C toolchain for a bunch of miscellaneous purposes.
Specifically, a C compiler (GCC or Clang), Binutils (or the CCTools + binutils mashup when targetting Darwin), and a C standard library (glibc or Darwin's libSystem) are all fed in, and dependency finding, hardening (see below), and purity checks for each are handled by CC Wrapper.
Packages typically depend on only CC Wrapper, instead of those 3 inputs directly.
</para>
<para>
Bintools Wrapper was only just recently split off from CC Wrapper, so the division of labor is still being worked out.
For example, it shouldn't care about about the C standard library, but just take a derivation with the dynamic loader (which happens to be the glibc on linux).
Dependency finding however is a task both wrappers will continue to need to share, and probably the most important to understand.
Dependency finding is undoubtedly the main task of CC wrapper.
It is currently accomplished by collecting directories of host-platform dependencies (i.e. <varname>buildInputs</varname> and <varname>nativeBuildInputs</varname>) in environment variables.
Bintools Wrapper's setup hook causes any <filename>lib</filename> and <filename>lib64</filename> subdirectories to be added to <envar>NIX_LDFLAGS</envar>.
Since CC Wrapper and Bintools Wrapper use the same strategy, most of the Bintools Wrapper code is sparsely commented and refers to CC Wrapper.
But CC Wrapper's code, by contrast, has quite lengthy comments.
Bintools Wrapper merely cites those, rather than repeating them, to avoid falling out of sync.
CC wrapper's setup hook causes any <filename>include</filename> subdirectory of such a dependency to be added to <envar>NIX_CFLAGS_COMPILE</envar>, and any <filename>lib</filename> and <filename>lib64</filename> subdirectories to <envar>NIX_LDFLAGS</envar>.
The setup hook itself contains some lengthy comments describing the exact convoluted mechanism by which this is accomplished.
</para>
<para>
A final task of the setup hook is defining a number of standard environment variables to tell build systems which executables full-fill which purpose.
They are defined to just be the base name of the tools, under the assumption that Bintools Wrapper's binaries will be on the path.
They are defined to just be the base name of the tools, under the assumption that CC Wrapper's binaries will be on the path.
Firstly, this helps poorly-written packages, e.g. ones that look for just <command>gcc</command> when <envar>CC</envar> isn't defined yet <command>clang</command> is to be used.
Secondly, this helps packages not get confused when cross-compiling, in which case multiple Bintools Wrappers may simultaneously be in use.
<footnote><para>
Each wrapper targets a single platform, so if binaries for multiple platforms are needed, the underlying binaries must be wrapped multiple times.
As this is a property of the wrapper itself, the multiple wrappings are needed whether or not the same underlying binaries can target multiple platforms.
</para></footnote>
<envar>BUILD_</envar>- and <envar>TARGET_</envar>-prefixed versions of the normal environment variable are defined for the additional Bintools Wrappers, properly disambiguating them.
Secondly, this helps packages not get confused when cross-compiling, in which case multiple CC wrappers may be simultaneous in use (targeting different platforms).
<envar>BUILD_</envar>- and <envar>TARGET_</envar>-prefixed versions of the normal environment variable are defined for the additional CC Wrappers, properly disambiguating them.
</para>
<para>
A problem with this final task is that Bintools Wrapper is honest and defines <envar>LD</envar> as <command>ld</command>.
A problem with this final task is that CC Wrapper is honest and defines <envar>LD</envar> as <command>ld</command>.
Most packages, however, firstly use the C compiler for linking, secondly use <envar>LD</envar> anyways, defining it as the C compiler, and thirdly, only so define <envar>LD</envar> when it is undefined as a fallback.
This triple-threat means Bintools Wrapper will break those packages, as LD is already defined as the actual linker which the package won't override yet doesn't want to use.
This triple-threat means CC Wrapper will break those packages, as LD is already defined as the actually linker which the package won't override yet doesn't want to use.
The workaround is to define, just for the problematic package, <envar>LD</envar> as the C compiler.
A good way to do this would be <command>preConfigure = "LD=$CC"</command>.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term>CC Wrapper</term>
<listitem>
<para>
CC Wrapper wraps a C toolchain for a bunch of miscellaneous purposes.
Specifically, a C compiler (GCC or Clang), wrapped binary tools, and a C standard library (glibc or Darwin's libSystem, just for the dynamic loader) are all fed in, and dependency finding, hardening (see below), and purity checks for each are handled by CC Wrapper.
Packages typically depend on CC Wrapper, which in turn (at run time) depends on Bintools Wrapper.
</para>
<para>
Dependency finding is undoubtedly the main task of CC Wrapper.
This works just like Bintools Wrapper, except that any <filename>include</filename> subdirectory of any relevant dependency is added to <envar>NIX_CFLAGS_COMPILE</envar>.
The setup hook itself contains some lengthy comments describing the exact convoluted mechanism by which this is accomplished.
</para>
<para>
CC Wrapper also like Bintools Wrapper defines standard environment variables with the names of the tools it wraps, for the same reasons described above.
Importantly, while it includes a <command>cc</command> symlink to the c compiler for portability, the <envar>CC</envar> will be defined using the compiler's "real name" (i.e. <command>gcc</command> or <command>clang</command>).
This helps lousy build systems that inspect on the name of the compiler rather than run it.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term>Perl</term>
<listitem>
<para>
Adds the <filename>lib/site_perl</filename> subdirectory of each build input to the <envar>PERL5LIB</envar> environment variable.
For instance, if <varname>buildInputs</varname> contains Perl, then the <filename>lib/site_perl</filename> subdirectory of each input is added to the <envar>PERL5LIB</envar> environment variable.
</para>
</listitem>
<listitem><para>Adds the <filename>lib/site_perl</filename> subdirectory
of each build input to the <envar>PERL5LIB</envar>
checkConfigError 'The option value .* in .* is not of type.*unsigned integer.*' config.value ./declare-int-unsigned-value.nix ./define-value-int-negative.nix
# positive
checkConfigError 'The option value .* in .* is not of type.*positive integer.*' config.value ./declare-int-positive-value.nix ./define-value-int-zero.nix
checkConfigError 'The option value .* in .* is not of type.*between.*-21 and 43.*inclusive.*' config.value ./declare-int-between-value.nix ./define-value-int-negative.nix
# Check mkForce without submodules.
set -- config.enable ./declare-enable.nix ./define-enable.nix
the <literal>openssh_with_kerberos</literal> package
is now a deprecated alias.
If you do not want Kerberos support,
you can do <literal>openssh.override { withKerboros = false; }</literal>.
Note, this also applies to the <literal>openssh_hpn</literal> package.
</para>
</listitem>
<listitem>
<para>
<literal>cc-wrapper</literal> has been split in two; there is now also a <literal>bintools-wrapper</literal>.
The most commonly used files in <filename>nix-support</filename> are now split between the two wrappers.
Some commonly used ones, like <filename>nix-support/dynamic-linker</filename>, are duplicated for backwards compatability, even though they rightly belong only in <literal>bintools-wrapper</literal>.
Other more obscure ones are just moved.
</para>
</listitem>
<listitem>
<para>
The propagation logic has been changed.
The new logic, along with new types of dependencies that go with, is thoroughly documented in the "Specifying dependencies" section of the "Standard Environment" chapter of the nixpkgs manual.
<!-- That's <xref linkend="ssec-stdenv-attributes"> were we to merge the manuals. -->
The old logic isn't but is easy to describe: dependencies were propagated as the same type of dependency no matter what.
In practice, that means that many <function>propagatedNativeBuildInputs</function> should instead be <function>propagatedBuildInputs</function>.
Thankfully, that was and is the least used type of dependency.
Also, it means that some <function>propagatedBuildInputs</function> should instead be <function>depsTargetTargetPropagated</function>.
Other types dependencies should be unaffected.
</para>
</listitem>
<listitem>
<para>
<literal>lib.addPassthru drv passthru</literal> is removed. Use <literal>lib.extendDerivation true passthru drv</literal> instead.
</para>
</listitem>
<listitem>
<para>
The <literal>memcached</literal> service no longer accept dynamic socket
paths via <option>services.memcached.socket</option>. Unix sockets can be
still enabled by <option>services.memcached.enableUnixSocket</option> and
will be accessible at <literal>/run/memcached/memcached.sock</literal>.
</para>
</listitem>
<listitem>
<para>
The <varname>hardware.amdHybridGraphics.disable</varname> option was removed for lack of a maintainer. If you still need this module, you may wish to include a copy of it from an older version of nixos in your imports.
</para>
</listitem>
<listitem>
<para>
The merging of config options for <varname>services.postfix.config</varname>
was buggy. Previously, if other options in the Postfix module like
<varname>services.postfix.useSrs</varname> were set and the user set config
options that were also set by such options, the resulting config wouldn't
include all options that were needed. They are now merged correctly. If
config options need to be overridden, <literal>lib.mkForce</literal> or
<literal>lib.mkOverride</literal> can be used.
</para>
</listitem>
<listitem>
<para>
The following changes apply if the <literal>stateVersion</literal> is changed to 18.03 or higher.
For <literal>stateVersion = "17.09"</literal> or lower the old behavior is preserved.
</para>
<itemizedlist>
<listitem>
<para>
<literal>matrix-synapse</literal> uses postgresql by default instead of sqlite.
Migration instructions can be found <linkxlink:href="https://github.com/matrix-org/synapse/blob/master/docs/postgres.rst#porting-from-sqlite"> here </link>.
</para>
</listitem>
</itemizedlist>
</listitem>
<listitem>
<para>
The <literal>jid</literal> package has been removed, due to maintenance
overhead of a go package having non-versioned dependencies.
</para>
</listitem>
<listitem>
<para>
When using <option>services.xserver.libinput</option> (enabled by default in GNOME),
it now handles all input devices, not just touchpads. As a result, you might need to
re-evaluate any custom Xorg configuration. In particular,
<literal>Option "XkbRules" "base"</literal> may result in broken keyboard layout.
</para>
</listitem>
<listitem>
<para>
The <literal>attic</literal> package was removed. A maintained fork called
<linkxlink:href="https://www.borgbackup.org/">Borg</link> should be used instead.
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
