Upstream changes:
* Fix ordering between systemd socket file descriptor names and rules.
* Fix usage of C library path as discovered by Meson.
Signed-off-by: aszlig <aszlig@nix.build>
(cherry picked from commit 8b7f8e2e69)
Upstream fixes:
- Pass linker version script to the linker instead of the compiler.
- Compile with `-fPIC` again (regression from version 2.1.2).
- Out of bounds array access in `globpath`.
- Handling of `epoll_ctl` calls (they're now replayed after replacing
socket).
- GCC 10 build errors and Clang warnings.
While most of these fixes are more relevant for other distros, the
linker script fix is actually a regression existing since a long time
(version 1.x) and caused libip2unix to expose way too many symbols.
Built and tested on i686-linux and x86_64-linux.
Signed-off-by: aszlig <aszlig@nix.build>
(cherry picked from commit 67325b12c6)
This fixes the issues with glibc 2.30, which were caused because glibc
no longer allows to dlopen/LD_PRELOAD a PIE executable.
So this release is essentially just a hotfix release which addresses
this issue by splitting the executable and library.
Signed-off-by: aszlig <aszlig@nix.build>
Reported-by: @zimbatm
(cherry picked from commit b51d39fbe4)
Since M81 won't receive any updates anymore and there are known
vulnerabilities we should mark it as insecure so that users are aware of
the risks.
Updating Chromium to M83 is unfortunately too challenging for
19.09, but as of today we've already covered the one month period of
security updates for "oldstable" and both 20.03 and nixos-unstable
contain recent versions (i.e. users should either update to the current
stable release or install Chromium from a different channel).
nixos-unstable PR for M83: #88206
Regression introduced by bce5268a21.
The bit size of the initialisation vector for AES GCM has been
introduced in NSS version 3.52 in the CK_GCM_PARMS struct via the
ulIvBits field.
Unfortunately, Firefox 68.8.0 and 76.0 do not set this field and thus it
gets initialised to zero, which in turn causes IV generation to fail.
I found out about this because WebRTC stopped working after updating to
NSS 3.52 and so I started bisecting.
Since there wasn't an obvious error in Firefox hinting towards NSS but
instead just the video stream ended up as a "null" stream, I didn't
suspect the NSS update to be the culprit at first. So I verified a few
times and then also started bisecting the actual commit in NSS that
caused the issue.
This turned out to be the problematic change:
https://phabricator.services.mozilla.com/D63241
> One notable change was caused by an inconsistancy between the spec and
> the released headers in PKCS#11 v2.40. CK_GCM_PARAMS had an extra
> field in the header that was not in the spec. OASIS considers the
> header file to be normative, so PKCS#11 v3.0 resolved the issue in
> favor of the header file definition.
Since the test I've used[1] was a bit flaky, I still didn't believe the
result of the bisect to be accurate, but after running the test several
times leading same results I dug through the above change line by line
to get more clues.
It fortunately didn't take that long to stumble upon the ulIvBits change
(which is actually documented in the NSS 3.52 release notes[4], but I
managed to blatantly ignore it for some reason) and started checking the
Firefox source tree for changes regarding that field.
Initialisation of that new field has been introduced[2] in preparation
for the 76 release, but subsequently got reverted[3] prior to the
release, because Firefox 76 is expected to be shipped with NSS 3.51,
which didn't have the ulIvBits field.
The patch I'm adding here is just a reintroduction of that change,
because we're using NSS 3.52. Not initialising that field will break
WebRTC and WebCrypto, which I think the former seems to gain in
popularity these days ;-)
Tested the change against the mentioned VM test[1] and also by testing
manually using Jitsi Meet and Nextcloud Talk.
[1]: https://github.com/aszlig/avonc/tree/884315838b6f0ebb32b/tests/talk
[2]: https://hg.mozilla.org/mozilla-central/rev/3ed30e6b6de1
[3]: https://hg.mozilla.org/mozilla-central/rev/665137da70ee
[4]: https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/NSS_3.52_release_notes
Signed-off-by: aszlig <aszlig@nix.build>
(cherry picked from commit 8fb49973ce & moved to packages.nix)
Fixes: CVE-2020-6061, CVE-2020-6062
An exploitable heap overflow vulnerability exists in the way CoTURN
4.5.1.1 web server parses POST requests. A specially crafted HTTP
POST request can lead to information leaks and other misbehavior.
An attacker needs to send an HTTPS request to trigger this vulnerability.
An exploitable denial-of-service vulnerability exists in the way
CoTURN 4.5.1.1 web server parses POST requests. A specially crafted
HTTP POST request can lead to server crash and denial of service.
An attacker needs to send an HTTP request to trigger this vulnerability.
(cherry picked from commit 704a018aae)
`bundix -l` doesn't work, as it treats bundler's warning about upgrading
the lockfile version as an error, so invoke `bundle lock` manually.
(cherry picked from commit 4c26ab4198)
While it's already possible to invoke `update-data` with the `--rev`
argument, one still needs to run all later phases manually.
Fix this, by having `update-all` also accept a `--rev` argument, and
pass it down to `update-data`.
Also, make the help text a bit more usable, by suggesting the usual
versioning scheme used these times.
(cherry picked from commit 191c2c67a4)
'toString false' results in an empty string, which, in this context,
is a syntax error. Use boolToString instead.
Fixes#86160
(cherry picked from commit c0a838df38)
Kyndig on IRC noticed that building `ninja` from source would fail due
to a patch 404'ing (because the repo appears to no longer exist). Fetch
from upstream instead.
(cherry picked from commit 91d4e9aa97)
cc #85742
AP mode PMF disconnection protection bypass
Published: September 11, 2019
Identifiers:
- CVE-2019-16275
Latest version available from: https://w1.fi/security/2019-7/
Vulnerability
hostapd (and wpa_supplicant when controlling AP mode) did not perform
sufficient source address validation for some received Management frames
and this could result in ending up sending a frame that caused
associated stations to incorrectly believe they were disconnected from
the network even if management frame protection (also known as PMF) was
negotiated for the association. This could be considered to be a denial
of service vulnerability since PMF is supposed to protect from this type
of issues. It should be noted that if PMF is not enabled, there would be
no protocol level protection against this type of denial service
attacks.
An attacker in radio range of the access point could inject a specially
constructed unauthenticated IEEE 802.11 frame to the access point to
cause associated stations to be disconnected and require a reconnection
to the network.
Vulnerable versions/configurations
All hostapd and wpa_supplicants versions with PMF support
(CONFIG_IEEE80211W=y) and a runtime configuration enabled AP mode with
PMF being enabled (optional or required). In addition, this would be
applicable only when using user space based MLME/SME in AP mode, i.e.,
when hostapd (or wpa_supplicant when controlling AP mode) would process
authentication and association management frames. This condition would
be applicable mainly with drivers that use mac80211.
Possible mitigation steps
- Merge the following commit to wpa_supplicant/hostapd and rebuild:
AP: Silently ignore management frame from unexpected source address
This patch is available from https://w1.fi/security/2019-7/
- Update to wpa_supplicant/hostapd v2.10 or newer, once available
(cherry picked from commit 3e9f3a3ebd)
(cherry picked from commit cb5c0a4bbc)
Note: Only M81 is supported on 19.09. This is mainly to cherry-pick
stable channel updates and avoid an insecure chromiumBeta.
(cherry picked from commit ac374d41c8)
Backported 32.0.0.363 to release 19.09 for important bug fixes.
Also needed because old upstream release is no longer available.
(cherry picked from commit 27ca6c2939)
Rationale for backport: it's explicitly supported to build a kernel with
a custom tree. When using a 5.6 tree in a system configuration, eval
will break since `wireguard` is still evaluated and throws an
assertion-error on 5.6 or greater.
This can e.g. save around 150k lines of unnecessary log messages which
take up around 66% of the total lines (based on a log of 80.0.3987.100):
29527 warning: unknown warning option '-Wno-bitwise-conditional-parentheses'; did you mean '-Wno-bitwise-op-parentheses'? [-Wunknown-warning-option]
29527 warning: unknown warning option '-Wno-builtin-assume-aligned-alignment' [-Wunknown-warning-option]
29527 warning: unknown warning option '-Wno-deprecated-copy'; did you mean '-Wno-deprecated'? [-Wunknown-warning-option]
29527 warning: unknown warning option '-Wno-final-dtor-non-final-class'; did you mean '-Wno-abstract-final-class'? [-Wunknown-warning-option]
29527 warning: unknown warning option '-Wno-implicit-int-float-conversion'; did you mean '-Wno-implicit-float-conversion'? [-Wunknown-warning-option]
(cherry picked from commit 9f3914824d)
Adding this as a new attribute as software is likely going to break when
we switch the default from the 1.7 branch to 1.8.
(cherry picked from commit 1859b5a5ae)
... into staging. Fixes CVE-2020-11501.
(cherry picked from commit f91b34e53e)
These bumps combined still seem quite safe in terms of regression
likelihood.
The webrtc code suffered from a race condition when used
with Pulseaudio. This lead to audio input breaking every
couple of minutes during a webrtc session.
(cherry picked from commit 81b18c3711)
which was deprecated in 2018 and is now gone for good. I guess many
won’t notice because the nix-cache kept the files around?
(cherry picked from commit
b872b8a200 and 29ca177c68)
It seems the quoting breaks it just like in da587daae5
(cherry picked from commit e50bb280cbf5339ed671b0a7208e6aba4002c713)
(cherry picked from commit f8ccef5edb)
While our ETag patch works pretty fine if it comes to serving data off
store paths, it unfortunately broke something that might be a bit more
common, namely when using regexes to extract path components of
location directives for example.
Recently, @devhell has reported a bug with a nginx location directive
like this:
location ~^/\~([a-z0-9_]+)(/.*)?$" {
alias /home/$1/public_html$2;
}
While this might look harmless at first glance, it does however cause
issues with our ETag patch. The alias directive gets broken up by nginx
like this:
*2 http script copy: "/home/"
*2 http script capture: "foo"
*2 http script copy: "/public_html/"
*2 http script capture: "bar.txt"
In our patch however, we use realpath(3) to get the canonicalised path
from ngx_http_core_loc_conf_s.root, which returns the *configured* value
from the root or alias directive. So in the example above, realpath(3)
boils down to the following syscalls:
lstat("/home", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
lstat("/home/$1", 0x7ffd08da6f60) = -1 ENOENT (No such file or directory)
During my review[1] of the initial patch, I didn't actually notice that
what we're doing here is returning NGX_ERROR if the realpath(3) call
fails, which in turn causes an HTTP 500 error.
Since our patch actually made the canonicalisation (and thus additional
syscalls) necessary, we really shouldn't introduce an additional error
so let's - at least for now - silently skip return value if realpath(3)
has failed.
However since we're using the unaltered root from the config we have
another issue, consider this root:
/nix/store/...-abcde/$1
Calling realpath(3) on this path will fail (except if there's a file
called "$1" of course), so even this fix is not enough because it
results in the ETag not being set to the store path hash.
While this is very ugly and we should fix this very soon, it's not as
serious as getting HTTP 500 errors for serving static files.
I added a small NixOS VM test, which uses the example above as a
regression test.
It seems that my memory is failing these days, since apparently I *knew*
about this issue since digging for existing issues in nixpkgs, I found
this similar pull request which I even reviewed:
https://github.com/NixOS/nixpkgs/pull/66532
However, since the comments weren't addressed and the author hasn't
responded to the pull request, I decided to keep this very commit and do
a follow-up pull request.
[1]: https://github.com/NixOS/nixpkgs/pull/48337
Signed-off-by: aszlig <aszlig@nix.build>
Reported-by: @devhell
Acked-by: @7c6f434c
Acked-by: @yorickvP
Merges: https://github.com/NixOS/nixpkgs/pull/80671
Fixes: https://github.com/NixOS/nixpkgs/pull/66532
(cherry picked from commit e1d63ada02)
Some changes were made after final review of the package. There was a
missing runtime dependency that was discovered after merge of the
backport
(cherry picked from commit 9fe4a634c1)
Reason: The dependency can make the package work or not
The tag points to the same commit hash, so the binary
is unchanged.
Signed-off-by: David Anderson <dave@natulte.net>
(cherry picked from commit 3fa813e820)
fetchpatch can't be used here and fetchurl from GitHub
like in PR #82928 has the risk of breaking the hash later;
fortunately the patches aren't too large.
Since Go 1.13, `GOSUMDB` defaults to "sum.golang.org", to consult the
checksum database of the main module's go.sum.
We already use the default behavior when building `go-modules`, but Go
tries to consult the checksum database again when building the module,
and fails because since it requires `cacert` and `git` which are not
propagated when building the package.
(cherry picked from commit c5733e7a09)
a "Low severity" [0] security issue:
> Fixed an overflow bug in the x64_64 Montgomery squaring procedure used
> in exponentiation with 512-bit moduli (CVE-2019-1551)
[0] https://www.openssl.org/news/vulnerabilities.html#y2019
(cherry picked from commit abecf82e22)
The substitition in smtpd/parse.y isn't necessary anymore.
The hardcoded /usr/libexec/ has been replaced by a PATH_LIBEXEC #define,
which will be set properly by the build system.
(cherry picked from commit 96588508bb)
This bumps to the latest state of the systemd 242 stable, published at
https://github.com/systemd/systemd-stable/tree/v243-stable.
Should cover CVE-2020-1712.
Git Log:
f8dd0f2f15 (tag: v243.7, systemd-stable/v243-stable) Revert "Support Plugable UD-PRO8 dock"
1a5428c2ab hibernate-resume-generator: wait "infinitely" for the resume device
eb3148c468 (tag: v243.6) hwdb: update to v245-rc1
f14fa558ae Fix typo in function name
fb21e13e8e polkit: when authorizing via PK let's re-resolve callback/userdata instead of caching it
2e504c92d1 sd-bus: introduce API for re-enqueuing incoming messages
4d80c8f158 polkit: use structured initialization
54791aff01 polkit: on async pk requests, re-validate action/details
81532beddc polkit: reuse some common bus message appending code
4441844d58 bus-polkit: rename return error parameter to ret_error
31a1d569db shared: split out polkit stuff from bus-util.c → bus-polkit.c
560eb5babf test: adapt to the new capsh format
275b266bde meson: update efi path detection to gnu-efi-3.0.11
9239154545 presets: "disable" all passive targets by default
a827c41851 shared/sysctl-util: normalize repeated slashes or dots to a single value
fb1bfd6804 dhcp6: do not use T1 and T2 longer than one provided by the lease
ca43a515c6 network: fix implicit type conversion warning by GCC-10
421eca7edf bootspec: parse random-seed-mode line in loader.conf
34e21fc6de sd-boot: fix typo
df7b3a05c9 test: Synchronize journal before reading from it
9326efee71 sd-bus: fix introspection bug in signal parameter names
7bbdc56aaf efi: fix build.
486f8ca365 generator: order growfs for the root fs after systemd-remount-fs
56d442e29d loginctl: use /org/freedesktop/login1/session/auto when "lock-session" is called without argument
6ed1152282 Documentation update for x-systemd.{before,after}
dba3efa34a man: fix typo in systemd.netdev Xfrm example
6f9a8621d8 timesyncd: log louder when we refuse a server due to root distance
0637255d3b resolved: drop DNSSEC root key that is not valid anymore
9a135baa40 journal: don't use startswith() on something that is not a NUL-terminated string
1ff3972a0f test: add test for https://github.com/systemd/systemd/issues/14560
cac79b606b core: make sure StandardInput=file: doesn't get dup'ed to stdout/stderr by default
906ba9a67d pkgconf: add full generator paths
01b93e2c68 tree-wide: we forgot to destroy some bus errors
5c9455657e mount: make checks on perpetual mount units more lax
28c58beca1 core: never allow perpetual units to be masked
d3b044b3e7 typo: "May modify to" -> "May modify"
fd378d3d3c sysctl: downgrade message when we have no permission
db4fbf5c61 Clarify journald.conf MaxLevelStore documentation
c8365f71c0 logind: refuse overriding idle hint on tty sessions
cd91f567b6 cgroup: update only siblings that got realized once
c672dcd212 mount: mark an existing "mounting" unit from /proc/self/mountinfo as "just_mounted"
a592a40564 journalctl: Correctly handle combination of --reverse and --lines (fixes#1596)
0aa144ab1d journalctl: Correctly handle --show-cursor in combination with --until or --since and --reverse
3b803a5e66 core: fix re-realization of cgroup siblings
7549dd40fc core: propagate service state to socket in more load states
af6df343b2 man: describe "symlink" and "systemctl link" explicitly in UNIT FILE LOAD PATH
a3c1ce25a7 core: be more restrictive on the dependency types we allow to be created transiently
2b9ec8384c udev: don't import parent ID_FS_ data on partitions
ecd95c507c man: fix option name
0d4f06156b Support Plugable UD-PRO8 dock
7fba869abd gpt-auto: don't assume XBOOTLDR is vfat
494c281b67 man: fix documentation of IBM VIO device naming
7271fb056a man: slightly extend documentation on difference between ID_NET_NAME_ONBOARD and ID_NET_LABEL_ONBOARD
852ae28e68 boot: fix osrel parser
2613200370 udev: do not use exact match of file permission
46477397c1 network: lower the log-level of harmless message
7163b1fe86 hwdb: ignore keys added in kernel 5.5
92f90837dc systemctl: skip non-existent units in the 'cat' verb
a67227cc99 systemd.exec: document the file system for EnvironmentFile paths
cfb4c0aca5 systemd-analyze: fixed typo in documentation
017fddd998 test-condition: fix group check condition
9d5e3cb774 umount: show correct error message
252f1a5277 Revert "Drop dbus activation stub service"
20bbfac95e man: add section about user manager units
c93ef60212 man: add remote-*.targets to the bootup sequence
55e0f99689 time-util: also use 32bit hack on EOVERFLOW
7afe2ecb02 [man] note which UID ranges will get user journals
a43b67a4c9 [man] fix URL
dedb26a8d6 analyze: badness if neither of RootImage and RootDirectory exists
714c93862a initrd: make udev cleanup service confict trigger and settle too
8932407ae1 man: we support growing xfs too these days
19af11dc07 time-util: deal with systems where userspace has 64bit time_t but kernel does not
c90229d81d [import] fix stdin/stdout pipe behavior in import/export tar/raw
39910328da cryptsetup-generator: unconfuse writing of the device timeout
fc5e6c87a4 shared/install: log syntax error for invalid DefaultInstance=
409c94a407 shared/install: provide a nicer error message for invalid WantedBy=/Required= values
70e8c1978a seccomp: real syscall numbers are >= 0
a0a1977d9a seccomp: more comprehensive protection against libseccomp's __NR_xyz namespace invasion
7f936c60d5 network: set ipv6 mtu after link-up or device mtu change
b59d88cc62 man: fix typo in net-naming-scheme man page
c5e5ac0958 man: fix typos (#14304)
9a2f26564d ipv4ll: do not reset conflict counter on restart
bc9e1ebfdd Fix typo (duplicate "or")
c6cb71b7e7 network: if /sys is rw, then udev should be around
67dcdfd956 nspawn: do not fail if udev is not running
a7938a1bc6 Create parent directories when creating systemd-private subdirs
53aa44f873 network: do not return error but return UINT64_MAX if speed meter is disabled
65abf12674 core: swap priority can be negative
b1cf452ff5 systemctl: enhance message about kexec missing kernel
07a0e5b425 man: use mkswap@ instead of makeswap@
57dc017c6b journald: don't ask for the machine ID if we don't need it
ac392a57c0 journalctl: pager_close() calls fflush(stdout) anyway as first thing
ee7dfadc82 journald: remove unused field
471073f1b5 journalctl: return EOPNOTSUPP if pcre is not enabled
002ededb61 man: drop reference to machined, add one for journald instead
fd3bd4be3b pid1: make TimeoutAbortSec settable for transient units
eb2ef4d664 pid1: fix setting of DefaultTimeoutAbortSec
1d75e29b23 shared/ask-password-api: modify keyctl break value
a16b1ee7e5 cryptsetup: reduce the chance that we will be OOM killed
4836fb010a core: write out correct field name when creating transient service units
3e2c547f6d udevd: don't use monitor after manager_exit()
d42f7d45a8 Revert "udevd: fix crash when workers time out after exit is signal caught"
c9a287eee8 man/systemd.link: Add missing verb *be*
a67a3ae04b man: document all pager variables for systemctl and systemd
3a8fce3f38 core.timer: fix "systemd-analyze dump" and docs syntax inconsistencies wrt OnTimezoneChange=
fdffd284b6 core/service: downgrade "scheduling restart" message to debug
733e7f19d3 travis: add missing closing quote sign
0d7b7817fc systemd-tmpfiles: don't install timer when service isn't installed either
0e7f83cd2b pam_systemd: prolong method call timeout when allocating session
(cherry picked from commit 53488b27be)
Version 1.1.11 (2020-03-08)
Compatibility notes:
When upgrading from borg 1.0.x to 1.1.x, please note:
read all the compatibility notes for 1.1.0*, starting from 1.1.0b1.
borg upgrade: you do not need to and you also should not run it.
borg might ask some security-related questions once after upgrading. You can answer them either manually or via environment variable. One known case is if you use unencrypted repositories, then it will ask about a unknown unencrypted repository one time.
your first backup with 1.1.x might be significantly slower (it might completely read, chunk, hash a lot files) - this is due to the --files-cache mode change (and happens every time you change mode). You can avoid the one-time slowdown by using the pre-1.1.0rc4-compatible mode (but that is less safe for detecting changed files than the default). See the --files-cache docs for details.
1.1.11 removes WSL autodetection (Windows 10 Subsystem for Linux). If WSL still has a problem with sync_file_range, you need to set BORG_WORKAROUNDS=basesyncfile in the borg process environment to work around the WSL issue.
Fixes:
fixed potential index corruption / data loss issue due to bug in hashindex_set, #4829 Please read and follow the more detailled notes close to the top of this document.
upgrade bundled xxhash to 0.7.3, #4891 0.7.2 is the minimum requirement for correct operations on ARMv6 in non-fixup mode, where unaligned memory accesses cause bus errors. 0.7.3 adds some speedups and libxxhash 0.7.3 even has a pkg-config file now.
upgrade bundled lz4 to 1.9.2
upgrade bundled zstd to 1.4.4
fix crash when upgrading erroneous hints file, #4922
extract:
fix KeyError for "partial" extraction, #4607
fix "partial" extract for hardlinked contentless file types, #4725
fix preloading for old (0.xx) remote servers, #4652
fix confusing output of borg extract --list --strip-components, #4934
delete: after double-force delete, warn about necessary repair, #4704
create: give invalid repo error msg if repo config not found, #4411
mount: fix FUSE mount missing st_birthtime, #4763#4767
check: do not stumble over invalid item key, #4845
info: if the archive doesn't exist, print a pretty message, #4793
SecurityManager.known(): check all files, #4614
Repository.open: use stat() to check for repo dir, #4695
Repository.check_can_create_repository: use stat() to check, #4695
fix invalid archive error message
fix optional/non-optional location arg, #4541
commit-time free space calc: ignore bad compact map entries, #4796
ignore EACCES (errno 13) when hardlinking the old config, #4730
--prefix / -P: fix processing, avoid argparse issue, #4769
New features:
enable placeholder usage in all extra archive arguments
new BORG_WORKAROUNDS mechanism, basesyncfile, #4710
recreate: support --timestamp option, #4745
support platforms without os.link (e.g. Android with Termux), #4901 if we don't have os.link, we just extract another copy instead of making a hardlink.
support linux platforms without sync_file_range (e.g. Android 7 with Termux), #4905
Other:
ignore --stats when given with --dry-run, but continue, #4373
add some ProgressIndicator msgids to code / fix docs, #4935
elaborate on "Calculating size" message
argparser: always use REPOSITORY in metavar, also use more consistent help phrasing.
check: improve error output for matching index size, see #4829
docs:
changelog: add advisory about hashindex_set bug #4829
better describe BORG_SECURITY_DIR, BORG_CACHE_DIR, #4919
infos about cache security assumptions, #4900
add FAQ describing difference between a local repo vs. repo on a server.
document how to test exclusion patterns without performing an actual backup
timestamps in the files cache are now usually ctime, #4583
fix bad reference to borg compact (does not exist in 1.1), #4660
create: borg 1.1 is not future any more
extract: document limitation "needs empty destination", #4598
how to supply a passphrase, use crypto devices, #4549
fix osxfuse github link in installation docs
add example of exclude-norecurse rule in help patterns
update macOS Brew link
add note about software for automating backups, #4581
AUTHORS: mention copyright+license for bundled msgpack
fix various code blocks in the docs, #4708
updated docs to cover use of temp directory on remote, #4545
add restore docs, #4670
add a pull backup / push restore how-to, #1552
add FAQ how to retain original paths, #4532
explain difference between --exclude and --pattern, #4118
add FAQs for SSH connection issues, #3866
improve password FAQ, #4591
reiterate that 'file cache names are absolute' in FAQ
tests:
cope with ANY error when importing pytest into borg.testsuite, #4652
fix broken test that relied on improper zlib assumptions
test_fuse: filter out selinux xattrs, #4574
travis / vagrant:
misc python versions removed / changed (due to openssl 1.1 compatibility) or added (3.7 and 3.8, for better borg compatibility testing)
binary building is on python 3.5.9 now
vagrant:
add new boxes: ubuntu 18.04 and 20.04, debian 10
update boxes: openindiana, darwin, netbsd
remove old boxes: centos 6
darwin: updated osxfuse to 3.10.4
use debian/ubuntu pip/virtualenv packages
rather use python 3.6.2 than 3.6.0, fixes coverage/sqlite3 issue
use requirements.d/development.lock.txt to avoid compat issues
travis:
darwin: backport some install code / order from master
remove deprecated keyword "sudo" from travis config
allow osx builds to fail, #4955 this is due to travis-ci frequently being so slow that the OS X builds just fail because they exceed 50 minutes and get killed by travis.
(cherry picked from commit dbff9b5479)
Simply keep up to date the cli since it is used to connect to a VPN.
(cherry picked from commit eb96574e9df3aba387c4abe902b154398271becf)
Reason: A tool to communicate with a VPN provider should be kept
up-to-date
Take the supported version of protonvpn
(cherry picked from commit b45c4d2d88)
Reason: protonvpn-cli is not supported anymore, it has been replaced by
this package
This is required to install protonvpn-cli-ng
(cherry picked from commit ebaedb0e11)
Reason: The supported version of protonvpn-cli-ng requires this
dependency
Includes multiple security fixes mentioned in
https://about.gitlab.com/releases/2020/03/04/gitlab-12-dot-8-dot-2-released/
(unfortunately, no CVE numbers as of yet)
- Directory Traversal to Arbitrary File Read
- Account Takeover Through Expired Link
- Server Side Request Forgery Through Deprecated Service
- Group Two-Factor Authentication Requirement Bypass
- Stored XSS in Merge Request Pages
- Stored XSS in Merge Request Submission Form
- Stored XSS in File View
- Stored XSS in Grafana Integration
- Contribution Analytics Exposed to Non-members
- Incorrect Access Control in Docker Registry via Deploy Tokens
- Denial of Service via Permission Checks
- Denial of Service in Design For Public Issue
- GitHub Tokens Displayed in Plaintext on Integrations Page
- Incorrect Access Control via LFS Import
- Unescaped HTML in Header
- Private Merge Request Titles Leaked via Widget
- Project Namespace Exposed via Vulnerability Feedback Endpoint
- Denial of Service Through Recursive Requests
- Project Authorization Not Being Updated
- Incorrect Permission Level For Group Invites
- Disclosure of Private Group Epic Information
- User IP Address Exposed via Badge images
- Update postgresql (GitLab Omnibus)
(cherry-picked from commit c25756f91c)
The way ruby loads gems and keeps track of their paths seems to not
always work very well when the gems are accessed through
symlinks. Ruby will then complain that the same files are loaded
multiple times; it relies on the file's full path to determine whether
the file is loaded or not.
This adds an option to simply copy all gem files into the environment
instead, which gets rid of this issue, but may instead result in major
file duplication.
(cherry-picked from commit affcf9ba1e)
This is left over from when gitlab-shell had a ruby part and a go
part. The ruby part is now gone, so let's call the go part
gitlab-shell.
(cherry-picked from commit a3b2828de3)
This avoids glibc verions mismatches in vscode terminal, as
LD_LIBRARY_PATH leaks into terminal and break with user installed
executables.
(cherry picked from commit 40d7ce7828)
Signed-off-by: Domen Kožar <domen@dev.si>
Add new maintainer to brave
(cherry picked from commit 9a4a2eb1d2)
Reason: Previous commit add jefflabonte to list of the maintainer, he
should be added to the package he tries to maintain
The build of Chromium 82 requires LLVM 10 (see 1d961a4c6d) which is
unlikely to be backported to 19.09. We could do it but since 20.03 will
be released soon it doesn't seem that important.
Release notes:
irc: fix crash when receiving a malformed message 352 (who)
irc: fix crash when a new message 005 is received with longer nick prefixes
irc: fix crash when receiving a malformed message 324 (channel mode) (CVE-2020-8955)
(cherry picked from commit 2d77fc3053)
Disables support for Javascript and PHP:
- Javascript requires an old version of v8
- PHP requires a larger number of dependencies in addition to php-embed
Changelog [1]:
New features
- core: add option weechat.look.nick_color_hash_salt to shuffle nick colors (issue #635)
- core: add different icons sizes (16x16 to 512x512) (issue #1347)
- core: add file weechat.desktop
- core: add reverse of string for screen in evaluation of expressions with "revscr:"
- core: add length of string (number of chars and on screen) in evaluation of expressions with "length:xxx" and "lengthscr:xxx"
- core: add calculation of expression in evaluation of expressions with "calc:xxx" (issue #997)
- core: add optional default path (evaluated) in completion "filename"
- core: add support of modifiers in evaluation of expressions with "modifier:name,data,string"
- api: add modifier "color_encode_ansi" (issue #528)
- api: add modifier "eval_path_home"
- irc: add filters on raw buffer (issue #1000)
- irc: add option irc.look.display_pv_warning_address to display a warning in private buffer if the remote nick address has changed (issue #892)
- irc: add server option "ssl_password" (issue #115, issue #1416)
- irc: add "user" in output of irc_message_parse (issue #136)
- irc: add options irc.color.message_kick and irc.color.reason_kick (issue #683, issue #684)
- logger: add option logger.file.color_lines (issue #528, issue #621)
- script: add options "-ol" and "-il" in command "/script list" to send translated string with list of scripts loaded, display "No scripts loaded" if no scripts are loaded
- xfer: add option xfer.file.download_temporary_suffix with default value ".part" (issue #1237)
Bug fixes
- core: set buffer name, short name and title only if the value has changed
- core: fix scrolling up in bare mode when switched to bare mode at the top of the buffer (issue #899, issue #978)
- core: optimize load of configuration files
- core: fix window separators not respecting window splits (issue #630)
- core: fix cursor mode info when prefix_align is none and with words split across lines (issue #610, issue #617, issue #619)
- core: add support of reverse video in ANSI color codes
- core: fixed segfault during excessive evaluation in function string_repeat (issue #1400)
- buflist: fix extra spaces between buffers when conditions are used to hide buffers (regression introduced in version 2.6) (issue #1403)
- irc: do not automatically open a channel with name "0" (issue #1429)
- irc: remove option irc.network.channel_encode, add server option "charset_message" to control which part of the IRC message is decoded/encoded to the target charset (issue #832)
- irc: use path from option xfer.file.upload_path to complete filename in command "/dcc send" (issue #60)
- logger: fix write in log file if it has been deleted or renamed (issue #123)
- python: send "bytes" instead of "str" to callbacks in Python 3 when the string is not UTF-8 valid (issue #1389)
- relay: send message "_buffer_title_changed" to clients only when the title is changed
- xfer: fix memory leak when a xfer is freed and when the plugin is unloaded
Tests
- unit: add tests on GUI color functions
Build
- core: fix build on Haiku (issue #1420)
- core: fix build on Alpine
- core: remove file FindTCL.cmake
- core: display an error on missing dependency in CMake (issue #916, issue #956)
- debian: disable Javascript plugin on Debian Sid and Ubuntu Eoan
- debian: build with Guile 2.2
- guile: add support of Guile 2.2, disable /guile eval (issue #1098)
- python: add detection of Python 3.8
[1] https://weechat.org/files/changelog/ChangeLog-2.7.html
(cherry picked from commit d1cb8bfc8d)
Note that we need to build from a tarball now to get the vendored
crates. A bit ugly to fetch tarballs from Hydra...
(cherry picked from commit dd7f6b0c6b)
We want to disable `PLUGIN_AUTH_PAM` when building:
1. `mariadb` on macOS.
2. `mariadb-client` on any platform
Unfortunately, the interaction of these two commits
6c97b0486c7e43b4d0ae
created a situation where we disable it *twice* when building on macOS.
Once in a darwin-specific `prePatch` script, and again in the `patches`
section for client builds.
This removes the redundant `prePatch` script and conditionally applies
the patch to `mariadb` server builds on darwin.
Fixes#70835
(cherry picked from commit b0b0bb7e0b)
As of a few days ago hydra has a different GC configuration that leads
to eval failures when the tested job has a direct dependency on all the
tests. This is an attempt at migrating the old list of jobs to the new
format while keeping the logic and the tests the same.
As of a few days ago hydra has a different GC configuration that leads
to eval failures when the tested job has a direct dependency on all the
tests. This is an attempt at migrating the old list of jobs to the new
format while keeping the logic and the tests the same.
start_kdeinit reads its environment over a pipe from start_kdeinit_wrapper. For
security, each environment entry must be smaller than 4kb by default. Qt-based
applications in Nixpkgs may have larger environments, and the recent upgrade to
Plasma 5.17 pushed start_kdeinit_wrapper over the limit. The limit is now
extended to 16kb.
This problem was not detected during testing because the failure is silent:
start_kdeinit will continue with an empty environment. In other circumstances,
this strategy might work, but it does not work on NixOS. This failure is now
treated as a fatal error.
Fixes: #79707
(cherry picked from commit c75860918f)
This avoids using NIX_CFLAGS_COMPILE by switching to hardeningDisable.
The hack is also only needed for darwin sources and is not specific to
clang.
Co-authored-by: Dmitry Kalinkin <dmitry.kalinkin@gmail.com>
(cherry picked from commit 5ef4af7afc)
cc #79794
See 3fadc45499. Since the beta channel is now also on 81 and the stable
channel will be on 81 soon, it makes sense to already add this
unconditionally for all channels.
(cherry picked from commit 67f349d224)
I don't really have the hardware resources nor time to do this properly,
but I'll try to keep a watch on Chromium (updates, PRs, and issues)
until we've found a new team [0].
Testing will be performed on a best effort basis (no guarantees :o).
I've also briefly documented the current maintainer
roles/responsibilities and added `meta.longDescription`.
[0]: https://github.com/NixOS/nixpkgs/issues/78450
(cherry picked from commit 4ad78e64ff)
This also includes b29e3582ac.
See http://aspell.net/aspell-0.60.8.txt for release information.
(#71242)
The fix for CVE-2019-20433 may break compatibility for some
applications, hence a version bump instead of adding a patch.
Also: backport of 648678f6e1
I can't say I really understand that much about our cross stuff,
but this seems very clear.
(cherry picked from commit 79210713e6)
Let's fix the online manual immediately.
Prepend the nix path to the zoneinfo.zip file and keep the original alternatives
to allow go programs built using nix to run on non nix servers.
see https://github.com/NixOS/nixpkgs/issues/54603
(cherry picked from commit 5a0be78562)
My build server which isn't using cache.nixos.org discovered an
outdated hash in servant:
```
trying https://github.com/haskell-servant/servant/archive/v0.16.2.tar.gz
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 132 0 132 0 0 616 0 --:--:-- --:--:-- --:--:-- 616
100 295k 0 295k 0 0 269k 0 --:--:-- 0:00:01 --:--:-- 384k
unpacking source archive /build/v0.16.2.tar.gz
hash mismatch in fixed-output derivation '/nix/store/i6qgxlqf599wl11rd44jasgmwb78wr6c-source':
wanted: sha256:0kqglih3rv12nmkzxvalhfaaafk4b2irvv9x5xmc48i1ns71y23l
got: sha256:0xk3czk3jhqjxhy0g8r2248m8yxgvmqhgn955k92z0h7p02lfs89
```
(cherry picked from commit 1cbb793ec8)
Otherwise, qarte fails at run-time with:
> from PyQt5.QtMultimedia import QMediaPlayer
> ModuleNotFoundError: No module named 'PyQt5.QtMultimedia'
(cherry picked from commit ef15478313)
The rebuilds happen because changing the end-part of URL
changes the name of the resulting file as placed into nix store
(those names were wrong/confusing before this change)
(cherry picked from commit 31ab6fdec5)
Fixes this error:
qt.qpa.plugin: Could not find the Qt platform plugin "xcb" in ""
This application failed to start because no Qt platform plugin could
be initialized. Reinstalling the application may fix this problem.
Aborted (core dumped)
Also, remove the unnecessary build input `gitFull`, and enable
parallel building.
Signed-off-by: Anders Kaseorg <andersk@mit.edu>
(cherry picked from commit 1bcb6fb027)
When a new version of the Citrix workspace app is released, there's no
versioned URL available. This means that as soon as a new version is
released, the homepage needs to be altered to ensure that the error
message from `requireFile` points to the proper download URL.
(cherry picked from commit 518b5ef0c9)
Fixes#76973
This moves the path configuration to a separate derivation and skips
an impure test that depends on the current year.
(cherry picked from commit 4b102f0f07)
cc #78552
Conflicts:
pkgs/development/compilers/ldc/default.nix
The skia patch no longer applies, and is no longer necessary.
The current version of chromium doesn't build with gcc. This has been
fixed upstream[1] and could be backported, but switching aarch64 to
clang/llvm and making the build the same on all platforms is simpler.
[1] 9662ec8440
(cherry picked from commit 6ec5e745dc)
Most prominently we don't use `phases` because of https://github.com/NixOS/nixpkgs/issues/28910.
This is also problematic when using wrapGAppsHook.
In order to use wrapGAppsHook's automatic wrapping
(this was done manually before because there was no fixupPhase)
we need to install signal at lib/Signal instead of just into libexec.
That's because it would try to wrap .so files.
(cherry picked from commit 15e0b23f48)
We have to specify if we're building CE or EE otherwise at least some JS
building was broken, resulting in e.g. broken "boards" pages.
(cherry picked from commit 6bf0ed8e02)
From https://github.com/zsh-users/zsh-syntax-highlighting#faq:
"It must be sourced after all custom widgets have been created
(i.e., after all zle -N calls and after running compinit)."
zsh-syntax-highlighting must be sourced to the end.
(cherry picked from commit 35ae47e44b)
Rename the old ceph test to ceph-single-node and add a new test
ceph-multi-node. The ceph-single-node represents a dev cluster whereas
ceph-multi-node is closer to a prod cluster.
(cherry picked from commit 916520151e)
correct platforms. ceph currently doesn't build on aarch64-linux. So
let's not lie in meta.platforms.
ceph: fix multiple output
We currently just move $out/share/ceph/mgr to
$lib/lib/ceph, and then remove all references to $out with a find
command.
I checked $out, the only reference to $out is in
$lib/lib/ceph/libceph-common.so.0, coming from src/common/options.cc:
https://github.com/ceph/ceph/blob/master/src/common/options.cc#L5050:
> Option("mgr_module_path", Option::TYPE_STR, Option::LEVEL_ADVANCED)
> .set_default(CEPH_DATADIR "/mgr")
> .add_service("mgr")
> .set_description("Filesystem path to manager modules."),
Just removing the reference might break some behaviour - it should point
to $lib/ceph/mgr instead.
We can fix this in a much more elegant fashion by just passing a custom
CMAKE_INSTALL_DATADIR to the build system.
ceph: fix outdated Boost::python substitutions
Instead of substituting in CMakeLists.txt files, one now needs to set
MGR_PYTHON_VERSION.
ceph: clean up PYTHONPATH wrapping
Set `pythonPath` instead of exporting PYTHONPATH.
Use `toPythonPath` to construct the PYTHONPATH where we need manual
wrapping. There's no ceph-volume, only ceph-mgr.
ceph: set doCheck = false explicitly
and describe why.
ceph: patch more shebangs
ceph: use system-provided gtest and rocksdb
(cherry picked from commit 05590b3efd)
This is required for programs using rocksdb and and typeinfo.
Otherwise, linking them fails with errors like this (that's ceph):
/nix/store/cg0k49h66nkdqx6ccwnqr0i4q0fnfznc-binutils-2.31.1/bin/ld: ../../lib/libos.a(RocksDBStore.cc.o):(.data.rel.ro._ZTIN12RocksDBStore14RocksWBHandlerE[_ZTIN12RocksDBStore14RocksWBHandlerE]+0x10): undefined reference to `typeinfo for rocksdb::WriteBatch::Handler'
/nix/store/cg0k49h66nkdqx6ccwnqr0i4q0fnfznc-binutils-2.31.1/bin/ld: ../../lib/libos.a(RocksDBStore.cc.o):(.data.rel.ro._ZTIN12RocksDBStore19MergeOperatorRouterE[_ZTIN12RocksDBStore19MergeOperatorRouterE]+0x10): undefined reference to `typeinfo for rocksdb::AssociativeMergeOperator'
/nix/store/cg0k49h66nkdqx6ccwnqr0i4q0fnfznc-binutils-2.31.1/bin/ld: ../../lib/libos.a(RocksDBStore.cc.o):(.data.rel.ro._ZTIN12RocksDBStore19MergeOperatorLinkerE[_ZTIN12RocksDBStore19MergeOperatorLinkerE]+0x10): undefined reference to `typeinfo for rocksdb::AssociativeMergeOperator'
/nix/store/cg0k49h66nkdqx6ccwnqr0i4q0fnfznc-binutils-2.31.1/bin/ld: ../../lib/libos.a(RocksDBStore.cc.o):(.data.rel.ro._ZTI17CephRocksdbLogger[_ZTI17CephRocksdbLogger]+0x10): undefined reference to `typeinfo for rocksdb::Logger'
/nix/store/cg0k49h66nkdqx6ccwnqr0i4q0fnfznc-binutils-2.31.1/bin/ld: ../../lib/libos.a(BlueRocksEnv.cc.o):(.data.rel.ro._ZTI12BlueRocksEnv[_ZTI12BlueRocksEnv]+0x10): undefined reference to `typeinfo for rocksdb::EnvWrapper'
/nix/store/cg0k49h66nkdqx6ccwnqr0i4q0fnfznc-binutils-2.31.1/bin/ld: ../../lib/libos.a(BlueRocksEnv.cc.o):(.data.rel.ro._ZTI23BlueRocksSequentialFile[_ZTI23BlueRocksSequentialFile]+0x10): undefined reference to `typeinfo for rocksdb::SequentialFile'
/nix/store/cg0k49h66nkdqx6ccwnqr0i4q0fnfznc-binutils-2.31.1/bin/ld: ../../lib/libos.a(BlueRocksEnv.cc.o):(.data.rel.ro._ZTI25BlueRocksRandomAccessFile[_ZTI25BlueRocksRandomAccessFile]+0x10): undefined reference to `typeinfo for rocksdb::RandomAccessFile'
/nix/store/cg0k49h66nkdqx6ccwnqr0i4q0fnfznc-binutils-2.31.1/bin/ld: ../../lib/libos.a(BlueRocksEnv.cc.o):(.data.rel.ro._ZTI21BlueRocksWritableFile[_ZTI21BlueRocksWritableFile]+0x10): undefined reference to `typeinfo for rocksdb::WritableFile'
/nix/store/cg0k49h66nkdqx6ccwnqr0i4q0fnfznc-binutils-2.31.1/bin/ld: ../../lib/libos.a(BlueRocksEnv.cc.o):(.data.rel.ro._ZTI17BlueRocksFileLock[_ZTI17BlueRocksFileLock]+0x10): undefined reference to `typeinfo for rocksdb::FileLock'
(cherry picked from commit 781d85c69a)
Using a function in an if condition when set -e is set doesn't seem to
break out or return false which means the workaround from 41ca86129f
never gets triggered.
(cherry picked from commit d5d8b3514d)
These enable some power management settings. They are needed for [s-tui
to show power readings](https://github.com/amanusk/s-tui/issues/105).
The values chosen here match what Arch Linux has. In particular
the Intel specific code is loadable as a module rather than compiled in.
(cherry picked from commit 299e6f07d2)
They both base on firefox versions where support has ended some time
ago. With CVE-2019-17026 (and other vulnerabilities) out and exploited
in the wild, these should not be used anymore. tor-browser-bundle-bin is
a better alternative.
We should wait until after `multi-user.target` is triggered to allow
hardware to finish initializing, such as network devices and USB drives.
This ensures `powertop --auto-tune` sets more tunables to "Good".
Fixes#66820
Previously when this function was called without a value coercible to a
string it would throw an error instead of returning false. Now it does.
As a result this now allows the use of a type like `either path attrs`
without it erroring out when a definition is an attribute set.
The warning about there not being a isPath primop was removed because
this is not the case anymore, there is builtins.isPath. But also there
always was `builtins.typeOf x == "path"` that could've been used
instead. However the path type now stands for more than just path types,
but absolute paths in general.
(cherry picked from commit d7a109b59f)
See https://github.com/NixOS/nixpkgs/pull/76861#issuecomment-571643864
for why this is cherry-picked
Traceback (most recent call last):
File "/nix/store/8qkdlyv2ckrimvi50qvl0anzv66jcp2j-python-swiftclient-3.6.0/bin/.swift-wrapped", line 7, in <module>
from swiftclient.shell import main
File "/nix/store/8qkdlyv2ckrimvi50qvl0anzv66jcp2j-python-swiftclient-3.6.0/lib/python3.7/site-packages/swiftclient/__init__.py", line 20, in <module>
from .client import * # noqa
File "/nix/store/8qkdlyv2ckrimvi50qvl0anzv66jcp2j-python-swiftclient-3.6.0/lib/python3.7/site-packages/swiftclient/client.py", line 33, in <module>
from swiftclient import version as swiftclient_version
File "/nix/store/8qkdlyv2ckrimvi50qvl0anzv66jcp2j-python-swiftclient-3.6.0/lib/python3.7/site-packages/swiftclient/version.py", line 15, in <module>
import pkg_resources
ModuleNotFoundError: No module named 'pkg_resources'
(cherry picked from commit dfd115a116)
Airwave itself is free software, but the VST SDK it depends on is not.
This means that trying to build airwave fails with an error about
manually adding VST SDK to the store, rather than the expected error
that non-free software has been requested.
(cherry picked from commit dfc27a8430)
GitLab Shell now has the go.mod and go.sum files in the root of the
repo; the go subdirectory has been removed and all the code in it has
been moved up to the root.
(cherry picked from commit a3c72e66a6)
For some reason this untagged commit is the one referred to in the
main repository; this might be a mistake, but we'll have to package it
for now to follow upstream.
(cherry picked from commit 445bc1494c)
This is what I've suspected a while ago[1]:
> Heads-up everyone: After testing this in a few production instances,
> it seems that some browsers still get cache hits for new store paths
> (and changed contents) for some reason. I highly suspect that it might
> be due to the last-modified header (as mentioned in [2]).
>
> Going to test this with last-modified disabled for a little while and
> if this is the case I think we should improve that patch by disabling
> last-modified if serving from a store path.
Much earlier[2] when I reviewed the patch, I wrote this:
> Other than that, it looks good to me.
>
> However, I'm not sure what we should do with Last-Modified header.
> From RFC 2616, section 13.3.4:
>
> - If both an entity tag and a Last-Modified value have been
> provided by the origin server, SHOULD use both validators in
> cache-conditional requests. This allows both HTTP/1.0 and
> HTTP/1.1 caches to respond appropriately.
>
> I'm a bit nervous about the SHOULD here, as user agents in the wild
> could possibly just use Last-Modified and use the cached content
> instead.
Unfortunately, I didn't pursue this any further back then because
@pbogdan noted[3] the following:
> Hmm, could they (assuming they are conforming):
>
> * If an entity tag has been provided by the origin server, MUST
> use that entity tag in any cache-conditional request (using If-
> Match or If-None-Match).
Since running with this patch in some deployments, I found that both
Firefox and Chrome/Chromium do NOT re-validate against the ETag if the
Last-Modified header is still the same.
So I wrote a small NixOS VM test with Geckodriver to have a test case
which is closer to the real world and I indeed was able to reproduce
this.
Whether this is actually a bug in Chrome or Firefox is an entirely
different issue and even IF it is the fault of the browsers and it is
fixed at some point, we'd still need to handle this for older browser
versions.
Apart from clearing the header, I also recreated the patch by using a
plain "git diff" with a small description on top. This should make it
easier for future authors to work on that patch.
[1]: https://github.com/NixOS/nixpkgs/pull/48337#issuecomment-495072764
[2]: https://github.com/NixOS/nixpkgs/pull/48337#issuecomment-451644084
[3]: https://github.com/NixOS/nixpkgs/pull/48337#issuecomment-451646135
Signed-off-by: aszlig <aszlig@nix.build>
(cherry picked from commit ccf55bead1)
Reason: The issue breaks setups that serve static content via Nix store
paths. I've also backported the NixOS VM test from Python to
Perl.
Rationale for this backport: not entirely sure why this starts to fail
now, but this change fixes the build on 19.09: https://hydra.nixos.org/build/109120376
(cherry picked from commit 5cc8fdb5d7)
services.pppd.peers was lacking a description, causing a trace warning
resulting in a parse error in the metrics job.
(cherry picked from commit 0256080d11)
In fact, don't create them at all because Nix does that automatically.
Also remove modules/programs/shell.nix because everything it did is
now done automatically by Nix.
(cherry picked from commit 4e0d6a5ff8)
- need --disable-native-tests not --disable-native-macro
- --with-systemwide is better than -DJOHN_SYSTEMWIDE=1
Fixes#74918
(cherry picked from commit 73cf5d961b)
In cases where you boot up really quickly (like in the VM test on a
non-busy host), tinydns might want to bind before the loopback interface
is fully up. Order tinydns after network.target to fix that.
(cherry picked from commit cbd9e9e01f)
In normal use of ROOT the PYTHONPATH is intended to be set when user
sources the thisroot.{,s}sh. We do that in the setupHook. This covers
the case when thisroot.sh was not sourced.
(cherry picked from commit 0b28198f23)
cc #76541
This is a bit dubvious, but the alternative of making nodejs a
nativeBuildInput for node packages is worse. In general the cross story
for interpreted languages is murky, and this fits that pattern.
(cherry picked from commit 313eba4451)
Reason: Avoid an expired (unusable) release in the stable release
(Signal-Desktop releases expire after 90 days).
(cherry picked from commit 096c2b4a4b)
Reason: Avoid an expired (unusable) release in the stable release
(Signal-Desktop releases expire after 90 days).
(cherry picked from commit 8d5f5e7e3e)
Reason: Avoid an expired (unusable) release in the stable release
(Signal-Desktop releases expire after 90 days).
The original commit didn't have a comment, causing a conflict. I
removed the comment here so future backports apply cleanly.
(cherry picked from commit 987a59e295)
Update the Name attribute in the wire-desktop.desktop applications file
and add StartupWMClass key. This fixes the icons on plasma5 and gnome3
which, in certain places, showed a generic X.org icon instead of the Wire
icon.
(cherry picked from commit 4a73fbc367)
Fixes on remote content injection issue (CVE-2019-3462).
Complete changelog:
> apt (1.4.9) stretch-security; urgency=medium
>
> * SECURITY UPDATE: content injection in http method (CVE-2019-3462)
> (LP: #1812353)
>
> -- Julian Andres Klode <jak@debian.org> Fri, 18 Jan 2019 11:42:07 +0100
>
> apt (1.4.8) stretch; urgency=medium
>
> [ Balint Reczey ]
> * Gracefully terminate process when stopping apt-daily-upgrade (LP: #1690980)
>
> [ David Kalnischkies ]
> * don't ask an uninit _system for supported archs, this
> crashes the mirror method (LP: #1613184)
>
> [ Julian Andres Klode ]
> * Do not warn about duplicate "legacy" targets (Closes: #839259)
> (LP: #1697120)
> * apt-daily: Pull in network-online.target in service, not timer
> - this can cause a severe boot performance regression / hang
> (LP: #1716973)
>
> -- Julian Andres Klode <jak@debian.org> Wed, 13 Sep 2017 18:47:33 +0200
>
> apt (1.4.7) stretch; urgency=medium
>
> * New release with important fixes up to 1.5~beta1; also see LP: #1702326
>
> [ Robert Luberda ]
> * fix a "critical" typo in old changelog entry (Closes: 866358)
>
> [ David Kalnischkies ]
> * test suite/travis CI: ignore profiling warning in progress lines
> * use port from SRV record instead of initial port
>
> [ Julian Andres Klode ]
> * Reset failure reason when connection was successful, so later errors are
> reported as such and not as "connection failure" warnings.
> * debian/gbp.conf: Set debian-branch to 1.4.y
> * http: A response with Content-Length: 0 has no content, so don't try to
> read it - it will either timeout or the server closes the connection.
> * travis CI: Migrate to Docker
>
> -- Julian Andres Klode <jak@debian.org> Thu, 13 Jul 2017 23:45:39 +0200
This addresses the following security issues:
* CVE-2019-14846 - Several Ansible plugins could disclose aws
credentials in log files. inventory/aws_ec2.py, inventory/aws_rds.py,
lookup/aws_account_attribute.py, and lookup/aws_secret.py,
lookup/aws_ssm.py use the boto3 library from the Ansible process. The
boto3 library logs credentials at log level DEBUG. If Ansible's
logging was enabled (by setting LOG_PATH to a value) Ansible would set
the global log level to DEBUG. This was inherited by boto and would
then log boto credentials to the file specified by LOG_PATH. This did
not affect aws ansible modules as those are executed in a separate
process. This has been fixed by switching to log level INFO
* Convert CLI provided passwords to text initially, to prevent unsafe
context being lost when converting from bytes->text during post
processing of PlayContext. This prevents CLI provided passwords from
being incorrectly templated (CVE-2019-14856)
* properly hide parameters marked with no_log in suboptions when
invalid parameters are passed to the module (CVE-2019-14858)
* resolves CVE-2019-10206, by avoiding templating passwords from
prompt as it is probable they have special characters.
* Handle improper variable substitution that was happening in
safe_eval, it was always meant to just do 'type enforcement' and have
Jinja2 deal with all variable interpolation. Also see CVE-2019-10156
Changelog: 9bdb89f740/changelogs/CHANGELOG-v2.6.rst
(cherry picked from commit b21b92947e)
This addresses the following security issues:
* Ansible: Splunk and Sumologic callback plugins leak sensitive data in logs (CVE-2019-14864)
* CVE-2019-14846 - Several Ansible plugins could disclose aws
credentials in log files. inventory/aws_ec2.py, inventory/aws_rds.py,
lookup/aws_account_attribute.py, and lookup/aws_secret.py,
lookup/aws_ssm.py use the boto3 library from the Ansible process. The
boto3 library logs credentials at log level DEBUG. If Ansible's
logging was enabled (by setting LOG_PATH to a value) Ansible would set
the global log level to DEBUG. This was inherited by boto and would
then log boto credentials to the file specified by LOG_PATH. This did
not affect aws ansible modules as those are executed in a separate
process. This has been fixed by switching to log level INFO
* Convert CLI provided passwords to text initially, to prevent unsafe
context being lost when converting from bytes->text during post
processing of PlayContext. This prevents CLI provided passwords from
being incorrectly templated (CVE-2019-14856)
* properly hide parameters marked with no_log in suboptions when
invalid parameters are passed to the module (CVE-2019-14858)
Changelog: 24220a618a/changelogs/CHANGELOG-v2.8.rst
(cherry picked from commit 71cde971c7)
This fixes the following security issues:
* Ansible: Splunk and Sumologic callback plugins leak sensitive data
in logs (CVE-2019-14864)
* CVE-2019-14846 - Several Ansible plugins could disclose aws
credentials in log files. inventory/aws_ec2.py, inventory/aws_rds.py,
lookup/aws_account_attribute.py, and lookup/aws_secret.py,
lookup/aws_ssm.py use the boto3 library from the Ansible process. The
boto3 library logs credentials at log level DEBUG. If Ansible's
logging was enabled (by setting LOG_PATH to a value) Ansible would set
the global log level to DEBUG. This was inherited by boto and would
then log boto credentials to the file specified by LOG_PATH. This did
not affect aws ansible modules as those are executed in a separate
process. This has been fixed by switching to log level INFO
* Convert CLI provided passwords to text initially, to prevent unsafe
context being lost when converting from bytes->text during post
processing of PlayContext. This prevents CLI provided passwords from
being incorrectly templated (CVE-2019-14856)
* properly hide parameters marked with no_log in suboptions when invalid
parameters are passed to the module (CVE-2019-14858)
* resolves CVE-2019-10206, by avoiding templating passwords from
prompt as it is probable they have special characters.
* Handle improper variable substitution that was happening in
safe_eval, it was always meant to just do 'type enforcement' and have
Jinja2 deal with all variable interpolation. Also see CVE-2019-10156
Changelog: 0623dedf2d/changelogs/CHANGELOG-v2.7.rst (v2-7-15)
(cherry picked from commit 64e2791092)
Update to latest version & updated the patch file to match with the
lastest verison.
Fixes the following security issue:
* CVE-2019-19722: Mails with group addresses in From or To fields
caused crash in push notification drivers.
(cherry picked from commit cd394340d8)
Currently, exa fails when being executed in a git repository with
symlinks pointing to a non-existing location.
This can happen quite often with garbage-collected result links, or in
bazel repositories.
A fix was PR'ed in September at https://github.com/ogham/exa/pull/584,
but upstream seems to be not responding.
Let's apply this patch until there's a release containing the fixes.
(cherry picked from commit d41dca2f5f)
This adds three lists with manylinux dependencies as well as three
packages that include all the manylinux dependencies.
(cherry picked from commit 6530535b20)
backport of #74319 without the file consistency checks.
3.12 was rated a major security update but was broken for NixOS, therefore jump to 3.13 which incorporates the necessary fix.
https://about.gitlab.com/blog/2019/12/10/critical-security-release-gitlab-12-5-4-released/
Insufficient parameter sanitization for Maven package registry could lead to privilege escalation and remote code execution vulnerabilities under certain conditions. The issue is now mitigated in the latest release and is assigned CVE-2019-19628.
When transferring a public project to a private group, private code would be disclosed via the Group Search API provided by Elasticsearch integration. The issue is now mitigated in the latest release and is assigned CVE-2019-19629.
The Git dependency has been upgraded to 2.22.2 in order to apply security fixes detailed here.
CVE-2019-19604 was identified by the GitLab Security Research team. For more information on that issue, please visit the GitLab Security Research Advisory
closes#75506.
(cherry picked from commit 5bf07d665f)
+ Fixing interrupted descriptions
+ Added more verbose descriptions
+ Addded <literal> to the descriptions
+ uniformly reformated descriptions to break at 80 chars
kitty has its own heavily modified fork of GLFW embedded in the source code. Therefore it doesn't need GLFW as an external dependency.
(cherry picked from commit 079d57fa20)
depmod looks for files modules.order and modules.builtin which are
generated at kernel build time but were previously not passed to
the modules-shrunk derivation
Fixes this error:
gnuplot> plot [-5:5] sin(x)
qt.qpa.plugin: Could not find the Qt platform plugin "xcb" in ""
This application failed to start because no Qt platform plugin could
be initialized. Reinstalling the application may fix this problem.
Signed-off-by: Anders Kaseorg <andersk@mit.edu>
(cherry picked from commit c55f48477a)
`RequiredForOnline` allows for a boolean value or operational state.
This adds the values for all valid the operational states.
(cherry picked from commit 0aeaf4dfe0)
This has been there since v209 [1]
```
The interface name to use. This option has lower precedence than NamePolicy=, so for this setting to take effect, NamePolicy= must either be unset, empty, disabled, or all policies configured there must fail. Also see the example below with "Name=dmz0".
Note that specifying a name that the kernel might use for another interface (for example "eth0") is dangerous because the name assignment done by udev will race with the assignment done by the kernel, and only one interface may use the name. Depending on the order of operations, either udev or the kernel will win, making the naming unpredictable. It is best to use some different prefix, for example "internal0"/"external0" or "lan0"/"lan1"/"lan3".
```
[1] 43b3a5ef61
(cherry picked from commit 943508a7fa)
(cherry picked from commit 8f56c19778)
Reason: Avoid an expired (unusable) release in the stable release
(Signal-Desktop releases expire after 90 days).
The irony-server binary package tracks the irony-server elisp package, which was
upgraded to 1.4.0. This is now failing on Hydra because upstream has refactored
the CMake build, and now require CMake files from LLVM.
(cherry picked from commit 33e0ffebc1)
19.09 has the same problem
Due to the recent update of python 2.7 from 2.7.16 to 2.7.17
(see 05dfc50639) the
`StaticTest::test_null_bytes` test case started failing on 2.7
too.
This is because additional validation has been backported to
httplib in PR 13315 in https://github.com/python/cpython to
to address a security issue.
Before, we'd always use `cc = null`, and check for that. The problem is
this breaks for cross compilation to platforms that don't support a C
compiler.
It's a very subtle issue. One might think there is no problem because we
have `stdenvNoCC`, and presumably one would only build derivations that
use that. The problem is that one still wants to use tools at build-time
that are themselves built with a C compiler, and those are gotten via
"splicing". The runtime version of those deps will explode, but the
build time / `buildPackages` versions of those deps will be fine, and
splicing attempts to work this by using `builtins.tryEval` to filter out
any broken "higher priority" packages (runtime is the default and
highest priority) so that both `foo` and `foo.nativeDrv` works.
However, `tryEval` only catches certain evaluation failures (e.g.
exceptions), and not arbitrary failures (such as `cc.attr` when `cc` is
null). This means `tryEval` fails to let us use our build time deps, and
everything comes apart.
The right solution is, as usually, to get rid of splicing. Or, baring
that, to make it so `foo` never works and one has to explicitly do
`foo.*`. But that is a much larger change, and certaily one unsuitable
to be backported to stable.
Given that, we instead make an exception-throwing `cc` attribute, and
create a `hasCC` attribute for those derivations which wish to
condtionally use a C compiler: instead of doing `stdenv.cc or null ==
null` or something similar, one does `stdenv.hasCC`. This allows quering
without "tripping" the exception, while also allowing `tryEval` to work.
No platform without a C compiler is yet wired up by default. That will
be done in a following commit.
- Switched to pname
- Fixed the double dash in pname
- Changed license to unfree (they don't allow redistribution)
Fixes#73956
Backport of #73963
(cherry picked from commit 576a82d6c2)
This package broke during the update of `nodejs-10_x` to `v10.17.0`[1]
since `node-gyp` got updated from `3.8.0` to `5.0.3` during the NPM
update to `6.10.2`[2] which is bundled in the `nodejs` release tarball.
This `node-gyp`-version is used by the build script for `codimd` to
build several dependencies such as `node-sqlite3`. Older `node-gyp`
versions expected source headers for the compilation in `~/.node-gyp`,
with `node-gyp@5.0.3`, headers are declared by using the `--nodedir`
option.
[1] 7785f49b23
[2] e2291cf805
(cherry picked from commit ba307dd176)
* add patch for CVE-2017-8372 and CVE-2017-8373
* add patch for CVE-2017-8374
* add patch for x86_64 platforms
* fetch existing patches from remote sources
Backport of #73234
(cherry picked from commit 92edb06109)
Based on testing this issue seems to only occur with clang_7, so
we should be able to revert this when the default llvm versions are
updated.
Fixes#66811
(cherry picked from commit 41ca86129f)
Instead of assign the libinput options to touchpad devices only, it
should be appied by any device using libinput.
Due to the fact that `40-libinput.conf` already defines libinput as
driver for any detected input device, we can use `MatchDriver` to appy
options.
(cherry picked from commit d6169284c4)
Adding an additional web-archive url to avoid breakage when
old versions disappear from upstream. Still keeping original location
to not needlessly hit archive.org (it's also slower).
(cherry picked from commit ad8c1703ec) and
resolved conflicts.
We were adding this to the compilation of MacVim, but not to the
compilation of the separate Vim binary. We may not actually need it for
MacVim at all, but omitting it for the Vim binary meant our postInstall
phase would fail for some people.
Fixes#73514
(cherry picked from commit 505f913ceb)
By translating NIX_CFLAGS_COMPILE to CPATH,
all tools will now find c headers properly,
when run in a nix-shell.
(cherry picked from commit a10ef1aa4f)
When the option services.vault.storageBackend is set to "file", a
systemd.tmpfiles.rules was added, with extraneous []. These are not
needed and have been removed.
(cherry picked from commit 9b78e5f35d)
The 2017.3 version of p4v is linked against `libssl.so.1.0.0`. Since
the default openssl in NixOS 2019.09 has been changed to openssl 1.1,
the p4v package must now import the openssl_1_0_2 derivation.
(cherry picked from commit 1ced63da76)
cc #71301Closes: #73456
most likely, people enabling the lorri module also want to use it,
without explicitly having to add it to users.users.<username>.packages.
cc @curiousleo @Profpatsch
(cherry picked from commit fd7d88f603)
(cherry picked from commit 7b77666eb1)
Reason: Avoid an expired (unusable) release in the stable release
(Signal-Desktop releases expire after 90 days).
(#72649)
resolving CVE-2019-14491, CVE-2019-14492 & CVE-2019-15939
most internal downloads are unchanged except for "ade" which was bumped
from v0.1.1d to v0.1.1f between these releases
(cherry picked from commit d623837d64)
After the newest update Steam itself complained about missing files
and would not start:
* libva.so.2
* libva-x11.so.2
(cherry picked from commit 5a13b856c4)
- setup_requires belong in nativeBuildInputs
- requests is only for Python 2. We offer only a Python 3 version of
pipenv
- setting PYTHONPATH is not needed because the magical sed expression
injects the dependencies in the executables. Otherwise, we would use
NIX_PYTHONPATH.
- PIP_IGNORE_INSTALLED was needed because of PYTHONPATH, but since we do
not set that anymore we can remove.
(cherry picked from commit 7f63ecfff9)
I think those deps could be made to build, but I didn't want to get
bogged down investigating further. "Use flags" are always a good thing,
so this is fine for now.
* Update trousers to latest, use regular openssl (#68338)
trousers: cleanup
* some CFLAGS and LDFLAGS are not needed anymore
* libtool file fixup was a no-op
* license is now BSD-3 since:
0160d229f8/
(cherry picked from commit 82dfacc7fe)
I've noticed a similar issue in Pantheon, without this
sound theme installed there's no system sounds.
I believe it's because the gnome theme and the pantheon
theme inherit this one.
(cherry picked from commit 4bdbbc1b33)
Hydra fails to build the assets on i686 - it runs out of memory. If we
limit the max consumption to 2048MB the assets still build, and will
hopefully also build on hydra.
(cherry picked from commit 22302ce845)
For some reason hydra seems to have issues downloading the
gitlab-workhorse source on macOS. Since we don't build the rails app
for macOS, the other components seem a bit useless there, so we
limit them to linux for now.
(cherry picked from commit a30facc96e)
CVE fix in #71695 broke this package, as it's an older
version and additionaly disables amalgamation.
The supplied patch is modified minimally to fit this version (slight
line number change for analyze.c).
The fix was verified using
https://www.sqlite.org/src/info/e4598ecbdd18bd82945f6029013296690e719a62
as for the previous fix.
addressing CVE-2019-14491, CVE-2019-14492 & CVE-2019-15939
all internal downloads are unchanged for this release
(cherry picked from commit a38ee9f002)
Derived from 997bd95b3b
(todoist: 8.1.0 -> 8.1.1). This backport is needed since Todoist changed
several parts of their API, so 7.0.17 is unusable with todoist.com.
For instance, when I do `todoist.sync()`, I get the following response:
```
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<title>410 Gone</title>
<h1>Gone</h1>
<p>This API endpoint is no longer available. Please refer to our documentation to upgrade your client to use the latest API version: https://developer.todoist.com</p>
```
Incorrect merging of modules resulted in dhcpcd being enabled causing flaky network connection.
https://github.com/NixOS/nixpkgs/pull/64364
Fixing it uncovered an infinite recursion from the same commit, previously masked by the incorrect merge.
While this is not a problem in 19.09, we can still drop the `mkDefault` for `networking.wireless.enable` as it is already `false` by default.
Closes: https://github.com/NixOS/nixpkgs/issues/72416
(cherry picked from commit 894fdfaf1f)
Addressing CVE-2019-17109
Also added missing description, homepage & license. Re-disabled for py3k
as the kojira executable doesn't seem to be happy with it.
(cherry picked from commit 605a7b31d7)
We build HandBrake with a newer ffmpeg than upstream expects,
triggering a problem where the audio samplerate defaults to zero
because HandBrake was not explicitly setting it.
This has been fixed in HandBrake upstream, but we must cherry pick
this change in order to produce videos with audio until HandBrake
1.3.0 is released.
(cherry picked from commit d51e366ffe)
Make sure that the both libqscintilla2_qt5.so and libqscintilla2.so are
present in `$out/lib` so all the dependant packages can find the most
appropriate library (some except the empty suffix, such as
sqlitebrowser, other expect the _qt5 suffix such as
python3Packages.qscintilla-qt5).
The mechanism would also work work for qt4 build, but it is broken at
the moment.
Also make sure python*Packages.qscintilla* are up to date
(cherry picked from commit 4bf49d9417)
We strip the library suffix as we don't need it and it confuses various
downstream consumers.
Also replace calls to sed with substituteInPlace as the latter will complain in
case it doesn't perform a substitution.
(cherry picked from commit 76ad2796be)
Fixes#72396.
The interface org.freedesktop.DisplayManager.AccountsService
should now exist. This also actually fixes#45059.
(cherry picked from commit feda399909)
There were no new changes in version 3.5.9; 3.5.9 was released only because of a CDN caching problem,
which resulted in some users downloading a prerelease version of the 3.5.8 .xz source tarball.
Apart from the version number, 3.5.9 is identical to the proper 3.5.8 release.
(cherry picked from commit 7827d3f449)
RMySQL was not building as `mysql_config` (which the config script
uses to determine C flags) is in pkgs.mysql.connector-c.dev but not
pkgs.mysql.connector-c
Default behavior is to continue executing the script even when one or
multiple steps fail. We want to abort early if any part of the
initialization fails to not run with a partially initialized state.
Default behavior also allows dereferencing non-existent variables,
potentially resulting in hard-to-find bugs.
(cherry picked from commit 041cbd860d)
- gitlab-shell no longer requires ruby for anything else than the
install script, so the bundlerEnv stuff could be dropped
- gitlab-shell and gitlab-workhorse now report their versions
correctly
(cherry picked from commit 5081a6cd56)
0.10.0 (2019-10-13)
* Upgrade rustsec to v0.16; new self-audit system (#155)
* Upgrade to Abscissa v0.4; MSRV 1.36 (#154)
(cherry picked from commit e2b084951c)
Upstream Pulseaudio has always stated that system-wide is not
recommended and comes with a number of usability and security drawbacks.
(cherry picked from commit 3af4f88acd)
There was a previous fix for this in
https://github.com/NixOS/nixpkgs/pull/71571
But some things, most notably pygtk, still rely on deprecated pango
APIs that are not available past 1.43, this backports the CVE
fix to this version.
(cherry picked from commit 9524bf3034)
Both options were introduced in systemd v243[1]. Those options can be
used to ensure that LinkLocalAddressing is only configured for a given
interface if DHCPv4 fails. To quote `systemd.network(5)`:
```
If "fallback" or "ipv4-fallback" is specified, then an IPv4
link-local address is configured only when DHCPv4 fails. If "fallback", an IPv6 link-local
address is always configured, and if "ipv4-fallback", the address is not configured. Note
that, the fallback mechanism works only when DHCPv4 client is enabled, that is, it requires
"DHCP=yes" or "DHCP=ipv4".
```
[1] 8bc17bb3f7
(cherry picked from commit 47724fc77c)
Backport of #72170
Related issue: #71296 (Po4a build get stuck in a loop)
Term::ReadKey is an optional dependency. From upstream:
> This module is used to retrieve the terminal's line width.
> If it is not present, the line width can be specified with the COLUMN environment variable.
Stable LibreSSL releases are supported one year after their OpenBSD release.
OpenBSD 6.4 with this branch was released on 2018-10-18.
(cherry picked from commit 671a1182e3)
The revision of the glfw fork that Rack depends on has been removed from
GitHub. This causes cloning of the glfw submodule for the Rack git
repository to fail.
As the glfw fork just adds a function that is only needed on Darwin (and
we don't support that platform at the moment) we remove the function
call from the Rack source. We can then use the upstream version of glfw.
We fetch the rest of the submodules manually as well.
See https://github.com/NixOS/nixpkgs/issues/71189 for the context.
(cherry picked from commit 0347078949)
http://www.tcpdump.org/libpcap-changes.txt
> Five CVE-2019-15161, CVE-2019-15162, CVE-2019-15163, CVE-2019-15164, CVE-2019-15165
> Fixes for CVE-2018-16301,
Drop the included patch as well.
(cherry picked from commit 4db088d36a)
* epsxe: fix link with openssl
Epsxe is hardcoded to build with openssl-1.0 (using libcrypto.so.1.0.0),
but current nixpkgs contains openssl-1.1, which provides
libcrypto.so.1.1.
This patchs just uses the previous version of the library.
* epsxe: use autoPatchelfHook instead of manual rpath overriding
This simplifies the file AND generates failures at build time if a
needed dynamic library is not found during build time.
Backport of #71920
(cherry picked from commit 4a2475c924)
Let's encrypt bumped ACME to V2. We need to update our nixos test to
be compatible with this new protocol version.
We decided to drop the Boulder ACME server in favor of the more
integration test friendly Pebble.
- overriding cacert not necessary
- this avoids rebuilding lots of packages needlessly
- nixos/tests/acme: use pebble's ca for client tests
- pebble always generates its own ca which has to be fetched
(cherry picked from commit 0c0af28cd5)
Updating:
- nixos module to use the new `account_reg.json` file.
- use nixpkgs pebble for integration tests.
Co-authored-by: Florian Klink <flokli@flokli.de>
Replace certbot-embedded pebble
(cherry picked from commit 38e84151e0)
Python 3.8 fails to build on macOS for two reasons:
* python-3.x-distutils-C++.patch fails to apply cleanly.
* An #include for <util.h> is missing, causing a build failure:
./Modules/posixmodule.c:6586:9: error: implicit declaration of function 'openpty' is invalid in C99
if (openpty(&master_fd, &slave_fd, NULL, NULL, NULL) != 0)
^
Use the correct version of python-3.x-distutils-C++.patch, and add a
patch to #include <util.h>.
(cherry picked from commit 81d15948cc)
This fixes a regression from bb649d96b0.
There were permission problems, when the preStart script tried to copy
the smokeping.fcgi file over the old file.
(cherry picked from commit 9eb067b0d7)
The default openssl version in nixpkgs is too new for eagle7 and it
fails to start:
eagle: error while loading shared libraries: libssl.so.1.0.0: cannot open shared object file: No such file or directory
(cherry picked from commit 13859d0bda)
On start, unicorn, sidekiq and other parts running ruby code emits
quite a few warnings similar to
/var/gitlab/state/config/application.rb:202: warning: already initialized constant Gitlab::Application::LOOSE_EE_APP_ASSETS
/nix/store/ysb0lgbzxp7a9y4yl8d4f9wrrzy9kafc-gitlab-ee-12.3.5/share/gitlab/config/application.rb:202: warning: previous definition of LOOSE_EE_APP_ASSETS was here
/var/gitlab/state/lib/gitlab.rb:38: warning: already initialized constant Gitlab::COM_URL
/nix/store/ysb0lgbzxp7a9y4yl8d4f9wrrzy9kafc-gitlab-ee-12.3.5/share/gitlab/lib/gitlab.rb:38: warning: previous definition of COM_URL was here
This seems to be caused by the same ruby files being evaluated
multiple times due to the paths being different - sometimes they're
loaded using the direct path and sometimes through a symlink, due to
our split between config and package data. To fix this, we make sure
that the offending files in the state directory always reference the
store path, regardless of that being the real file or a symlink.
(cherry picked from commit ed4a09c6f3)
* doc: organize chapters into parts, and reduce toc depth
Reorganize the chapters into parts and reduce the TOC depth to make the
TOC useful again. The top-level TOC is very brief, but that is fine
because every part will have its own TOC.
Section titles of languages/frameworks are also simplified to just
the name of the language/framework.
* doc: merge package notes and package-specific notes
Maybe there was an idea behind this separation, but looking at the
contents I don't see any reason for these being separate.
* doc: split packages part into xml file per package
* doc: move fetchers and trivial builders under builders
* doc: move image builders into new images chapter
* doc: move overrides into separate chapter
* doc: move fhs and mkShell under builders/special
In my opinion Functions should only contain pure functions. These are
both meant to provide derivations so I put them under Builders. Don't
know exactly *where* to put them so "special" it is...
This is a manually backported patch for a crash induced by a division by
zero. The patch had to be manually adopted to the "amalgamated" source
release.
Even though the release obviously already happened, I think it might
still make sense to add a short note about the attributes not being
supported any longer (and going forward).
perl is a run-time dependency, so it should be in buildInputs rather
than nativeBuildInputs.
This has been preventing patchShebangsAuto() in fixupOutputHooks from
patching the /usr/bin/perl interpreter shebang in $out/bin/rrsync since
61bc03c017.
Resolves#71198
(cherry picked from commit f203d50d09)
Otherwise connecting simply fails:
VPN connection: failed to connect: 'La création du fichier « /tmp/lib/NetworkManager-fortisslvpn/0507e3ef-f0e0-4153-af64-b3d9a025877c.config.XSB19Z » a échoué : No such file or directory'
- work around strictDeps issue wit python packages
- use pr 21 commit instead of debian patch to fix configparser issue
(cherry picked from commit 15953b7728)
This reverts commit 2ee14c34ed.
This caused the initializers directory to be cleaned out while gitlab
was running in some instances. We clean out the directory on the
preStart stage already, so ensuring existance and permissions should
suffice.
(cherry picked from commit 201cca9a04)
This fixes an issue with a recent addition of a config file
check in c28ded36ef.
Previously it was possible to supply a path as a string
to `configFile`. Now it will fail checking the config file
during evaluation of the module due to sandboxing.
A toggle to disable the check, more informative log messages
and handling for various configFile values are added.
(cherry picked from commit b788467ec4)
pwndbg is a Python module for gdb. The built-in interpreter is used and
pwndbg offers additional routines. Packaging this is tricky because that
interpreter needs to be used. Using `python3.withPackages` won't work.
By setting `NIX_PYTHONPATH`, the interpreter should pick up pwndbg and
its dependencies.
If `NIX_PYTHONPATH` does not function we can fall back to `PYTHONPATH`.
An example of when that won't work is if pwndbg runs a script of itself
in a subshell. `NIX_PYTHONPATH` would be unset, but `PYTHONPATH` not.
(cherry picked from commit 27a9800e85)
In our tests we have experienced failures of this test,
but it was otherwise not reproducible so far. A backported
upstream fix did not alleviate the issue either, so disabling
seems workable for now.
(cherry picked from commit cffba01e12)
We need rst2man to build manpages.
I also removed revert-create-dirs-on-install.patch, as it doesn't apply
cleanly anymore, and is purely cosmetic anyway.
(cherry picked from commit 29ba759209)
The opam patch makes ocaml link dependent executables with
-L${LLVM_OCAML_EXTERNAL_LLVM_LIBDIR}. This variable was previously
undefined and as a result the linker would previously be called with
just -L which makes it ignore the next argument. This would lead strange
linking errors, like missing caml_apply2.
Despite defining this variable correctly, propagating llvm is still
necessary for linking to complete. In case ocaml-llvm is a transitive
dependency only, propagatedBuildInputs is not enough. To avoid having to
guess which version of llvm was used, we provide the right one in
passthrough.
(cherry picked from commit 55ac8ffa43)
+ added webarchive source for reliable builds in the future
+ removed `${version}` from url, as it actually adds more hassle to
have it in there and no benefits whatsoever, since the url keeps
changing other parts too
(cherry picked from commit 4db74946ac)
+ building from gitlab source
+ reorderd dependencies to be in logical/alphabetical order
+ replaced patches with substituteInPlace, as patches broke the installChecks
and substituteInPlace may be more robust than making new patches for each
release. Also the compiled source is now closer to upstream than
before.
+ added installChecks
+ added all supported devices as listed on epson.net
(cherry picked from commit 9eb00acbbe)
(cherry picked from commit 751b661a09)
Switched to using qt5`s mkDerivation so the application is now wrapped.
Before it likely would fail with an error at runtime.
https://github.com/MindFlavor/prometheus_wireguard_exporter/releases/tag/3.2.0
Previously, the exporter used `wg show all dump` by default to retrieve
information about wireguard peers. If a wireguard config is set, the interface is
now extracted automatically and the exporter runs `wg show <interface> dump`[1].
The cargo hash didn't change as no dependency updates were done in this
release.
[1] 4e332cb73f
(cherry picked from commit d08a743156)
* pivx: 3.2.0 -> 3.2.2
* altcoins.pivx: 3.2.2 -> 3.3.0
Furthermore, this fixes 2542928
* pivx: 3.3.0 -> 3.4.0
Added `test_pivx` as test ran by nixpkgs
* Update pkgs/applications/blockchains/pivx.nix
Thanks to @lassulus for fixing this typo!
Co-Authored-By: Lassulus <github@lassul.us>
(cherry picked from commit e9cd8a2d60)
Removing debug info to fix hydra build.
The debug symbols alone are around ~1.8GB in size, which
makes the closure combined with the other two outputs
too large.
(cherry picked from commit 0ad35ab3ad)
This option was added by mistake since `listenAddress` exists by default
for each prometheus-exporter. Using
`services.prometheus.exporters.wireguard.addr` will now cause a warning,
but doesn't break eval.
(cherry picked from commit eeb4726446)
(cherry picked from commit 7818f30cc4)
Adding this kernel module seems unlikely to break stuff, and the change
will only affect those specifying hardware.steam-hardware anyway.
Shouldn't be needed for the style engine itself to work, but it is
needed for `kvantummanager` and `kvantumpreview`.
(cherry picked from commit 30360cb045)
List all modules that *may* be required depending on individual container
configurations; don't expect that further modules can be loaded after boot.
Fixes https://github.com/NixOS/nixpkgs/issues/38676
(cherry picked from commit fe3da83b7e)
Build error on i686:
> util.h:39:18: error: '__int128' is not supported on this target
typedef unsigned __int128 u128;
(cherry picked from commit a08851c925)
CVE-2019-13693 CVE-2019-13694 CVE-2019-13695 CVE-2019-13696
CVE-2019-13697
Disable jumbo mode because upstream dropped support for it.
(See chromium-dev "We're removing support for the jumbo build")
This makes builds take about 3x as long, but we have no alternative.
(cherry picked from commit f45798e544)
Rather than using autodiscovery, the checkPhase should import
`__init__.py` from `diff_match_patch.tests to execute all relevant
tests. Otherwise several python2-related tests are executed in a py3 env
and break the build.
See also: https://hydra.nixos.org/build/102482273
(cherry picked from commit b6237fb589)
gitlab:db:configure prints the root user's password to stdout on
successful setup, which means it will be logged to the
journal. Silence this informational output. Errors are printed to
stderr and will thus still be let through.
(cherry picked from commit dc29a45fc9)
(cherry picked from commit 64a247a580)
Reason: Avoid an expired (unusable) release in the stable release
(Signal-Desktop releases expire after 90 days).
Fixes
$ qsynth
qt.qpa.plugin: Could not find the Qt platform plugin "xcb" in ""
This application failed to start because no Qt platform plugin could be initialized. Reinstalling the application may fix this problem.
Aborted (core dumped)
(Also, take qt5.* attrs as input instead of the whole qt5 attrset itself.)
(cherry picked from commit 3fc66462de)
With a previous fix for log size issues due to GCC 8
a gcc specific `-W` flag was added that clang does
not know, so it spams the logs.
(cherry picked from commit 3bfe0872b9)
We removed the symlinks for the alias in
* f99bdb2b61
but we also need to move this definition into the module.
Else we get issues like #70301.
Fixes#70301.
Make sure that we don't create a database if we're not going to
connect to it. Also, fix the assertion that usernames be equal to only
trig when peer authentication is used (databaseHost == "").
(cherry picked from commit 58a7502421)
config.services.postgresql.package is only defined when the postgresql
service is activated, which means we fail to evaluate when
databaseCreateLocally == false. Fix this by using the default
postgresql package when the postgresql service is disabled.
(cherry picked from commit ec958d46ac)
The initializers directory is populated with files from the gitlab
distribution on start, but old files will be left in the state folder
even if they're removed from the distribution, which can lead to
startup failures. Fix this by always purging the directory on start
before populating it.
(cherry picked from commit c6efa9fd2d)
Since the preStart script is no longer running in privileged mode, we
reassign the files in the state directory and its config subdirectory
to the user we're running as. This is done by splitting the preStart
script into a privileged and an unprivileged part where the privileged
part does the reassignment.
Also, delete the database.yml symlink if it exists, since we want to
create a real file in its place.
Fixes#68696.
(cherry picked from commit 0f8133d633)
GitLab recently restructured their repos; whereas previously they had
one gitlab-ce and one gitlab-ee repo, they're now one and the
same. All proprietary components are put into the ee subdirectory -
removing it gives us the foss / community version of GitLab. For more
info, see
https://about.gitlab.com/2019/02/21/merging-ce-and-ee-codebases/
This gives us the opportunity to simplify things quite a bit, since we
don't have to keep track of two separate versions of either the base
data or rubyEnv.
(cherry picked from commit afa3abf632)
Instead of extracting prebuilt assets from the debian build, build
them from the source. This should give faster package updates and
reduces the amount of data needed to be downloaded by more than 500MB.
(cherry picked from commit 59324d1fb9)
Split the remove-hardcoded-locations patch into two separate patches,
one for the ruby package and one for the go package. This is clearer
and results in fewer rebuilds.
(cherry picked from commit 09e657efea)
- Update GitLab to 12.3.4
- Update update.py to cope with the new upstream repository structure
- Refactor gitlab-shell to use buildGoPackage and bundlerEnv for
dependencies
- Refactor gitlab-workhorse to use buildGoPackage for dependencies
- Make update.py able to update gitlab-shell and gitlab-workhorse
dependencies
- Various fixes necessary for update to work
(cherry picked from commit f3eb063ecf)
The networking.virtual test does not work with networkd yet, for
multiple reasons:
- network-online.target is not reached, because tun0 and tap0 are
considered as required for online but _not_ brought up or assigned
the configured addresses
- the commands later in the test rely on some units from the scripted
network setup
cc @fpletz networkd exper
cc @globin we looked at this together
(cherry picked from commit a3a441cd87)
Tests have been disabled since over a year and now the
code starts to bit-rot. As it seems unlikely that they
will come back in near future, let's just remove it.
(cherry picked from commit 173d5a4e6e)
Quoting the release manual:
> Remove attributes that we know we will not be able to support,
> especially if there is a stable alternative. E.g. Check that our Linux
> kernels' projected end-of-life are after our release projected
> end-of-life
This sets networking.useDHCP to false and for all interfaces found the
per-interface useDHCP to true. This replicates the current default
behaviour and prepares for the switch to networkd.
(cherry picked from commit 5ee383ea8c)
This setting will be removed with the switch to systemd-networkd. The
use of per interface config is encouraged instead.
(cherry picked from commit c26c6241ea)
xfce4-volumed-pulse is not abandoned, but is superseded by a panel
plugin which is not available when not using the desktop.
Fixes: volume up/down keys support
(cherry picked from commit d9cac95878)
There were several custom python dependencies broken. I decided to
modify the `sourcehut` expression as it wouldn't even evaluate without
nodejs-11_x I didn't manage to get it building.
(cherry picked from commit 594378ceea)
The hash to the patch is broken, even with the original revision
which adds asyncpg (ee2161c5e8). As the
downloaded patch seems fine, I guess that it was generated with
`nix-prefetch-url` (the hashes for `fetchpatch` usually differ) and the
issue wasn't found as the fixed-output-derivation was already in the
contributor's store.
See https://hydra.nixos.org/build/102495795
ZHF #68361
(cherry picked from commit 7c74ebd2a6)
Bump to fix the broken build of the package:
* Disable doctest as they're currently broken in our test env
* Loosen version constraint for `semantic_version` as it was only
introduced to work around some deprecation warnings[1]
See also: https://hydra.nixos.org/build/102480957
ZHF #68361
[1] 3446ae072b
(cherry picked from commit 06041fd174)
This option in now completely useless.
All the default configs for these packages
already have GNOME features default,
(cherry picked from commit 9bc8169695)
Since version 2.3 (https://github.com/NixOS/nix/pull/2949 which was
cherry-picked to master) Nix issues a warning when --no-net wasn't
passed and there is no network interface. This commit adds the --no-net
flag to the nix.conf check such that no warning is issued.
(cherry picked from commit e463c7cd75)
Previously mkRemovedOptionModule would only show the replacement
instructions when the removed option was *defined*. With this change, it
also does so when an option is *used*.
This is essential for options that are only intended to be used such as
`security.acme.directory`, whose replacement instructions would never
trigger without this change because almost everybody only uses the
option and isn't defining it.
(cherry picked from commit ebb136da9f)
This should be a behavior no-op, but it helps vulnix figure out that we
are up to date regarding security patches.
(cherry picked from commit 2242bb86d1)
The original file contains just a library name, which does not work when LD_LIBRARY_PATH does not contain /run/opengl-driver/lib, as is the case in unstable NixOS.
Fixes https://github.com/NixOS/nixpkgs/issues/69264
(cherry picked from commit d156b2b619)
See https://hydra.nixos.org/build/102480738
Bumping to latest version (which is 0.4.2 according to Cargo.lock) fixes
the build error. As no dependency changes happened, cargoSha256 doesn't
need to be updated.
ZHF #68361
(cherry picked from commit b5204d9f5f)
Applied several patches to fix the test suite on python 2.7 and to
properly install the `pyprinttags` executable. Also switched to the
GitHub source for now as the PyPI tarball was wrongly packaged and
didn't contain the `pyprinttags.py` script (see the last two patches for
further reference).
See also https://hydra.nixos.org/build/102493330
ZHF #68361
(cherry picked from commit c7164ea3c4)
Build broke as it's attempted to run the cmake configure-phase which
won't work as this package uses cmake, but builds via a `setup.py`
rather than a `CMakeLists.txt`.
ZHF #68361
(cherry picked from commit f8c6b826d4)
The `with stdenv;` would override the `mkDerivation` to be the regular
one, instead of the libsForQt5 one.
This simply removes the dangerous use of the all-encompassing `with`,
and prefers using a more precise inherit for `lib`.
See #65399
Co-authored-by: worldofpeace <worldofpeace@protonmail.ch>
(cherry picked from commit c52b5b8a5d)
We don't want to ignore config that can mess up machines. In general
this should always fail evaluation, as you think you are changing
behaviour and don't, which can easily create run-time errors we can
catch early.
(cherry picked from commit b08b0bcbbe)
In #68792 it was discovered that /dev/fuse doesn't have
wordl-read-writeable permissions anymore. The cause of this is that the
tmpfiles examples in systemd were reorganized and split into more files.
We thus lost some of the configuration we were depending on.
In this commit some of the new tmpfiles configuration that are
applicable to us are added which also makes wtmp/lastlog in the pam
module not necessary anymore.
Rationale for the new tmpfile configs:
- `journal-nowcow.conf`: Contains chattr +C for journald logs which
makes sense on copy-on-write filesystems like Btrfs. Other filesystems
shouldn't do anything funny when that flag is set.
- `static-nodes-permissions.conf`: Contains some permission overrides
for some device nodes like audio, loop, tun, fuse and kvm.
- `systemd-nspawn.conf`: Makes sure `/var/lib/machines` exists and old
snapshots are properly removed.
- `systemd-tmp.conf`: Removes systemd services related private tmp
folders and temporary coredump files.
- `var.conf`: Creates some useful directories in `/var` which we would
create anyway at some point. Also includes
`/var/log/{wtmp,btmp,lastlog}`.
Fixes#68792.
(cherry picked from commit 0dc4fe0a44)
The test has recently been failing due to the IPv6 address
on the server still being in the tentative state, when the
client sends its first request. The server will not start
using the IPv6 address until DAD has completed.
Scripted networking seems not to wait for DAD completion
before completing network-online.target, so let's switch
to networkd instead, which does.
(cherry picked from commit 1fb3818440)
We already have msgpack, which is the same. Building a Python env with
`spacy` resulted in a collision between an `.so` provided through both
`msgpack` and `msgpack-python`.
I don't know why `transitional = True` was set. These kind of things
should be documented!
(cherry picked from commit 22aef72ff1)
Importing spacy fails with:
ModuleNotFoundError: No module named 'pkg_resources
spaCy probably worked before because a dependency had setuptools as a
propagated dependency. This change adds setuptools to spacy's
propogatedBuildInputs.
Tested with the en_core_web_sm model.
(cherry picked from commit d2ccabaeea)
https://github.com/MindFlavor/prometheus_wireguard_exporter/releases/tag/3.1.1
This release adds a flag `-l` which takes an address where the exporter
is available. The default is `0.0.0.0` (previously, `0.0.0.0` was used
by default).
Please note that there are no dependency changes in Cargo and therefore
the cargo hash didn't change.
(cherry picked from commit beb59b76cf)
These don't use a the virtualbox sources, but an iso as src, and we need
to add the kernel 5.3 patch aswell.
As for some reason the source files are present on the .iso with Windows
Line endings (sic!), call dos2unix first.
Unfortunately, we can't use the same kernel-5.3-fix.patch as virtualbox
itself, as some files are missing and paths are different.
(cherry picked from commit 61f0f8d607)
This commits makes it clearer to a novice reader how to configure several
diferent types of SSID connections that were otherwise obscurely documented
Resolves#66650
(cherry picked from commit cce7486deb)
Mucommander 0.9.3-3 was released in January 2019.
* comment out `proguard.enabled = ...` in build.gradle
* use Gradle 4.10 (upstream uses 4.8)
* fix version in build.gradle
This fixes several Xcode 11 incompatibilities with MacVim, including an
issue where it wasn't inheriting the deployment target correctly to
begin with.
(cherry picked from commit 4563496375)
(cherry picked from commit 6f3b44baa4)
Reason: Avoid an expired (unusable) release in the stable release
(Signal-Desktop releases expire after 90 days).
Or else `xdg-screensaver suspend <WINDOW_ID>` fails with errors like:
Can't locate Net/DBus.pm in @INC [...]
This increases the closure of xdg-utils from 53 MiB to 119 MiB.
(The issue was found when testing retroarch.)
(cherry picked from commit e584eba7f8)
The functionality provided by this package has been added to the Idris contrib library (module `Interfaces.Verified`).
Therefore identifiers cannot be disambiguated anymore.
(cherry picked from commit 7df8575a72)
This commit fixes#26650
The main problem was that the iKVM related libraries are always loaded
from the current working directory. The bundled wrapper script makes
sure to CD to the package root folder. This is a no-go in nix as the
application writes its settings in the current working directory and the
store is read-only.
Workaround: create a directory in the users home, where the required
binaries are symlinked and is writable for the current user.
There was an additional issue that for some BMCs IPMIView relies on
the bundled `stunnel` binary to wrap the iKVM traffic in a TLS tunnel.
Therefore it has to be patched to make it executable and the `killall`
command is needed on the PATH because it is used to terminate the
`stunnel` process upon exit.
(cherry picked from commit 15b8478211)
A ton of tests fail and it's not obvious to me how to fix them.
Adding bleach to checkInputs fixes a tiny number of them, though.
(cherry picked from commit 4c714c1f58)
On startup piper would be unable to find Pango:
> ImportError: Typelib file for namespace 'Pango', version '1.0' not found
Workaround for #56943
(cherry picked from commit fb9b7446ee)
The recent bump to 0.96.2 now requires pyyaml 5.1.1. The PRs upgrading
home-assistant to a newer version and the one pinning to an old PyYAML
version raced each other and we ended up with both submitted.
Fixes home-assistant build.
(cherry picked from commit 04c1fcd09c)
Fixes the build because https://git.apache.org has been taken offline
and now has been replaced with another mirror
(cherry picked from commit 35e9b2915a)
The state path now, since the transition from initialization in
preStart to using systemd-tmpfiles, has the following restriction: no
parent directory can be owned by any other user than root or the user
specified in services.gitlab.user. This is a potentially breaking
change and the cause of the error isn't immediately obvious, so
document it both in the release notes and statePath description.
(cherry picked from commit dfc43f7d0a)
The tests were failing due the switch to pytest5.
This issue has been addressed upstream in
a500f20866
which is included in v.1.1.0, so bumping the version and
updating the old patch.
Hydra log of the failure:
https://hydra.nixos.org/build/100785460/nixlog/6
(cherry picked from commit 7ff2638b7f)
(cherry picked from commit b577340eb5bc3b72549f0544b50e2e37df78bf12)
Co-authored-by: Matthew Bauer <mjbauer95@gmail.com>
(cherry picked from commit 23399ff012)
The new systemd in 19.09 gives an "Access Denied" error when doing
"systemctl daemon-reexec" on an 19.03 system. The fix is to use the
previous systemctl to signal the daemon to re-exec itself. This
ensures that users don't have to reboot when upgrading from NixOS
19.03 to 19.09.
(cherry picked from commit b20a0e49c8)
Without python as a dependency I only get the following error:
/usr/bin/env: ‘python’: No such file or directory
(cherry picked from commit 4f297c2b6f)
The tests depend on many third-party libraries, presumably because
Sentry offers integration for each of them. I added these as build
inputs but not propagated build inputs, because they are only needed for
the tests.
(cherry picked from commit ce6145dedc)
Unfortunately it is broken and I won’t have time to fix right now.
Most likely we will have to wait until the macOS 10.12 update to get
this one working again.
(cherry picked from commit 70f1335f8d)
Fix configure time error:
...
ImportError: No module named wx
CMake Error at CMakeModules/FindwxPython.cmake:52 (message):
wxPython/Phoenix does not appear to be installed on the system
Only build tested.
Fixes: f7e28bf5d8 ("Split buildPythonPackage into setup hooks")
(cherry picked from commit 5af0d0b5da)
No dependencies within nixpkgs, and the package has not built
successfully since 2018-04-29 according to Hydra[1].
[1] https://hydra.nixos.org/build/100604053
(cherry picked from commit 21c92c4a1d)
As a side-effect of f7e28bf, the build no longer propagated 'setuptools', which
is a run-time dependency. See #68314 for further details.
(cherry picked from commit 55bf3b482c)
This is just a small bugfix release (essentially adds two lines of code)
which fixes a segfault if using with a program that doesn't pass a
sockaddr buffer to accept() or accept4().
Signed-off-by: aszlig <aszlig@nix.build>
(cherry picked from commit d69bc56e69)
Upstream moved libwidevinecdm.so from
./opt/google/chrome-unstable/libwidevinecdm.so
to
./opt/google/chrome-unstable/WidevineCdm/_platform_specific/linux_x64/libwidevinecdm.so
(cherry picked from commit 5456def6b3)
Fixes build errors for the third-party mongoose module:
```
In file included from
/nix/store/r5s3w32ahjzdlzsfrhybc3l2qcpi6yb2-libpcap-1.9.0/include/pcap.h:43,
from /build/ntopng-2.0/include/ntop_includes.h:93,
from src/HTTPserver.cpp:22:
/nix/store/r5s3w32ahjzdlzsfrhybc3l2qcpi6yb2-libpcap-1.9.0/include/pcap/pcap.h:958: note: this is the location of the previous definition
#define INVALID_SOCKET -1
src/../third-party/mongoose/mongoose.c:270:13: error: multiple types in one declaration
typedef int SOCKET;
^~~~~~
```
Even a simple typo fix can result in a reflow of a whole paragraph, leading to illegible diffs. The majority of text editors supports wrapping the source code to a comfortable width so it makes sense to me to sacrifice the few that do not rather than the unfortunately line-oriented diff tools.
(cherry picked from commit 641f6356d3)
Without this, mdadm won't be able to send email notifications:
$ sudo mdadm --monitor --scan --test
sh: /nix/store/2v8jn0lxza72grcm6hciak9fpgm7xb3a-system-sendmail-1.0: Is a directory
Fixes: b074a40f74 ("mdadm: use shared system-sendmail")
(cherry picked from commit 6b3832a519)
QT 5.12 introduced a regression, where a QT program wouldn't show its
tray icon, if there was no tray bar during program startup. (QTBUG-73459)
QT 5.12 introduced a regression, where qtwebengine applications would
freeze in some wayland compositors if a surface from the instance was not
visible (for example having a qutebrowser window on another workspace in
sway would freeze all qutebrowser windows).
Both got fixed already in Qt 5.12.4, but according to #57042 and its
sibling issues/PRs it doesn't seem to get fixed in near future for
nixpkgs.
Fixes the following ImportError on application startup:
/nix/store/qh7ndfsar3icmwqbiwcla7pc8x1133vg-python2.7-Markdown-3.1.1/bin/markdown_py README.md > README.html.new
Traceback (most recent call last):
File "/nix/store/qh7ndfsar3icmwqbiwcla7pc8x1133vg-python2.7-Markdown-3.1.1/bin/.markdown_py-wrapped", line 7, in <module>
from markdown.__main__ import run
File "/nix/store/qh7ndfsar3icmwqbiwcla7pc8x1133vg-python2.7-Markdown-3.1.1/lib/python2.7/site-packages/markdown/__init__.py", line 25, in <module>
from .core import Markdown, markdown, markdownFromFile
File "/nix/store/qh7ndfsar3icmwqbiwcla7pc8x1133vg-python2.7-Markdown-3.1.1/lib/python2.7/site-packages/markdown/core.py", line 29, in <module>
import pkg_resources
ImportError: No module named pkg_resources
make: *** [Makefile:53: README.html] Error 1
(cherry picked from commit 2b239b5b30)
tarsnap has always been unfree, but this wasn't expressed properly, so
it wouldn't be caught by allowUnfree = false.
(cherry picked from commit 39b5f5956e)
Update linuxPackages_latest to 5.3
(cherry picked from commit 921071da08)
Rationale for backport: Stable kernels (currently 5.2) will not be
maintained shortly after the next mainline release, which is currently
5.3.
This commit marks the rc linux kernel as broken just on the release
branch. Since testing kernels are neither regularly updated nor
backported by us to stable we shouldn't encourage using them.
The build was broken because meanwhile setools requires cython
and no bison, swig and flex anymore.
Also, bumping version to newest release, which is not directly related
to the build breakage.
(cherry picked from commit afc4110dac)
This reverts commit 755c9f3ba2.
I'm moving this to the staging-19.09 branch, similarly to a95a53aa.
It's a huge rebuild (on the order of 20k jobs), and it seems like that
was not noticed, and I can't see sufficient motivation to skip ahead of
other changes in staging-19.09. Here my motivation is mainly to reduce
the total amount of work necessary for Hydra.
Build was failing because we were depending on tagged versions of
the deblobbing scripts. The tags are not updated and thus newer
changes required won't be reflected unless the tag is re-created, which
might not be reliably the case.
So bumping revision and switching to use the branches to access the
deblob scripts.
For context, in our case the missing change is:
--- /nix/store/sfc0rrhj5l44zpqgpsymq5750k5wzg8p-tags-r16790/4.19-gnu/deblob-4.19 1970-01-01 01:00:01.000000000 +0100
+++ ../deblob-4.19 2019-09-14 14:53:44.637404289 +0200
@@ -1879,7 +1879,11 @@
announce BRCMFMAC - "Broadcom IEEE802.11n embedded FullMAC WLAN driver"
reject_firmware drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c
-reject_firmware drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c
+if grep -q firmware_request_nowarn drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c; then
+ reject_firmware_nowarn drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c
+else
+ reject_firmware drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c
+fi
clean_blob drivers/net/wireless/broadcom/brcm80211/brcmfmac/feature.c
clean_blob drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.h
(cherry picked from commit 2a8f7d71ce)
`django-cors-headers` 3.x (which is used in nixpkgs) requires a scheme
for allowed hosts. Upstream uses 2.4, however we create the python env
with Nix, so the source needs to be patched accordingly.
(cherry picked from commit 0d5806fefd)
Doesn't have a maintainer.
Doesn't work with our new glusterfs version.
bareos18 has changed from autotools to cmake so the derivation has to be
completely rewritten.
(cherry picked from commit e416a39464)
The CMake configuring is done in the `setup.py` and doesn't need to be
done by the setup hook. This broke the build as the setup-hook switches
into `source/build` which doesn't have a `setup.py`.
Relying on the setup script from upstream fixes the issue.
ZHF #68361
(cherry picked from commit 72ec538d2c)
Fixes problems such as:
systemd[1]: Failed to put bus name to hashmap: File exists
systemd[1]: dbus-org.freedesktop.nm-dispatcher.service: Two services allocated for the same bus name org.freedesktop.nm_dispatcher, refusing operation.
Problem is that systemd treats symlinks to files outside the service
path differently, causing our old workaround to look like two separate services.
These symlinks are intended to be a means for manually emulating
the behavior of the `Alias=` directive in these services.
Unfortunately even making these symlinks relative isn't enough,
since they don't make it to where it matters--
that only makes the links in /etc/static/systemd/system/*
relative, with systemd still being shown non-relative links
in /etc/systemd/system/*.
To fix this, drop all of this at the package level
and instead simply specify the aliases in the NixOS modules.
Also handle the same for modemmanager,
since the networkmanager NixOS module also handles that.
(cherry picked from commit 447d625edc)
During the last update, `hydra-notify` was rewritten as a daemon which
listens to postgresql notifications for each build[1]. The module
uses the `hydra-notify.service` unit from upstream's Hydra module and
the VM test ensures that email notifications are sent properly.
Also updated `hydra-init.service` to install `pg_trgm` on a local
database if needed[2].
[1] c7861b85c4
[2] 8a0a5ec3a3
(cherry picked from commit ce37a040c2)
We ship `https://cache.nixos.org` as binary cache by default which
automatically substitutes the test derivation used inside the Hydra
test. However it needs to be built locally to confirm that
`hydra-queue-runner` works properly.
Also inherited the platform name for the test derivation from `system`
to ensure that the build can be tested on each supported platform.
ZHF #68361
(cherry picked from commit 7f136b5a56)
The pkgconfig requirements for glusterfs-api were not satisfied without
uuid, resulting in Waf not setting the correct API version for glusterfs
during the build and consequently incompatible function calls in samba.
Co-authored-by: Franz Pletz <fpletz@fnordicwalking.de>
(cherry picked from commit 9378ff1cb5)
Some executables are built as PIEs (e.g. keepassxc) and are technically
isELFDyn, not isELFExec. Without this change those executables will not
be wrapped.
(cherry picked from commit c6d516dfc4)
By default everything from `stderr` will be recorded in case of errors,
however this shouldn't break `nixos-option` if a simple trace call is
used that breaks the Nix expression evaluated by `nixos-option`.
Fixes#67659
(cherry picked from commit 588aefc53d)
closes#68121
This is exactly the same as we had prior to
e7b0c389c2, which broke some dependents,
just under a new attribute name.
(cherry picked from commit afceaee163)
Also fix build by skipping a test that requires setuptools to be present.
(Also just adding setuptools does not fix the issue either?)
(cherry picked from commit 08d556c0e8)
When compiled with LuaJIT support, rspamd segfaults on aarch64.
Without LuaJIT, rspamd falls back to plain Lua and torch support needs to
be disabled.
(cherry picked from commit 7350dd9d94)
Because the gemdir was referenced on the derivation, it would cause the
whole gemdir to get added to the store, which would in turn force the
derivation to be rebuilt whenever unrelated folder files would change.
(cherry picked from commit cef857e8b7)
Related: #68314
This fixes startup of anki, which currently shows this in a dialog:
Error during startup:
Traceback (most recent call last):
File "/nix/store/0h395dwc6b80n5xg93p86ywaz6kpz6ck-anki-2.1.15/lib/python3.7/site-packages/aqt/main.py", line 46, in __init__
self.setupAddons()
File "/nix/store/0h395dwc6b80n5xg93p86ywaz6kpz6ck-anki-2.1.15/lib/python3.7/site-packages/aqt/main.py", line 657, in setupAddons
import aqt.addons
File "/nix/store/0h395dwc6b80n5xg93p86ywaz6kpz6ck-anki-2.1.15/lib/python3.7/site-packages/aqt/addons.py", line 9, in <module>
import markdown
File "/nix/store/knq8798kl0xzzr7ii4bchskg1c8mq6pj-python3.7-Markdown-3.1.1/lib/python3.7/site-packages/markdown/__init__.py", line 25, in <module>
from .core import Markdown, markdown, markdownFromFile
File "/nix/store/knq8798kl0xzzr7ii4bchskg1c8mq6pj-python3.7-Markdown-3.1.1/lib/python3.7/site-packages/markdown/core.py", line 29, in <module>
import pkg_resources
ModuleNotFoundError: No module named 'pkg_resources'
(cherry picked from commit 2769d610ac)
Fixes the error:
qt.qpa.plugin: Could not find the Qt platform plugin "xcb" in ""
This application failed to start because no Qt platform plugin could be initialized. Reinstalling the application may fix this problem.
See #65399
(cherry picked from commit b918bb9e5d)
This adds a module that configures the json exporter,
which then acts as an exporter for rspamd.
(cherry picked from commit bcce960d7d)
Signed-off-by: Maximilian Bosch <maximilian@mbosch.me>
When mailman-web restarts, it removes the generated "static" directory. This
breaks a currently running httpd process, which needs a re-start, too, to
obtain a new handle for the newly generated path.
(cherry picked from commit 0cc37b3cfa)
This fixes:
FAILED: obj/engine/engine.engine.o
clang++ -MMD -MF obj/engine/engine.engine.o.d -DOS_LINUX -DMOZC_BUILD -DCHANNEL_DEV -DENABLE_GTK_RENDERER -DNDEBUG -DQT_NO_DEBUG -DNO_LOGGING -DIGNORE_HELP_FLAG -DIGNORE_INVALID_FLAG -I/build/source/src -Igen -Igen/proto_out -Wall -Wno-char-subscripts -Wno-sign-compare -Wno-deprecated-declarations -Wwrite-strings -fPIC -fno-exceptions -fmessage-length=0 -fno-strict-aliasing -funsigned-char -include base/namespace.h -pipe -pthread -fno-omit-frame-pointer -fstack-protector --param=ssp-buffer-size=4 -Wtype-limits -O2 -Wno-deprecated -Wno-covered-switch-default -Wno-unnamed-type-template-args -Wno-c++11-narrowing -std=gnu++0x -std=gnu++0x -c ../../engine/engine.cc -o obj/engine/engine.engine.o
In file included from ../../engine/engine.cc:30:
In file included from /build/source/src/engine/engine.h:33:
In file included from /nix/store/pcs8pq4a5rkym1hzibqz7da45fxkmig7-gcc-8.3.0/include/c++/8.3.0/memory:62:
In file included from /nix/store/pcs8pq4a5rkym1hzibqz7da45fxkmig7-gcc-8.3.0/include/c++/8.3.0/bits/stl_algobase.h:66:
/nix/store/pcs8pq4a5rkym1hzibqz7da45fxkmig7-gcc-8.3.0/include/c++/8.3.0/bits/stl_iterator_base_funcs.h:183:2: error: cannot decrement value of type 'mozc::ZeroQueryDict::iterator'
--__i;
^ ~~~
/nix/store/pcs8pq4a5rkym1hzibqz7da45fxkmig7-gcc-8.3.0/include/c++/8.3.0/bits/stl_iterator_base_funcs.h:206:12: note: in instantiation of function template specialization 'std::__advance<mozc::ZeroQueryDict::iterator, long>' requested here
std::__advance(__i, __d, std::__iterator_category(__i));
^
/nix/store/pcs8pq4a5rkym1hzibqz7da45fxkmig7-gcc-8.3.0/include/c++/8.3.0/bits/stl_algo.h:2137:9: note: in instantiation of function template specialization 'std::advance<mozc::ZeroQueryDict::iterator, long>' requested here
std::advance(__middle, __half);
^
/nix/store/pcs8pq4a5rkym1hzibqz7da45fxkmig7-gcc-8.3.0/include/c++/8.3.0/bits/stl_algo.h:2190:19: note: in instantiation of function template specialization 'std::__equal_range<mozc::ZeroQueryDict::iterator, unsigned long, __gnu_cxx::__ops::_Iter_less_val, __gnu_cxx::__ops::_Val_less_iter>' requested here
return std::__equal_range(__first, __last, __val,
^
/build/source/src/prediction/zero_query_dict.h:213:17: note: in instantiation of function template specialization 'std::equal_range<mozc::ZeroQueryDict::iterator, unsigned long>' requested here
return std::equal_range(begin(), end(), iter.index());
^
1 error generated.
(cherry picked from commit fdccd9cd9b)
Recent changes to buildPythonPackage seem to have enabled a configure
script that doesn't work, so disable it.
(cherry picked from commit 91b7dd6c91)
ZHF: #68361
This fixes:
Traceback (most recent call last):
File "/nix/store/607z14x0spsz1lsh0fg9cbyc9lr038mi-python3.7-snscrape-0.3.0/bin/.snscrape-wrapped", line 11, in <module>
sys.exit(main())
File "/nix/store/607z14x0spsz1lsh0fg9cbyc9lr038mi-python3.7-snscrape-0.3.0/lib/python3.7/site-packages/snscrape/cli.py", line 218, in main
args = parse_args()
File "/nix/store/607z14x0spsz1lsh0fg9cbyc9lr038mi-python3.7-snscrape-0.3.0/lib/python3.7/site-packages/snscrape/cli.py", line 154, in parse_args
import snscrape.version
File "/nix/store/607z14x0spsz1lsh0fg9cbyc9lr038mi-python3.7-snscrape-0.3.0/lib/python3.7/site-packages/snscrape/version.py", line 1, in <module>
import pkg_resources
ModuleNotFoundError: No module named 'pkg_resources'
Related: https://github.com/NixOS/nixpkgs/pull/68314
(cherry picked from commit 7e7c98a199)
GCC 8 introduced a new type of warning `-Wclass-memaccess` which
is included in `-Wall`. This warnings spits out *a million* of warnings
like the following:
```
[...]
/build/source/Source/WTF/wtf/Vector.h:128:15: warning: 'void* memcpy(void*, const void*, size_t)' writing to an object of type 'class WTF::RefPtr<WebCore::TransformOperation>' with no trivial copy-assignment; use copy-assignment or copy-initialization instead [-Wclass-memaccess]
memcpy(dst, src, reinterpret_cast<const char*>(srcEnd) - reinterpret_cast<const char*>(src));
[...]
``
Logs demonstrating the issue:
https://hydra.nixos.org/build/100205478/nixlog/1
While I don't think disabling warnings is the best way to deal with this,
there is alrady precedent for this package and I don't feel confident enough
to either patch or bump this package.
Please view this as a low-friction sub-optimal suggestion in case nobody else
has a better fix.
(cherry picked from commit 6f1ad0676f)
This fixes:
FAILED: obj/engine/engine.engine.o
clang++ -MMD -MF obj/engine/engine.engine.o.d -DOS_LINUX -DMOZC_BUILD -DCHANNEL_DEV -DENABLE_GTK_RENDERER -DNDEBUG -DQT_NO_DEBUG -DNO_LOGGING -DIGNORE_HELP_FLAG -DIGNORE_INVALID_FLAG -I/build/source/src -Igen -Igen/proto_out -Wall -Wno-char-subscripts -Wno-sign-compare -Wno-deprecated-declarations -Wwrite-strings -Wno-unknown-warning-option -Wno-inconsistent-missing-override -fPIC -fno-exceptions -fmessage-length=0 -fno-strict-aliasing -funsigned-char -pipe -pthread -fno-omit-frame-pointer -fstack-protector --param=ssp-buffer-size=4 -Wtype-limits -O2 -Wno-deprecated -Wno-covered-switch-default -Wno-unnamed-type-template-args -Wno-c++11-narrowing -std=gnu++0x -std=gnu++0x -c ../../engine/engine.cc -o obj/engine/engine.engine.o
In file included from ../../engine/engine.cc:30:
In file included from /build/source/src/engine/engine.h:33:
In file included from /nix/store/pcs8pq4a5rkym1hzibqz7da45fxkmig7-gcc-8.3.0/include/c++/8.3.0/memory:62:
In file included from /nix/store/pcs8pq4a5rkym1hzibqz7da45fxkmig7-gcc-8.3.0/include/c++/8.3.0/bits/stl_algobase.h:66:
/nix/store/pcs8pq4a5rkym1hzibqz7da45fxkmig7-gcc-8.3.0/include/c++/8.3.0/bits/stl_iterator_base_funcs.h:183:2: error: cannot decrement value of type 'mozc::ZeroQueryDict::iterator'
--__i;
^ ~~~
/nix/store/pcs8pq4a5rkym1hzibqz7da45fxkmig7-gcc-8.3.0/include/c++/8.3.0/bits/stl_iterator_base_funcs.h:206:12: note: in instantiation of function template specialization 'std::__advance<mozc::ZeroQueryDict::iterator, long>' requested here
std::__advance(__i, __d, std::__iterator_category(__i));
^
/nix/store/pcs8pq4a5rkym1hzibqz7da45fxkmig7-gcc-8.3.0/include/c++/8.3.0/bits/stl_algo.h:2137:9: note: in instantiation of function template specialization 'std::advance<mozc::ZeroQueryDict::iterator, long>' requested here
std::advance(__middle, __half);
^
/nix/store/pcs8pq4a5rkym1hzibqz7da45fxkmig7-gcc-8.3.0/include/c++/8.3.0/bits/stl_algo.h:2190:19: note: in instantiation of function template specialization 'std::__equal_range<mozc::ZeroQueryDict::iterator, unsigned long, __gnu_cxx::__ops::_Iter_less_val, __gnu_cxx::__ops::_Val_less_iter>' requested here
return std::__equal_range(__first, __last, __val,
^
/build/source/src/prediction/zero_query_dict.h:213:17: note: in instantiation of function template specialization 'std::equal_range<mozc::ZeroQueryDict::iterator, unsigned long>' requested here
return std::equal_range(begin(), end(), iter.index());
^
1 error generated.
(cherry picked from commit b4b332bcad)
Currently, `setuptools` isn't propagated automatically to python
packages[1] which causes the following error when starting
`matrix-synapse`:
```
Traceback (most recent call last):
File "/nix/store/xxkds7821mrahfx75az0sq3ryf69m612-matrix-synapse-1.3.1/bin/.homeserver-wrapped", line 39, in <module>
import synapse.config.logger
File "/nix/store/xxkds7821mrahfx75az0sq3ryf69m612-matrix-synapse-1.3.1/lib/python3.7/site-packages/synapse/config/logger.py", line 27, in <module>
from synapse.app import _base as appbase
File "/nix/store/xxkds7821mrahfx75az0sq3ryf69m612-matrix-synapse-1.3.1/lib/python3.7/site-packages/synapse/app/__init__.py", line 18, in <module>
E402
File "/nix/store/xxkds7821mrahfx75az0sq3ryf69m612-matrix-synapse-1.3.1/lib/python3.7/site-packages/synapse/python_dependencies.py", line 19, in <module>
from pkg_resources import (
No module named 'pkg_resources'
```
[1] https://github.com/NixOS/nixpkgs/pull/68314
(cherry picked from commit 58dc1e2a6f)
The current Skydive version can not be build with a recent Go version
and the maintainer (lewo) is no longer interested in maintaining it.
(cherry picked from commit 636e15507b)
Before this change, buildRustCrate always called rustc with
--extern libName=[...]libName[...]
However, Cargo permits using a different name under which a dependency
is known to a crate. For example, rand 0.7.0 uses:
[dependencies]
getrandom_package = { version = "0.1.1", package = "getrandom", optional = true }
Which introduces the getrandom dependency such that it is known as
getrandom_package to the rand crate. In this case, the correct extern
flag is of the form
--extern getrandom_package=[...]getrandom[...]
which is currently not supported. In order to support such cases, this
change introduces a crateRenames argument to buildRustCrate. This
argument is an attribute set of dependencies that should be renamed. In
this case, crateRenames would be:
{
"getrandom" = "getrandom_package";
}
The extern options are then built such that if the libName occurs as
an attribute in this set, it value will be used as the local
name. Otherwise libName will be used as before.
(cherry picked from commit 85c6d72011)
Adds support for Realtek wireless/bluetooth cards found in some Lenovo
laptops. The old `r8822be` module was removed in favour of this one.
(cherry picked from commit 471ba8e2e6)
Looks like something used to propagate nettle but doesn't anymore.
Adding it properly, as it does depend on it, fixes the issue.
(cherry picked from commit 00d419c362)
Fix gnome3 tests.
ZHF: #68361
It's no longer propagated so we need to add it.
Was failing like:
FAILED: libfwupd/fwupd.map
/build/fwupd-1.2.10/libfwupd/generate-version-script.py LIBFWUPD libfwupd/Fwupd-2.0.gir libfwupd/fwupd.map
Traceback (most recent call last):
File "/build/fwupd-1.2.10/libfwupd/generate-version-script.py", line 11, in <module>
from pkg_resources import parse_version
ModuleNotFoundError: No module named 'pkg_resources'
(cherry picked from commit a9e0f1dee1)
This fixes the gnome3 tests so the channel can advance.
This fixes:
pythonCatchConflictsPhase
Found duplicated packages in closure for dependency 'lmdb':
lmdb 0.97 (/build/lmdb-0.97)
lmdb 0.97 (/nix/store/js0iimri6y9yqgfc111jzp3mrv5ic9cj-python3.7-lmdb-0.97/lib/python3.7/site-packages)
Package duplicates found in closure, see above. Usually this happens if two packages depend on different version of the same dependency.
builder for '/nix/store/9bcn2m3r5v8slmpj31hxw05j906qgl5l-python3.7-lmdb-0.97.drv' failed with exit code 1
This was probably broken by f7e28bf5d8
(cherry picked from commit 39d0c9693e)
<!-- Nixpkgs has a lot of new incoming Pull Requests, but not enough people to review this constant stream. Even if you aren't a committer, we would appreciate reviews of other PRs, especially simple ones like package updates. Just testing the relevant package/service and leaving a comment saying what you tested, how you tested it and whether it worked would be great. List of open PRs: <https://github.com/NixOS/nixpkgs/pulls>, for more about reviewing contributions: <https://hydra.nixos.org/job/nixpkgs/trunk/manual/latest/download/1/nixpkgs/manual.html#sec-reviewing-contributions>. Reviewing isn't mandatory, but it would help out a lot and reduce the average time-to-merge for all of us. Thanks a lot if you do! -->
<!-- Nixpkgs has a lot of new incoming Pull Requests, but not enough people to review this constant stream. Even if you aren't a committer, we would appreciate reviews of other PRs, especially simple ones like package updates. Just testing the relevant package/service and leaving a comment saying what you tested, how you tested it and whether it worked would be great. List of open PRs: <https://github.com/NixOS/nixpkgs/pulls>, for more about reviewing contributions: <https://hydra.nixos.org/job/nixpkgs/trunk/manual/latest/download/1/nixpkgs/manual.html#chap-reviewing-contributions>. Reviewing isn't mandatory, but it would help out a lot and reduce the average time-to-merge for all of us. Thanks a lot if you do! -->
###### Motivation for this change
@@ -12,7 +12,7 @@
- [ ] macOS
- [ ] other Linux distributions
- [ ] 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 nix-review --run "nix-review wip"`
- [ ] Tested compilation of all pkgs that depend on this change using `nix-shell -p nixpkgs-review --run "nixpkgs-review wip"`
- [ ] Tested execution of all binary files (usually in `./result/bin/`)
- [ ] Determined the impact on package closure size (by running `nix path-info -S` before and after)
- [ ] Ensured that relevant documentation is up to date
When using Nix, you will frequently need to download source code and other files from the internet. Nixpkgs comes with a few helper functions that allow you to fetch fixed-output derivations in a structured way.
</para>
<para>
The two fetcher primitives are <function>fetchurl</function> and <function>fetchzip</function>. Both of these have two required arguments, a URL and a hash. The hash is typically <literal>sha256</literal>, although many more hash algorithms are supported. Nixpkgs contributors are currently recommended to use <literal>sha256</literal>. This hash will be used by Nix to identify your source. A typical usage of fetchurl is provided below.
The main difference between <function>fetchurl</function> and <function>fetchzip</function> is in how they store the contents. <function>fetchurl</function> will store the unaltered contents of the URL within the Nix store. <function>fetchzip</function> on the other hand will decompress the archive for you, making files and directories directly accessible in the future. <function>fetchzip</function> can only be used with archives. Despite the name, <function>fetchzip</function> is not limited to .zip files and can also be used with any tarball.
</para>
<para>
<function>fetchpatch</function> works very similarly to <function>fetchurl</function> with the same arguments expected. It expects patch files as a source and and performs normalization on them before computing the checksum. For example it will remove comments or other unstable parts that are sometimes added by version control systems and can change over time.
</para>
<para>
Other fetcher functions allow you to add source code directly from a VCS such as subversion or git. These are mostly straightforward names based on the name of the command used with the VCS system. Because they give you a working repository, they act most like <function>fetchzip</function>.
</para>
<variablelist>
<varlistentry>
<term>
<literal>fetchsvn</literal>
</term>
<listitem>
<para>
Used with Subversion. Expects <literal>url</literal> to a Subversion directory, <literal>rev</literal>, and <literal>sha256</literal>.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term>
<literal>fetchgit</literal>
</term>
<listitem>
<para>
Used with Git. Expects <literal>url</literal> to a Git repo, <literal>rev</literal>, and <literal>sha256</literal>. <literal>rev</literal> in this case can be full the git commit id (SHA1 hash) or a tag name like <literal>refs/tags/v1.0</literal>.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term>
<literal>fetchfossil</literal>
</term>
<listitem>
<para>
Used with Fossil. Expects <literal>url</literal> to a Fossil archive, <literal>rev</literal>, and <literal>sha256</literal>.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term>
<literal>fetchcvs</literal>
</term>
<listitem>
<para>
Used with CVS. Expects <literal>cvsRoot</literal>, <literal>tag</literal>, and <literal>sha256</literal>.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term>
<literal>fetchhg</literal>
</term>
<listitem>
<para>
Used with Mercurial. Expects <literal>url</literal>, <literal>rev</literal>, and <literal>sha256</literal>.
</para>
</listitem>
</varlistentry>
</variablelist>
<para>
A number of fetcher functions wrap part of <function>fetchurl</function> and <function>fetchzip</function>. They are mainly convenience functions intended for commonly used destinations of source code in Nixpkgs. These wrapper fetchers are listed below.
</para>
<variablelist>
<varlistentry>
<term>
<literal>fetchFromGitHub</literal>
</term>
<listitem>
<para>
<function>fetchFromGitHub</function> expects four arguments. <literal>owner</literal> is a string corresponding to the GitHub user or organization that controls this repository. <literal>repo</literal> corresponds to the name of the software repository. These are located at the top of every GitHub HTML page as <literal>owner</literal>/<literal>repo</literal>. <literal>rev</literal> corresponds to the Git commit hash or tag (e.g <literal>v1.0</literal>) that will be downloaded from Git. Finally, <literal>sha256</literal> corresponds to the hash of the extracted directory. Again, other hash algorithms are also available but <literal>sha256</literal> is currently preferred.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term>
<literal>fetchFromGitLab</literal>
</term>
<listitem>
<para>
This is used with GitLab repositories. The arguments expected are very similar to fetchFromGitHub above.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term>
<literal>fetchFromBitbucket</literal>
</term>
<listitem>
<para>
This is used with BitBucket repositories. The arguments expected are very similar to fetchFromGitHub above.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term>
<literal>fetchFromSavannah</literal>
</term>
<listitem>
<para>
This is used with Savannah repositories. The arguments expected are very similar to fetchFromGitHub above.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term>
<literal>fetchFromRepoOrCz</literal>
</term>
<listitem>
<para>
This is used with repo.or.cz repositories. The arguments expected are very similar to fetchFromGitHub above.
<varname>pkgs.appimageTools</varname> is a set of functions for extracting
and wrapping <linkxlink:href="https://appimage.org/">AppImage</link> files.
They are meant to be used if traditional packaging from source is infeasible,
or it would take too long. To quickly run an AppImage file,
<literal>pkgs.appimage-run</literal> can be used as well.
<varname>pkgs.appimageTools</varname> is a set of functions for extracting and wrapping <linkxlink:href="https://appimage.org/">AppImage</link> files. They are meant to be used if traditional packaging from source is infeasible, or it would take too long. To quickly run an AppImage file, <literal>pkgs.appimage-run</literal> can be used as well.
</para>
<warning>
<para>
The <varname>appimageTools</varname> API is unstable and may be subject to
backwards-incompatible changes in the future.
The <varname>appimageTools</varname> API is unstable and may be subject to backwards-incompatible changes in the future.
There are different formats for AppImages, see<linkxlink:href="https://github.com/AppImage/AppImageSpec/blob/74ad9ca2f94bf864a4a0dac1f369dd4f00bd1c28/draft.md#image-format">the specification</link> for details.
Depending on the type of AppImage you're wrapping, you'll have to use
<varname>wrapType1</varname> or <varname>wrapType2</varname>.
Depending on the type of AppImage you're wrapping, you'll have to use<varname>wrapType1</varname> or <varname>wrapType2</varname>.
</para>
<programlisting>
@@ -91,23 +82,16 @@ appimageTools.wrapType2 { # or wrapType1
</callout>
<calloutarearefs='ex-appimageTools-wrapping-2'>
<para>
<varname>extraPkgs</varname> allows you to pass a function to include
additional packages inside the FHS environment your AppImage is going to
run in. There are a few ways to learn which dependencies an application
needs:
<varname>extraPkgs</varname> allows you to pass a function to include additional packages inside the FHS environment your AppImage is going to run in. There are a few ways to learn which dependencies an application needs:
<itemizedlist>
<listitem>
<para>
Looking through the extracted AppImage files, reading its scripts and
running <command>patchelf</command> and <command>ldd</command> on its
executables. This can also be done in <command>appimage-run</command>,
by setting <command>APPIMAGE_DEBUG_EXEC=bash</command>.
Looking through the extracted AppImage files, reading its scripts and running <command>patchelf</command> and <command>ldd</command> on its executables. This can also be done in <command>appimage-run</command>, by setting <command>APPIMAGE_DEBUG_EXEC=bash</command>.
</para>
</listitem>
<listitem>
<para>
Running <command>strace -vfefile</command> on the wrapped executable,
looking for libraries that can't be found.
Running <command>strace -vfefile</command> on the wrapped executable, looking for libraries that can't be found.
Docker Image Specification v1.2.0 </link>. Docker itself is not used to
perform any of the operations done by these functions.
<varname>pkgs.dockerTools</varname> is a set of functions for creating and manipulating Docker images according to the <linkxlink:href="https://github.com/moby/moby/blob/master/image/spec/v1.2.md#docker-image-specification-v120"> Docker Image Specification v1.2.0 </link>. Docker itself is not used to perform any of the operations done by these functions.
</para>
<warning>
<para>
The <varname>dockerTools</varname> API is unstable and may be subject to
backwards-incompatible changes in the future.
The <varname>dockerTools</varname> API is unstable and may be subject to backwards-incompatible changes in the future.
</para>
</warning>
@@ -23,15 +18,11 @@
<title>buildImage</title>
<para>
This function is analogous to the <command>docker build</command> command,
in that it can be used to build a Docker-compatible repository tarball
containing a single image with one or multiple layers. As such, the result
is suitable for being loaded in Docker with <command>docker load</command>.
This function is analogous to the <command>docker build</command> command, in that it can be used to build a Docker-compatible repository tarball containing a single image with one or multiple layers. As such, the result is suitable for being loaded in Docker with <command>docker load</command>.
</para>
<para>
The parameters of <varname>buildImage</varname> with relative example values
are described below:
The parameters of <varname>buildImage</varname> with relative example values are described below:
</para>
<examplexml:id='ex-dockerTools-buildImage'>
@@ -63,135 +54,89 @@ buildImage {
</example>
<para>
The above example will build a Docker image <literal>redis/latest</literal>
from the given base image. Loading and running this image in Docker results
in <literal>redis-server</literal> being started automatically.
The above example will build a Docker image <literal>redis/latest</literal> from the given base image. Loading and running this image in Docker results in <literal>redis-server</literal> being started automatically.
</para>
<calloutlist>
<calloutarearefs='ex-dockerTools-buildImage-1'>
<para>
<varname>name</varname> specifies the name of the resulting image. This is
the only required argument for <varname>buildImage</varname>.
<varname>name</varname> specifies the name of the resulting image. This is the only required argument for <varname>buildImage</varname>.
</para>
</callout>
<calloutarearefs='ex-dockerTools-buildImage-2'>
<para>
<varname>tag</varname> specifies the tag of the resulting image. By
default it's <literal>null</literal>, which indicates that the nix output
hash will be used as tag.
<varname>tag</varname> specifies the tag of the resulting image. By default it's <literal>null</literal>, which indicates that the nix output hash will be used as tag.
</para>
</callout>
<calloutarearefs='ex-dockerTools-buildImage-3'>
<para>
<varname>fromImage</varname> is the repository tarball containing the base
image. It must be a valid Docker image, such as exported by
<command>docker save</command>. By default it's <literal>null</literal>,
which can be seen as equivalent to <literal>FROM scratch</literal> of a
<filename>Dockerfile</filename>.
<varname>fromImage</varname> is the repository tarball containing the base image. It must be a valid Docker image, such as exported by <command>docker save</command>. By default it's <literal>null</literal>, which can be seen as equivalent to <literal>FROM scratch</literal> of a <filename>Dockerfile</filename>.
</para>
</callout>
<calloutarearefs='ex-dockerTools-buildImage-4'>
<para>
<varname>fromImageName</varname> can be used to further specify the base
image within the repository, in case it contains multiple images. By
default it's <literal>null</literal>, in which case
<varname>buildImage</varname> will peek the first image available in the
repository.
<varname>fromImageName</varname> can be used to further specify the base image within the repository, in case it contains multiple images. By default it's <literal>null</literal>, in which case <varname>buildImage</varname> will peek the first image available in the repository.
</para>
</callout>
<calloutarearefs='ex-dockerTools-buildImage-5'>
<para>
<varname>fromImageTag</varname> can be used to further specify the tag of
the base image within the repository, in case an image contains multiple
tags. By default it's <literal>null</literal>, in which case
<varname>buildImage</varname> will peek the first tag available for the
base image.
<varname>fromImageTag</varname> can be used to further specify the tag of the base image within the repository, in case an image contains multiple tags. By default it's <literal>null</literal>, in which case <varname>buildImage</varname> will peek the first tag available for the base image.
</para>
</callout>
<calloutarearefs='ex-dockerTools-buildImage-6'>
<para>
<varname>contents</varname> is a derivation that will be copied in the new
layer of the resulting image. This can be similarly seen as <command>ADD
contents/ /</command> in a <filename>Dockerfile</filename>. By default
it's <literal>null</literal>.
<varname>contents</varname> is a derivation that will be copied in the new layer of the resulting image. This can be similarly seen as <command>ADD contents/ /</command> in a <filename>Dockerfile</filename>. By default it's <literal>null</literal>.
<varname>runAsRoot</varname> is a bash script that will run as root in an
environment that overlays the existing layers of the base image with the
new resulting layer, including the previously copied
<varname>contents</varname> derivation. This can be similarly seen as
<command>RUN ...</command> in a <filename>Dockerfile</filename>.
<varname>runAsRoot</varname> is a bash script that will run as root in an environment that overlays the existing layers of the base image with the new resulting layer, including the previously copied <varname>contents</varname> derivation. This can be similarly seen as <command>RUN ...</command> in a <filename>Dockerfile</filename>.
<note>
<para>
Using this parameter requires the <literal>kvm</literal> device to be
available.
Using this parameter requires the <literal>kvm</literal> device to be available.
</para>
</note>
</para>
</callout>
<calloutarearefs='ex-dockerTools-buildImage-8'>
<para>
<varname>config</varname> is used to specify the configuration of the
containers that will be started off the built image in Docker. The
<varname>config</varname> is used to specify the configuration of the containers that will be started off the built image in Docker. The available options are listed in the <linkxlink:href="https://github.com/moby/moby/blob/master/image/spec/v1.2.md#image-json-field-descriptions"> Docker Image Specification v1.2.0 </link>.
</para>
</callout>
</calloutlist>
<para>
After the new layer has been created, its closure (to which
<varname>contents</varname>, <varname>config</varname> and
<varname>runAsRoot</varname> contribute) will be copied in the layer itself.
Only new dependencies that are not already in the existing layers will be
copied.
After the new layer has been created, its closure (to which<varname>contents</varname>, <varname>config</varname> and <varname>runAsRoot</varname> contribute) will be copied in the layer itself. Only new dependencies that are not already in the existing layers will be copied.
</para>
<para>
At the end of the process, only one new single layer will be produced and
added to the resulting image.
At the end of the process, only one new single layer will be produced and added to the resulting image.
</para>
<para>
The resulting repository will only list the single image
<varname>image/tag</varname>. In the case of
<xreflinkend='ex-dockerTools-buildImage'/> it would be
<varname>redis/latest</varname>.
The resulting repository will only list the single image<varname>image/tag</varname>. In the case of <xreflinkend='ex-dockerTools-buildImage'/> it would be <varname>redis/latest</varname>.
</para>
<para>
It is possible to inspect the arguments with which an image was built using
its <varname>buildArgs</varname> attribute.
It is possible to inspect the arguments with which an image was built using its <varname>buildArgs</varname> attribute.
</para>
<note>
<para>
If you see errors similar to <literal>getProtocolByName: does not exist (no
such protocol name: tcp)</literal> you may need to add
<literal>pkgs.iana-etc</literal> to <varname>contents</varname>.
If you see errors similar to <literal>getProtocolByName: does not exist (no such protocol name: tcp)</literal> you may need to add <literal>pkgs.iana-etc</literal> to <varname>contents</varname>.
</para>
</note>
<note>
<para>
If you see errors similar to <literal>Error_Protocol ("certificate has
unknown CA",True,UnknownCa)</literal> you may need to add
<literal>pkgs.cacert</literal> to <varname>contents</varname>.
If you see errors similar to <literal>Error_Protocol ("certificate has unknown CA",True,UnknownCa)</literal> you may need to add <literal>pkgs.cacert</literal> to <varname>contents</varname>.
<title>Impurely Defining a Docker Layer's Creation Date</title>
<para>
By default <function>buildImage</function> will use a static date of one
second past the UNIX Epoch. This allows <function>buildImage</function> to
produce binary reproducible images. When listing images with
<command>docker images</command>, the newly created images will be listed
like this:
By default <function>buildImage</function> will use a static date of one second past the UNIX Epoch. This allows <function>buildImage</function> to produce binary reproducible images. When listing images with <command>docker images</command>, the newly created images will be listed like this:
</para>
<screen><![CDATA[
$ docker images
@@ -199,9 +144,7 @@ REPOSITORY TAG IMAGE ID CREATED SIZE
hello latest 08c791c7846e 48 years ago 25.2MB
]]></screen>
<para>
You can break binary reproducibility but have a sorted, meaningful
<literal>CREATED</literal> column by setting <literal>created</literal> to
<literal>now</literal>.
You can break binary reproducibility but have a sorted, meaningful<literal>CREATED</literal> column by setting <literal>created</literal> to <literal>now</literal>.
</para>
<programlisting><![CDATA[
pkgs.dockerTools.buildImage {
@@ -214,8 +157,7 @@ pkgs.dockerTools.buildImage {
}
]]></programlisting>
<para>
and now the Docker CLI will display a reasonable date and sort the images
as expected:
and now the Docker CLI will display a reasonable date and sort the images as expected:
<screen><![CDATA[
$ docker images
REPOSITORY TAG IMAGE ID CREATED SIZE
@@ -230,8 +172,7 @@ hello latest de2bf4786de6 About a minute ago 25.2MB
<title>buildLayeredImage</title>
<para>
Create a Docker image with many of the store paths being on their own layer
to improve sharing between images.
Create a Docker image with many of the store paths being on their own layer to improve sharing between images.
</para>
<variablelist>
@@ -264,8 +205,7 @@ hello latest de2bf4786de6 About a minute ago 25.2MB
</term>
<listitem>
<para>
Top level paths in the container. Either a single derivation, or a list
of derivations.
Top level paths in the container. Either a single derivation, or a list of derivations.
Run-time configuration of the container. A full list of the options are available at in the <linkxlink:href="https://github.com/moby/moby/blob/master/image/spec/v1.2.md#image-json-field-descriptions"> Docker Image Specification v1.2.0 </link>.
@@ -325,10 +260,7 @@ hello latest de2bf4786de6 About a minute ago 25.2MB
</term>
<listitem>
<para>
Shell commands to run while building the final layer, without access
to most of the layer contents. Changes to this layer are "on top"
of all the other layers, so can create additional directories
and files.
Shell commands to run while building the final layer, without access to most of the layer contents. Changes to this layer are "on top" of all the other layers, so can create additional directories and files.
</para>
</listitem>
</varlistentry>
@@ -338,8 +270,7 @@ hello latest de2bf4786de6 About a minute ago 25.2MB
<title>Behavior of <varname>contents</varname> in the final image</title>
<para>
Each path directly listed in <varname>contents</varname> will have a
symlink in the root of the image.
Each path directly listed in <varname>contents</varname> will have a symlink in the root of the image.
Increasing the <varname>maxLayers</varname> increases the number of layers
which have a chance to be shared between different images.
Increasing the <varname>maxLayers</varname> increases the number of layers which have a chance to be shared between different images.
</para>
<para>
Modern Docker installations support up to 128 layers, however older
versions support as few as 42.
Modern Docker installations support up to 128 layers, however older versions support as few as 42.
</para>
<para>
If the produced image will not be extended by other Docker builds, it is
safe to set <varname>maxLayers</varname> to <literal>128</literal>. However
it will be impossible to extend the image further.
If the produced image will not be extended by other Docker builds, it is safe to set <varname>maxLayers</varname> to <literal>128</literal>. However it will be impossible to extend the image further.
</para>
<para>
The first (<literal>maxLayers-2</literal>) most "popular" paths will have
their own individual layers, then layer #<literal>maxLayers-1</literal>
will contain all the remaining "unpopular" paths, and finally layer
#<literal>maxLayers</literal> will contain the Image configuration.
The first (<literal>maxLayers-2</literal>) most "popular" paths will have their own individual layers, then layer #<literal>maxLayers-1</literal> will contain all the remaining "unpopular" paths, and finally layer #<literal>maxLayers</literal> will contain the Image configuration.
</para>
<para>
Docker's Layers are not inherently ordered, they are content-addressable
and are not explicitly layered until they are composed in to an Image.
Docker's Layers are not inherently ordered, they are content-addressable and are not explicitly layered until they are composed in to an Image.
This function is analogous to the <command>docker pull</command> command, in
that it can be used to pull a Docker image from a Docker registry. By
default <linkxlink:href="https://hub.docker.com/">Docker Hub</link> is used
to pull images.
This function is analogous to the <command>docker pull</command> command, in that it can be used to pull a Docker image from a Docker registry. By default <linkxlink:href="https://hub.docker.com/">Docker Hub</link> is used to pull images.
</para>
<para>
@@ -445,76 +362,51 @@ pullImage {
<calloutlist>
<calloutarearefs='ex-dockerTools-pullImage-1'>
<para>
<varname>imageName</varname> specifies the name of the image to be
downloaded, which can also include the registry namespace (e.g.
<literal>nixos</literal>). This argument is required.
<varname>imageName</varname> specifies the name of the image to be downloaded, which can also include the registry namespace (e.g. <literal>nixos</literal>). This argument is required.
</para>
</callout>
<calloutarearefs='ex-dockerTools-pullImage-2'>
<para>
<varname>imageDigest</varname> specifies the digest of the image to be
downloaded. This argument is required.
<varname>imageDigest</varname> specifies the digest of the image to be downloaded. This argument is required.
</para>
</callout>
<calloutarearefs='ex-dockerTools-pullImage-3'>
<para>
<varname>finalImageName</varname>, if specified, this is the name of the
image to be created. Note it is never used to fetch the image since we
prefer to rely on the immutable digest ID. By default it's equal to
<varname>imageName</varname>.
<varname>finalImageName</varname>, if specified, this is the name of the image to be created. Note it is never used to fetch the image since we prefer to rely on the immutable digest ID. By default it's equal to <varname>imageName</varname>.
</para>
</callout>
<calloutarearefs='ex-dockerTools-pullImage-4'>
<para>
<varname>finalImageTag</varname>, if specified, this is the tag of the
image to be created. Note it is never used to fetch the image since we
prefer to rely on the immutable digest ID. By default it's
<literal>latest</literal>.
<varname>finalImageTag</varname>, if specified, this is the tag of the image to be created. Note it is never used to fetch the image since we prefer to rely on the immutable digest ID. By default it's <literal>latest</literal>.
</para>
</callout>
<calloutarearefs='ex-dockerTools-pullImage-5'>
<para>
<varname>sha256</varname> is the checksum of the whole fetched image. This
argument is required.
<varname>sha256</varname> is the checksum of the whole fetched image. This argument is required.
</para>
</callout>
<calloutarearefs='ex-dockerTools-pullImage-6'>
<para>
<varname>os</varname>, if specified, is the operating system of the
fetched image. By default it's <literal>linux</literal>.
<varname>os</varname>, if specified, is the operating system of the fetched image. By default it's <literal>linux</literal>.
</para>
</callout>
<calloutarearefs='ex-dockerTools-pullImage-7'>
<para>
<varname>arch</varname>, if specified, is the cpu architecture of the
fetched image. By default it's <literal>x86_64</literal>.
<varname>arch</varname>, if specified, is the cpu architecture of the fetched image. By default it's <literal>x86_64</literal>.
</para>
</callout>
</calloutlist>
<para>
<literal>nix-prefetch-docker</literal> command can be used to get required
image parameters:
<literal>nix-prefetch-docker</literal> command can be used to get required image parameters:
<screen>
<prompt>$ </prompt>nix run nixpkgs.nix-prefetch-docker -c nix-prefetch-docker --image-name mysql --image-tag 5
</screen>
Since a given <varname>imageName</varname> may transparently refer to a
manifest list of images which support multiple architectures and/or
operating systems, you can supply the <option>--os</option> and
<option>--arch</option> arguments to specify exactly which image you want.
By default it will match the OS and architecture of the host the command is
run on.
Since a given <varname>imageName</varname> may transparently refer to a manifest list of images which support multiple architectures and/or operating systems, you can supply the <option>--os</option> and <option>--arch</option> arguments to specify exactly which image you want. By default it will match the OS and architecture of the host the command is run on.
<screen>
<prompt>$ </prompt>nix-prefetch-docker --image-name mysql --image-tag 5 --arch x86_64 --os linux
</screen>
Desired image name and tag can be set using
<option>--final-image-name</option> and <option>--final-image-tag</option>
arguments:
Desired image name and tag can be set using <option>--final-image-name</option> and <option>--final-image-tag</option> arguments:
<screen>
<prompt>$ </prompt>nix-prefetch-docker --image-name mysql --image-tag 5 --final-image-name eu.gcr.io/my-project/mysql --final-image-tag prod
</screen>
@@ -525,17 +417,12 @@ pullImage {
<title>exportImage</title>
<para>
This function is analogous to the <command>docker export</command> command,
in that it can be used to flatten a Docker image that contains multiple
layers. It is in fact the result of the merge of all the layers of the
image. As such, the result is suitable for being imported in Docker with
<command>docker import</command>.
This function is analogous to the <command>docker export</command> command, in that it can be used to flatten a Docker image that contains multiple layers. It is in fact the result of the merge of all the layers of the image. As such, the result is suitable for being imported in Docker with <command>docker import</command>.
</para>
<note>
<para>
Using this function requires the <literal>kvm</literal> device to be
available.
Using this function requires the <literal>kvm</literal> device to be available.
</para>
</note>
@@ -557,14 +444,11 @@ exportImage {
</example>
<para>
The parameters relative to the base image have the same synopsis as
described in <xreflinkend='ssec-pkgs-dockerTools-buildImage'/>, except that
<varname>fromImage</varname> is the only required argument in this case.
The parameters relative to the base image have the same synopsis as described in <xreflinkend='ssec-pkgs-dockerTools-buildImage'/>, except that <varname>fromImage</varname> is the only required argument in this case.
</para>
<para>
The <varname>name</varname> argument is the name of the derivation output,
which defaults to <varname>fromImage.name</varname>.
The <varname>name</varname> argument is the name of the derivation output, which defaults to <varname>fromImage.name</varname>.
</para>
</section>
@@ -572,11 +456,7 @@ exportImage {
<title>shadowSetup</title>
<para>
This constant string is a helper for setting up the base files for managing
users and groups, only if such files don't exist already. It is suitable for
being used in a <varname>runAsRoot</varname>
<xreflinkend='ex-dockerTools-buildImage-runAsRoot'/> script for cases like
in the example below:
This constant string is a helper for setting up the base files for managing users and groups, only if such files don't exist already. It is suitable for being used in a <varname>runAsRoot</varname><xreflinkend='ex-dockerTools-buildImage-runAsRoot'/> script for cases like in the example below:
</para>
<examplexml:id='ex-dockerTools-shadowSetup'>
@@ -598,9 +478,7 @@ buildImage {
</example>
<para>
Creating base files like <literal>/etc/passwd</literal> or
<literal>/etc/login.defs</literal> is necessary for shadow-utils to
manipulate users and groups.
Creating base files like <literal>/etc/passwd</literal> or<literal>/etc/login.defs</literal> is necessary for shadow-utils to manipulate users and groups.
container specification v1.0.0</link>. Beyond that it makes no assumptions
about the container runner you choose to use to run the created container.
<varname>pkgs.ociTools</varname> is a set of functions for creating containers according to the <linkxlink:href="https://github.com/opencontainers/runtime-spec">OCI container specification v1.0.0</link>. Beyond that it makes no assumptions about the container runner you choose to use to run the created container.
This function creates a simple OCI container that runs a single command
inside of it. An OCI container consists of a <varname>config.json</varname>
and a rootfs directory.The nix store of the container will contain all
referenced dependencies of the given command.
This function creates a simple OCI container that runs a single command inside of it. An OCI container consists of a <varname>config.json</varname> and a rootfs directory.The nix store of the container will contain all referenced dependencies of the given command.
</para>
<para>
The parameters of <varname>buildContainer</varname> with an example value
are described below:
The parameters of <varname>buildContainer</varname> with an example value are described below:
</para>
<examplexml:id='ex-ociTools-buildContainer'>
@@ -51,23 +43,17 @@ buildContainer {
<calloutlist>
<calloutarearefs='ex-ociTools-buildContainer-1'>
<para>
<varname>args</varname> specifies a set of arguments to run inside the container.
This is the only required argument for <varname>buildContainer</varname>.
All referenced packages inside the derivation will be made available
inside the container
<varname>args</varname> specifies a set of arguments to run inside the container. This is the only required argument for <varname>buildContainer</varname>. All referenced packages inside the derivation will be made available inside the container
</para>
</callout>
<calloutarearefs='ex-ociTools-buildContainer-2'>
<para>
<varname>mounts</varname> specifies additional mount points chosen by the
user. By default only a minimal set of necessary filesystems are mounted
into the container (e.g procfs, cgroupfs)
<varname>mounts</varname> specifies additional mount points chosen by the user. By default only a minimal set of necessary filesystems are mounted into the container (e.g procfs, cgroupfs)
</para>
</callout>
<calloutarearefs='ex-ociTools-buildContainer-3'>
<para>
<varname>readonly</varname> makes the container's rootfs read-only if it is set to true.
The default value is false <literal>false</literal>.
<varname>readonly</varname> makes the container's rootfs read-only if it is set to true. The default value is false <literal>false</literal>.
<function>makeSnap</function> takes a single named argument,<parameter>meta</parameter>. This argument mirrors <linkxlink:href="https://docs.snapcraft.io/snap-format">the upstream <filename>snap.yaml</filename> format</link> exactly.
</para>
<para>
The <parameter>base</parameter> should not be be specified, as
<function>makeSnap</function> will force set it.
The <parameter>base</parameter> should not be be specified, as<function>makeSnap</function> will force set it.
</para>
<para>
Currently, <function>makeSnap</function> does not support creating GUI
stubs.
Currently, <function>makeSnap</function> does not support creating GUI stubs.
<command>hello</command> will now be the Snapcraft version of the package.
<command>nix-build</command> this expression and install it with<command>snap install ./result --dangerous</command>. <command>hello</command> will now be the Snapcraft version of the package.
</para>
</example>
</section>
@@ -53,21 +45,14 @@
<examplexml:id="ex-snapTools-buildSnap-firefox">
<title>Making a Graphical Snap</title>
<para>
Graphical programs require many more integrations with the host. This
example uses Firefox as an example, because it is one of the most
complicated programs we could package.
Graphical programs require many more integrations with the host. This example uses Firefox as an example, because it is one of the most complicated programs we could package.
<command>nix-example-firefox</command> will now be the Snapcraft version of
the Firefox package.
<command>nix-build</command> this expression and install it with<command>snap install ./result --dangerous</command>. <command>nix-example-firefox</command> will now be the Snapcraft version of the Firefox package.
</para>
<para>
The specific meaning behind plugs can be looked up in the
The specific meaning behind plugs can be looked up in the<linkxlink:href="https://docs.snapcraft.io/supported-interfaces">Snapcraft interface documentation</link>.
<function>buildFHSUserEnv</function> provides a way to build and run
FHS-compatible lightweight sandboxes. It creates an isolated root with bound
<filename>/nix/store</filename>, so its footprint in terms of disk space
needed is quite small. This allows one to run software which is hard or
unfeasible to patch for NixOS -- 3rd-party source trees with FHS assumptions,
games distributed as tarballs, software with integrity checking and/or
external self-updated binaries. It uses Linux namespaces feature to create
temporary lightweight environments which are destroyed after all child
processes exit, without root user rights requirement. Accepted arguments are:
<function>buildFHSUserEnv</function> provides a way to build and run FHS-compatible lightweight sandboxes. It creates an isolated root with bound <filename>/nix/store</filename>, so its footprint in terms of disk space needed is quite small. This allows one to run software which is hard or unfeasible to patch for NixOS -- 3rd-party source trees with FHS assumptions, games distributed as tarballs, software with integrity checking and/or external self-updated binaries. It uses Linux namespaces feature to create temporary lightweight environments which are destroyed after all child processes exit, without root user rights requirement. Accepted arguments are:
</para>
<variablelist>
@@ -33,8 +25,7 @@
</term>
<listitem>
<para>
Packages to be installed for the main host's architecture (i.e. x86_64 on
x86_64 installations). Along with libraries binaries are also installed.
Packages to be installed for the main host's architecture (i.e. x86_64 on x86_64 installations). Along with libraries binaries are also installed.
</para>
</listitem>
</varlistentry>
@@ -44,9 +35,7 @@
</term>
<listitem>
<para>
Packages to be installed for all architectures supported by a host (i.e.
i686 and x86_64 on x86_64 installations). Only libraries are installed by
default.
Packages to be installed for all architectures supported by a host (i.e. i686 and x86_64 on x86_64 installations). Only libraries are installed by default.
</para>
</listitem>
</varlistentry>
@@ -66,8 +55,7 @@
</term>
<listitem>
<para>
Like <literal>extraBuildCommands</literal>, but executed only on multilib
architectures.
Like <literal>extraBuildCommands</literal>, but executed only on multilib architectures.
</para>
</listitem>
</varlistentry>
@@ -77,8 +65,7 @@
</term>
<listitem>
<para>
Additional derivation outputs to be linked for both target and
multi-architecture packages.
Additional derivation outputs to be linked for both target and multi-architecture packages.
</para>
</listitem>
</varlistentry>
@@ -88,8 +75,7 @@
</term>
<listitem>
<para>
Additional commands to be executed for finalizing the derivation with
runner script.
Additional commands to be executed for finalizing the derivation with runner script.
</para>
</listitem>
</varlistentry>
@@ -99,16 +85,14 @@
</term>
<listitem>
<para>
A command that would be executed inside the sandbox and passed all the
command line arguments. It defaults to <literal>bash</literal>.
A command that would be executed inside the sandbox and passed all the command line arguments. It defaults to <literal>bash</literal>.
</para>
</listitem>
</varlistentry>
</variablelist>
<para>
One can create a simple environment using a <literal>shell.nix</literal> like
that:
One can create a simple environment using a <literal>shell.nix</literal> like that:
</para>
<programlisting><![CDATA[
@@ -133,10 +117,6 @@
]]></programlisting>
<para>
Running <literal>nix-shell</literal> would then drop you into a shell with
these libraries and binaries available. You can use this to run closed-source
applications which expect FHS structure without hassles: simply change
<literal>runScript</literal> to the application path, e.g.
<filename>./bin/start.sh</filename> -- relative paths are supported.
Running <literal>nix-shell</literal> would then drop you into a shell with these libraries and binaries available. You can use this to run closed-source applications which expect FHS structure without hassles: simply change <literal>runScript</literal> to the application path, e.g. <filename>./bin/start.sh</filename> -- relative paths are supported.
<function>pkgs.mkShell</function> is a special kind of derivation that is
only useful when using it combined with <command>nix-shell</command>. It will
in fact fail to instantiate when invoked with <command>nix-build</command>.
<function>pkgs.mkShell</function> is a special kind of derivation that is only useful when using it combined with <command>nix-shell</command>. It will in fact fail to instantiate when invoked with <command>nix-build</command>.
Nixpkgs provides a couple of functions that help with building derivations. The most important one, <function>stdenv.mkDerivation</function>, has already been documented above. The following functions wrap <function>stdenv.mkDerivation</function>, making it easier to use in certain cases.
</para>
<variablelist>
<varlistentry>
<term>
<literal>runCommand</literal>
</term>
<listitem>
<para>
This takes three arguments, <literal>name</literal>, <literal>env</literal>, and <literal>buildCommand</literal>. <literal>name</literal> is just the name that Nix will append to the store path in the same way that <literal>stdenv.mkDerivation</literal> uses its <literal>name</literal> attribute. <literal>env</literal> is an attribute set specifying environment variables that will be set for this derivation. These attributes are then passed to the wrapped <literal>stdenv.mkDerivation</literal>. <literal>buildCommand</literal> specifies the commands that will be run to create this derivation. Note that you will need to create <literal>$out</literal> for Nix to register the command as successful.
</para>
<para>
An example of using <literal>runCommand</literal> is provided below.
echo I can write data to the Nix store > $out/message
echo I can also run basic commands like:
echo ls
ls
echo whoami
whoami
echo date
date
''
</programlisting>
</listitem>
</varlistentry>
<varlistentry>
<term>
<literal>runCommandCC</literal>
</term>
<listitem>
<para>
This works just like <literal>runCommand</literal>. The only difference is that it also provides a C compiler in <literal>buildCommand</literal>’s environment. To minimize your dependencies, you should only use this if you are sure you will need a C compiler as part of running your command.
These functions write <literal>text</literal> to the Nix store. This is useful for creating scripts from Nix expressions. <literal>writeTextFile</literal> takes an attribute set and expects two arguments, <literal>name</literal> and <literal>text</literal>. <literal>name</literal> corresponds to the name used in the Nix store path. <literal>text</literal> will be the contents of the file. You can also set <literal>executable</literal> to true to make this file have the executable bit set.
</para>
<para>
Many more commands wrap <literal>writeTextFile</literal> including <literal>writeText</literal>, <literal>writeTextDir</literal>, <literal>writeScript</literal>, and <literal>writeScriptBin</literal>. These are convenience functions over <literal>writeTextFile</literal>.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term>
<literal>symlinkJoin</literal>
</term>
<listitem>
<para>
This can be used to put many derivations into the same directory structure. It works by creating a new derivation and adding symlinks to each of the paths listed. It expects two arguments, <literal>name</literal>, and <literal>paths</literal>. <literal>name</literal> is the name used in the Nix store path for the created derivation. <literal>paths</literal> is a list of paths that will be symlinked. These paths can be to Nix store derivations or any other subdirectory contained within.
Use 2 spaces of indentation per indentation level in Nix expressions, 4
spaces in shell scripts.
Use 2 spaces of indentation per indentation level in Nix expressions, 4 spaces in shell scripts.
</para>
</listitem>
<listitem>
<para>
Do not use tab characters, i.e. configure your editor to use soft tabs.
For instance, use <literal>(setq-default indent-tabs-mode nil)</literal>
in Emacs. Everybody has different tab settings so it’s asking for
trouble.
Do not use tab characters, i.e. configure your editor to use soft tabs. For instance, use <literal>(setq-default indent-tabs-mode nil)</literal> in Emacs. Everybody has different tab settings so it’s asking for trouble.
</para>
</listitem>
<listitem>
<para>
Use <literal>lowerCamelCase</literal> for variable names, not
<literal>UpperCamelCase</literal>. Note, this rule does not apply to
package attribute names, which instead follow the rules in
<xreflinkend="sec-package-naming"/>.
Use <literal>lowerCamelCase</literal> for variable names, not<literal>UpperCamelCase</literal>. Note, this rule does not apply to package attribute names, which instead follow the rules in <xreflinkend="sec-package-naming"/>.
</para>
</listitem>
<listitem>
@@ -52,8 +45,7 @@ foo { arg = ...; }
</listitem>
<listitem>
<para>
In attribute sets or lists that span multiple lines, the attribute names
or list elements should be aligned:
In attribute sets or lists that span multiple lines, the attribute names or list elements should be aligned:
<programlisting>
# A long list.
list = [
@@ -97,8 +89,7 @@ attrs = { x = 1280; y = 1024; };
</listitem>
<listitem>
<para>
Breaking in the middle of a function argument can give hard-to-read code,
like
Breaking in the middle of a function argument can give hard-to-read code, like
<programlisting>
someFunction { x = 1280;
y = 1024; } otherArg
@@ -123,8 +114,7 @@ in someFunction res otherArg yetAnotherArg
</listitem>
<listitem>
<para>
The bodies of functions, asserts, and withs are not indented to prevent a
lot of superfluous indentation levels, i.e.
The bodies of functions, asserts, and withs are not indented to prevent a lot of superfluous indentation levels, i.e.
<programlisting>
{ arg1, arg2 }:
assert system == "i686-linux";
@@ -156,8 +146,7 @@ stdenv.mkDerivation { ...
</listitem>
<listitem>
<para>
Functions should list their expected arguments as precisely as possible.
That is, write
Functions should list their expected arguments as precisely as possible. That is, write
@@ -171,9 +160,7 @@ args: with args; <replaceable>...</replaceable>
</programlisting>
</para>
<para>
For functions that are truly generic in the number of arguments (such as
wrappers around <varname>mkDerivation</varname>) that have some required
arguments, you should write them using an <literal>@</literal>-pattern:
For functions that are truly generic in the number of arguments (such as wrappers around <varname>mkDerivation</varname>) that have some required arguments, you should write them using an <literal>@</literal>-pattern:
and <emphasis>optional</emphasis> in this section are to be interpreted as
described in <linkxlink:href="https://tools.ietf.org/html/rfc2119">RFC
2119</link>. Only <emphasis>emphasized</emphasis> words are to be
interpreted in this way.
The key words <emphasis>must</emphasis>, <emphasis>must not</emphasis>,<emphasis>required</emphasis>, <emphasis>shall</emphasis>, <emphasis>shall not</emphasis>, <emphasis>should</emphasis>, <emphasis>should not</emphasis>, <emphasis>recommended</emphasis>, <emphasis>may</emphasis>, and <emphasis>optional</emphasis> in this section are to be interpreted as described in <linkxlink:href="https://tools.ietf.org/html/rfc2119">RFC 2119</link>. Only <emphasis>emphasized</emphasis> words are to be interpreted in this way.
</para>
<para>
In Nixpkgs, there are generally three different names associated with a
package:
In Nixpkgs, there are generally three different names associated with a package:
<itemizedlist>
<listitem>
<para>
The <varname>name</varname> attribute of the derivation (excluding the
version part). This is what most users see, in particular when using
<command>nix-env</command>.
The <varname>name</varname> attribute of the derivation (excluding the version part). This is what most users see, in particular when using <command>nix-env</command>.
</para>
</listitem>
<listitem>
<para>
The variable name used for the instantiated package in
<filename>all-packages.nix</filename>, and when passing it as a
dependency to other functions. Typically this is called the
<emphasis>package attribute name</emphasis>. This is what Nix expression
authors see. It can also be used when installing using <command>nix-env
-iA</command>.
The variable name used for the instantiated package in<filename>all-packages.nix</filename>, and when passing it as a dependency to other functions. Typically this is called the <emphasis>package attribute name</emphasis>. This is what Nix expression authors see. It can also be used when installing using <command>nix-env -iA</command>.
Most of the time, these are the same. For instance, the package<literal>e2fsprogs</literal> has a <varname>name</varname> attribute <literal>"e2fsprogs-<replaceable>version</replaceable>"</literal>, is bound to the variable name <varname>e2fsprogs</varname> in <filename>all-packages.nix</filename>, and the Nix expression is in <filename>pkgs/os-specific/linux/e2fsprogs/default.nix</filename>.
The <literal>name</literal> attribute <emphasis>must not</emphasis> contain uppercase letters — e.g., <literal>"mplayer-1.0rc2"</literal> instead of <literal>"MPlayer-1.0rc2"</literal>.
</para>
</listitem>
<listitem>
<para>
The version part of the <literal>name</literal> attribute
<emphasis>must</emphasis> start with a digit (following a dash) — e.g.,
<literal>"hello-0.3.1rc2"</literal>.
The version part of the <literal>name</literal> attribute<emphasis>must</emphasis> start with a digit (following a dash) — e.g., <literal>"hello-0.3.1rc2"</literal>.
</para>
</listitem>
<listitem>
<para>
If a package is not a release but a commit from a repository, then the
version part of the name <emphasis>must</emphasis> be the date of that
(fetched) commit. The date <emphasis>must</emphasis> be in
<literal>"YYYY-MM-DD"</literal> format. Also append
<literal>"unstable"</literal> to the name - e.g.,
<literal>"pkgname-unstable-2014-09-23"</literal>.
If a package is not a release but a commit from a repository, then the version part of the name <emphasis>must</emphasis> be the date of that (fetched) commit. The date <emphasis>must</emphasis> be in <literal>"YYYY-MM-DD"</literal> format. Also append <literal>"unstable"</literal> to the name - e.g., <literal>"pkgname-unstable-2014-09-23"</literal>.
</para>
</listitem>
<listitem>
<para>
Dashes in the package name <emphasis>should</emphasis> be preserved in
new variable names, rather than converted to underscores or camel cased
— e.g., <varname>http-parser</varname> instead of
<varname>http_parser</varname> or <varname>httpParser</varname>. The
hyphenated style is preferred in all three package names.
Dashes in the package name <emphasis>should</emphasis> be preserved in new variable names, rather than converted to underscores or camel cased — e.g., <varname>http-parser</varname> instead of <varname>http_parser</varname> or <varname>httpParser</varname>. The hyphenated style is preferred in all three package names.
</para>
</listitem>
<listitem>
<para>
If there are multiple versions of a package, this
<emphasis>should</emphasis> be reflected in the variable names in
<filename>all-packages.nix</filename>, e.g. <varname>json-c-0-9</varname>
and <varname>json-c-0-11</varname>. If there is an obvious “default”
version, make an attribute like <literal>json-c = json-c-0-9;</literal>.
See also <xreflinkend="sec-versioning"/>
If there are multiple versions of a package, this<emphasis>should</emphasis> be reflected in the variable names in <filename>all-packages.nix</filename>, e.g. <varname>json-c-0-9</varname> and <varname>json-c-0-11</varname>. If there is an obvious “default” version, make an attribute like <literal>json-c = json-c-0-9;</literal>. See also <xreflinkend="sec-versioning"/>
Names of files and directories should be in lowercase, with dashes between
words — not in camel case. For instance, it should be
<filename>all-packages.nix</filename>, not
<filename>allPackages.nix</filename> or
<filename>AllPackages.nix</filename>.
Names of files and directories should be in lowercase, with dashes between words — not in camel case. For instance, it should be <filename>all-packages.nix</filename>, not <filename>allPackages.nix</filename> or <filename>AllPackages.nix</filename>.
</para>
<sectionxml:id="sec-hierarchy">
<title>Hierarchy</title>
<para>
Each package should be stored in its own directory somewhere in the
Below are some rules for picking the right category for a package. Many
packages fall under several categories; what matters is the
<emphasis>primary</emphasis> purpose of a package. For example, the
<literal>libxml2</literal> package builds both a library and some tools;
but it’s a library foremost, so it goes under
<filename>pkgs/development/libraries</filename>.
Each package should be stored in its own directory somewhere in the<filename>pkgs/</filename> tree, i.e. in <filename>pkgs/<replaceable>category</replaceable>/<replaceable>subcategory</replaceable>/<replaceable>...</replaceable>/<replaceable>pkgname</replaceable></filename>. Below are some rules for picking the right category for a package. Many packages fall under several categories; what matters is the <emphasis>primary</emphasis> purpose of a package. For example, the <literal>libxml2</literal> package builds both a library and some tools; but it’s a library foremost, so it goes under <filename>pkgs/development/libraries</filename>.
</para>
<para>
When in doubt, consider refactoring the <filename>pkgs/</filename> tree,
e.g. creating new categories or splitting up an existing category.
When in doubt, consider refactoring the <filename>pkgs/</filename> tree, e.g. creating new categories or splitting up an existing category.
Because every version of a package in Nixpkgs creates a potential
maintenance burden, old versions of a package should not be kept unless
there is a good reason to do so. For instance, Nixpkgs contains several
versions of GCC because other packages don’t build with the latest
version of GCC. Other examples are having both the latest stable and latest
pre-release version of a package, or to keep several major releases of an
application that differ significantly in functionality.
Because every version of a package in Nixpkgs creates a potential maintenance burden, old versions of a package should not be kept unless there is a good reason to do so. For instance, Nixpkgs contains several versions of GCC because other packages don’t build with the latest version of GCC. Other examples are having both the latest stable and latest pre-release version of a package, or to keep several major releases of an application that differ significantly in functionality.
</para>
<para>
If there is only one version of a package, its Nix expression should be
named <filename>e2fsprogs/default.nix</filename>. If there are multiple
versions, this should be reflected in the filename, e.g.
<filename>e2fsprogs/1.41.8.nix</filename> and
<filename>e2fsprogs/1.41.9.nix</filename>. The version in the filename
should leave out unnecessary detail. For instance, if we keep the latest
Firefox 2.0.x and 3.5.x versions in Nixpkgs, they should be named
<filename>firefox/2.0.nix</filename> and
<filename>firefox/3.5.nix</filename>, respectively (which, at a given
point, might contain versions <literal>2.0.0.20</literal> and
<literal>3.5.4</literal>). If a version requires many auxiliary files, you
can use a subdirectory for each version, e.g.
<filename>firefox/2.0/default.nix</filename> and
<filename>firefox/3.5/default.nix</filename>.
If there is only one version of a package, its Nix expression should be named <filename>e2fsprogs/default.nix</filename>. If there are multiple versions, this should be reflected in the filename, e.g. <filename>e2fsprogs/1.41.8.nix</filename> and <filename>e2fsprogs/1.41.9.nix</filename>. The version in the filename should leave out unnecessary detail. For instance, if we keep the latest Firefox 2.0.x and 3.5.x versions in Nixpkgs, they should be named <filename>firefox/2.0.nix</filename> and <filename>firefox/3.5.nix</filename>, respectively (which, at a given point, might contain versions <literal>2.0.0.20</literal> and <literal>3.5.4</literal>). If a version requires many auxiliary files, you can use a subdirectory for each version, e.g. <filename>firefox/2.0/default.nix</filename> and <filename>firefox/3.5/default.nix</filename>.
</para>
<para>
All versions of a package <emphasis>must</emphasis> be included in
<filename>all-packages.nix</filename> to make sure that they evaluate
correctly.
All versions of a package <emphasis>must</emphasis> be included in<filename>all-packages.nix</filename> to make sure that they evaluate correctly.
There are multiple ways to fetch a package source in nixpkgs. The general
guideline is that you should package reproducible sources with a high degree
of availability. Right now there is only one fetcher which has mirroring
support and that is <literal>fetchurl</literal>. Note that you should also
prefer protocols which have a corresponding proxy environment variable.
There are multiple ways to fetch a package source in nixpkgs. The general guideline is that you should package reproducible sources with a high degree of availability. Right now there is only one fetcher which has mirroring support and that is <literal>fetchurl</literal>. Note that you should also prefer protocols which have a corresponding proxy environment variable.
</para>
<para>
You can find many source fetch helpers in
<literal>pkgs/build-support/fetch*</literal>.
You can find many source fetch helpers in<literal>pkgs/build-support/fetch*</literal>.
</para>
<para>
In the file <literal>pkgs/top-level/all-packages.nix</literal> you can find
fetch helpers, these have names on the form <literal>fetchFrom*</literal>.
The intention of these are to provide snapshot fetches but using the same
api as some of the version controlled fetchers from
<literal>pkgs/build-support/</literal>. As an example going from bad to
good:
In the file <literal>pkgs/top-level/all-packages.nix</literal> you can find fetch helpers, these have names on the form <literal>fetchFrom*</literal>. The intention of these are to provide snapshot fetches but using the same api as some of the version controlled fetchers from <literal>pkgs/build-support/</literal>. As an example going from bad to good:
Find the value to put as <literal>sha256</literal> by running<literal>nix run -f '<nixpkgs>' nix-prefetch-github -c nix-prefetch-github --rev 1f795f9f44607cc5bec70d1300150bfefcef2aae NixOS nix</literal> or <literal>nix-prefetch-url --unpack https://github.com/NixOS/nix/archive/1f795f9f44607cc5bec70d1300150bfefcef2aae.tar.gz</literal>.
<literal>bzr</literal>, <literal>svn</literal>). Hash is printed to
stdout.
Prefetch URL (with <literal>nix-prefetch-<replaceable>XXX</replaceable><replaceable>URL</replaceable></literal>, where <replaceable>XXX</replaceable> is one of <literal>url</literal>, <literal>git</literal>, <literal>hg</literal>, <literal>cvs</literal>, <literal>bzr</literal>, <literal>svn</literal>). Hash is printed to stdout.
</para>
</listitem>
<listitem>
<para>
Prefetch by package source (with <literal>nix-prefetch-url
'<nixpkgs>' -A <replaceable>PACKAGE</replaceable>.src</literal>,
where <replaceable>PACKAGE</replaceable> is package attribute name). Hash
is printed to stdout.
Prefetch by package source (with <literal>nix-prefetch-url '<nixpkgs>' -A <replaceable>PACKAGE</replaceable>.src</literal>, where <replaceable>PACKAGE</replaceable> is package attribute name). Hash is printed to stdout.
</para>
<para>
This works well when you've upgraded existing package version and want to
find out new hash, but is useless if package can't be accessed by
attribute or package has multiple sources (<literal>.srcs</literal>,
architecture-dependent sources, etc).
This works well when you've upgraded existing package version and want to find out new hash, but is useless if package can't be accessed by attribute or package has multiple sources (<literal>.srcs</literal>, architecture-dependent sources, etc).
</para>
</listitem>
<listitem>
<para>
Upstream provided hash: use it when upstream provides
<literal>sha256</literal> or <literal>sha512</literal> (when upstream
provides <literal>md5</literal>, don't use it, compute
<literal>sha256</literal> instead).
Upstream provided hash: use it when upstream provides<literal>sha256</literal> or <literal>sha512</literal> (when upstream provides <literal>md5</literal>, don't use it, compute <literal>sha256</literal> instead).
</para>
<para>
A little nuance is that <literal>nix-prefetch-*</literal> tools produce
hash encoded with <literal>base32</literal>, but upstream usually provides
hexadecimal (<literal>base16</literal>) encoding. Fetchers understand both
formats. Nixpkgs does not standardize on any one format.
A little nuance is that <literal>nix-prefetch-*</literal> tools produce hash encoded with <literal>base32</literal>, but upstream usually provides hexadecimal (<literal>base16</literal>) encoding. Fetchers understand both formats. Nixpkgs does not standardize on any one format.
</para>
<para>
You can convert between formats with nix-hash, for example:
@@ -927,28 +786,18 @@ src = fetchFromGitHub {
</listitem>
<listitem>
<para>
Extracting hash from local source tarball can be done with
<literal>sha256sum</literal>. Use <literal>nix-prefetch-url
file:///path/to/tarball </literal> if you want base32 hash.
Extracting hash from local source tarball can be done with<literal>sha256sum</literal>. Use <literal>nix-prefetch-url file:///path/to/tarball </literal> if you want base32 hash.
</para>
</listitem>
<listitem>
<para>
Fake hash: set fake hash in package expression, perform build and extract
correct hash from error Nix prints.
Fake hash: set fake hash in package expression, perform build and extract correct hash from error Nix prints.
</para>
<para>
For package updates it is enough to change one symbol to make hash fake.
For new packages, you can use <literal>lib.fakeSha256</literal>,
<literal>lib.fakeSha512</literal> or any other fake hash.
For package updates it is enough to change one symbol to make hash fake. For new packages, you can use <literal>lib.fakeSha256</literal>, <literal>lib.fakeSha512</literal> or any other fake hash.
</para>
<para>
This is last resort method when reconstructing source URL is non-trivial
and <literal>nix-prefetch-url -A</literal> isn't applicable (for example,
one of <literal>kodi</literal> dependencies</link>). The easiest way then
would be replace hash with a fake one and rebuild. Nix build will fail and
error message will contain desired hash.
This is last resort method when reconstructing source URL is non-trivial and <literal>nix-prefetch-url -A</literal> isn't applicable (for example, <linkxlink:href="https://github.com/NixOS/nixpkgs/blob/d2ab091dd308b99e4912b805a5eb088dd536adb9/pkgs/applications/video/kodi/default.nix#L73"> one of <literal>kodi</literal> dependencies</link>). The easiest way then would be replace hash with a fake one and rebuild. Nix build will fail and error message will contain desired hash.
</para>
<warning>
<para>
@@ -962,9 +811,7 @@ src = fetchFromGitHub {
<title>Obtaining hashes securely</title>
<para>
Let's say Man-in-the-Middle (MITM) sits close to your network. Then instead
of fetching source you can fetch malware, and instead of source hash you
get hash of malware. Here are security considerations for this scenario:
Let's say Man-in-the-Middle (MITM) sits close to your network. Then instead of fetching source you can fetch malware, and instead of source hash you get hash of malware. Here are security considerations for this scenario:
</para>
<itemizedlist>
@@ -975,8 +822,7 @@ src = fetchFromGitHub {
</listitem>
<listitem>
<para>
hashes from upstream (in method 3) should be obtained via secure
protocol;
hashes from upstream (in method 3) should be obtained via secure protocol;
</para>
</listitem>
<listitem>
@@ -986,12 +832,7 @@ src = fetchFromGitHub {
</listitem>
<listitem>
<para>
<literal>https://</literal> URLs are not secure in method 5. When
obtaining hashes with fake hash method, TLS checks are disabled. So
refetch source hash from several different networks to exclude MITM
scenario. Alternatively, use fake hash method to make Nix error, but
instead of extracting hash from error, extract
<literal>https://</literal> URL and prefetch it with method 1.
<literal>https://</literal> URLs are not secure in method 5. When obtaining hashes with fake hash method, TLS checks are disabled. So refetch source hash from several different networks to exclude MITM scenario. Alternatively, use fake hash method to make Nix error, but instead of extracting hash from error, extract <literal>https://</literal> URL and prefetch it with method 1.
</para>
</listitem>
</itemizedlist>
@@ -1001,8 +842,7 @@ src = fetchFromGitHub {
<title>Patches</title>
<para>
Patches available online should be retrieved using
<literal>fetchpatch</literal>.
Patches available online should be retrieved using<literal>fetchpatch</literal>.
</para>
<para>
@@ -1018,10 +858,7 @@ patches = [
</para>
<para>
Otherwise, you can add a <literal>.patch</literal> file to the
<literal>nixpkgs</literal> repository. In the interest of keeping our
maintenance burden to a minimum, only patches that are unique to
<literal>nixpkgs</literal> should be added in this way.
Otherwise, you can add a <literal>.patch</literal> file to the<literal>nixpkgs</literal> repository. In the interest of keeping our maintenance burden to a minimum, only patches that are unique to <literal>nixpkgs</literal> should be added in this way.
Nix comes with certain defaults about what packages can and cannot be
installed, based on a package's metadata. By default, Nix will prevent
installation if any of the following criteria are true:
Nix comes with certain defaults about what packages can and cannot be installed, based on a package's metadata. By default, Nix will prevent installation if any of the following criteria are true:
</para>
<itemizedlist>
<listitem>
<para>
The package is thought to be broken, and has had its
<literal>meta.broken</literal> set to <literal>true</literal>.
The package is thought to be broken, and has had its<literal>meta.broken</literal> set to <literal>true</literal>.
</para>
</listitem>
<listitem>
<para>
The package isn't intended to run on the given system, as none of its
<literal>meta.platforms</literal> match the given system.
The package isn't intended to run on the given system, as none of its<literal>meta.platforms</literal> match the given system.
</para>
</listitem>
<listitem>
<para>
The package's <literal>meta.license</literal> is set to a license which is
considered to be unfree.
The package's <literal>meta.license</literal> is set to a license which is considered to be unfree.
</para>
</listitem>
<listitem>
<para>
The package has known security vulnerabilities but has not or can not be
updated for some reason, and a list of issues has been entered in to the
The package has known security vulnerabilities but has not or can not be updated for some reason, and a list of issues has been entered in to the package's <literal>meta.knownVulnerabilities</literal>.
</para>
</listitem>
</itemizedlist>
<para>
Note that all this is checked during evaluation already, and the check
includes any package that is evaluated. In particular, all build-time
dependencies are checked. <literal>nix-env -qa</literal> will (attempt to)
hide any packages that would be refused.
Note that all this is checked during evaluation already, and the check includes any package that is evaluated. In particular, all build-time dependencies are checked. <literal>nix-env -qa</literal> will (attempt to) hide any packages that would be refused.
</para>
<para>
Each of these criteria can be altered in the nixpkgs configuration.
</para>
<para>
The nixpkgs configuration for a NixOS system is set in the
<literal>configuration.nix</literal>, as in the following example:
The nixpkgs configuration for a NixOS system is set in the<literal>configuration.nix</literal>, as in the following example:
<programlisting>
{
nixpkgs.config = {
@@ -53,13 +42,10 @@
};
}
</programlisting>
However, this does not allow unfree software for individual users. Their
configurations are managed separately.
However, this does not allow unfree software for individual users. Their configurations are managed separately.
</para>
<para>
A user's of nixpkgs configuration is stored in a user-specific configuration
file located at <filename>~/.config/nixpkgs/config.nix</filename>. For
example:
A user's of nixpkgs configuration is stored in a user-specific configuration file located at <filename>~/.config/nixpkgs/config.nix</filename>. For example:
<programlisting>
{
allowUnfree = true;
@@ -67,31 +53,25 @@
</programlisting>
</para>
<para>
Note that we are not able to test or build unfree software on Hydra due to
policy. Most unfree licenses prohibit us from either executing or
distributing the software.
Note that we are not able to test or build unfree software on Hydra due to policy. Most unfree licenses prohibit us from either executing or distributing the software.
</para>
<sectionxml:id="sec-allow-broken">
<title>Installing broken packages</title>
<para>
There are two ways to try compiling a package which has been marked as
broken.
There are two ways to try compiling a package which has been marked as broken.
</para>
<itemizedlist>
<listitem>
<para>
For allowing the build of a broken package once, you can use an
environment variable for a single invocation of the nix tools:
For allowing the build of a broken package once, you can use an environment variable for a single invocation of the nix tools:
For permanently allowing broken packages to be built, you may add
<literal>allowUnsupportedSystem = true;</literal> to your user's
configuration file, like this:
For permanently allowing broken packages to be built, you may add<literal>allowUnsupportedSystem = true;</literal> to your user's configuration file, like this:
<programlisting>
{
allowUnsupportedSystem = true;
@@ -132,42 +108,29 @@
</itemizedlist>
<para>
The difference between a package being unsupported on some system and being
broken is admittedly a bit fuzzy. If a program <emphasis>ought</emphasis> to
work on a certain platform, but doesn't, the platform should be included in
<literal>meta.platforms</literal>, but marked as broken with e.g.
<literal>meta.broken = !hostPlatform.isWindows</literal>. Of course, this
begs the question of what "ought" means exactly. That is left to the package
maintainer.
The difference between a package being unsupported on some system and being broken is admittedly a bit fuzzy. If a program <emphasis>ought</emphasis> to work on a certain platform, but doesn't, the platform should be included in <literal>meta.platforms</literal>, but marked as broken with e.g. <literal>meta.broken = !hostPlatform.isWindows</literal>. Of course, this begs the question of what "ought" means exactly. That is left to the package maintainer.
</para>
</section>
<sectionxml:id="sec-allow-unfree">
<title>Installing unfree packages</title>
<para>
There are several ways to tweak how Nix handles a package which has been
marked as unfree.
There are several ways to tweak how Nix handles a package which has been marked as unfree.
</para>
<itemizedlist>
<listitem>
<para>
To temporarily allow all unfree packages, you can use an environment
variable for a single invocation of the nix tools:
To temporarily allow all unfree packages, you can use an environment variable for a single invocation of the nix tools:
It is possible to permanently allow individual unfree packages, while
still blocking unfree packages by default using the
<literal>allowUnfreePredicate</literal> configuration option in the user
configuration file.
It is possible to permanently allow individual unfree packages, while still blocking unfree packages by default using the <literal>allowUnfreePredicate</literal> configuration option in the user configuration file.
</para>
<para>
This option is a function which accepts a package as a parameter, and
returns a boolean. The following example configuration accepts a package
and always returns false:
This option is a function which accepts a package as a parameter, and returns a boolean. The following example configuration accepts a package and always returns false:
<programlisting>
{
allowUnfreePredicate = (pkg: false);
@@ -175,29 +138,23 @@
</programlisting>
</para>
<para>
For a more useful example, try the following. This configuration only
allows unfree packages named flash player and visual studio code:
For a more useful example, try the following. This configuration only allows unfree packages named flash player and visual studio code:
It is also possible to whitelist and blacklist licenses that are specifically acceptable or not acceptable, using <literal>whitelistedLicenses</literal> and <literal>blacklistedLicenses</literal>, respectively.
</para>
<para>
The following example configuration whitelists the licenses
<literal>amd</literal> and <literal>wtfpl</literal>:
The following example configuration whitelists the licenses<literal>amd</literal> and <literal>wtfpl</literal>:
<programlisting>
{
whitelistedLicenses = with stdenv.lib.licenses; [ amd wtfpl ];
@@ -205,8 +162,7 @@
</programlisting>
</para>
<para>
The following example configuration blacklists the <literal>gpl3</literal>
and <literal>agpl3</literal> licenses:
The following example configuration blacklists the <literal>gpl3</literal> and <literal>agpl3</literal> licenses:
<programlisting>
{
blacklistedLicenses = with stdenv.lib.licenses; [ agpl3 gpl3 ];
@@ -217,37 +173,29 @@
</itemizedlist>
<para>
A complete list of licenses can be found in the file
<filename>lib/licenses.nix</filename> of the nixpkgs tree.
A complete list of licenses can be found in the file<filename>lib/licenses.nix</filename> of the nixpkgs tree.
</para>
</section>
<sectionxml:id="sec-allow-insecure">
<title>Installing insecure packages</title>
<para>
There are several ways to tweak how Nix handles a package which has been
marked as insecure.
There are several ways to tweak how Nix handles a package which has been marked as insecure.
</para>
<itemizedlist>
<listitem>
<para>
To temporarily allow all insecure packages, you can use an environment
variable for a single invocation of the nix tools:
To temporarily allow all insecure packages, you can use an environment variable for a single invocation of the nix tools:
It is possible to permanently allow individual insecure packages, while
still blocking other insecure packages by default using the
<literal>permittedInsecurePackages</literal> configuration option in the
user configuration file.
It is possible to permanently allow individual insecure packages, while still blocking other insecure packages by default using the <literal>permittedInsecurePackages</literal> configuration option in the user configuration file.
</para>
<para>
The following example configuration permits the installation of the
hypothetically insecure package <literal>hello</literal>, version
<literal>1.2.3</literal>:
The following example configuration permits the installation of the hypothetically insecure package <literal>hello</literal>, version <literal>1.2.3</literal>:
<programlisting>
{
permittedInsecurePackages = [
@@ -259,27 +207,21 @@
</listitem>
<listitem>
<para>
It is also possible to create a custom policy around which insecure
It is also possible to create a custom policy around which insecure packages to allow and deny, by overriding the <literal>allowInsecurePredicate</literal> configuration option.
</para>
<para>
The <literal>allowInsecurePredicate</literal> option is a function which
accepts a package and returns a boolean, much like
<literal>allowUnfreePredicate</literal>.
The <literal>allowInsecurePredicate</literal> option is a function which accepts a package and returns a boolean, much like <literal>allowUnfreePredicate</literal>.
</para>
<para>
The following configuration example only allows insecure packages with
very short names:
The following configuration example only allows insecure packages with very short names:
Note that <literal>permittedInsecurePackages</literal> is only checked if
<literal>allowInsecurePredicate</literal> is not specified.
Note that <literal>permittedInsecurePackages</literal> is only checked if<literal>allowInsecurePredicate</literal> is not specified.
</para>
</listitem>
</itemizedlist>
@@ -289,10 +231,7 @@
<title>Modify packages via <literal>packageOverrides</literal></title>
<para>
You can define a function called <varname>packageOverrides</varname> in your
local <filename>~/.config/nixpkgs/config.nix</filename> to override Nix
packages. It must be a function that takes pkgs as an argument and returns a
modified set of packages.
You can define a function called <varname>packageOverrides</varname> in your local <filename>~/.config/nixpkgs/config.nix</filename> to override Nix packages. It must be a function that takes pkgs as an argument and returns a modified set of packages.
<programlisting>
{
packageOverrides = pkgs: rec {
@@ -309,15 +248,7 @@
<title>Build an environment</title>
<para>
Using <literal>packageOverrides</literal>, it is possible to manage
packages declaratively. This means that we can list all of our desired
packages within a declarative Nix expression. For example, to have
<literal>nox</literal>, and <literal>silver-searcher</literal>, we could
use the following in <filename>~/.config/nixpkgs/config.nix</filename>:
Using <literal>packageOverrides</literal>, it is possible to manage packages declaratively. This means that we can list all of our desired packages within a declarative Nix expression. For example, to have <literal>aspell</literal>, <literal>bc</literal>, <literal>ffmpeg</literal>, <literal>coreutils</literal>, <literal>gdb</literal>, <literal>nixUnstable</literal>, <literal>emscripten</literal>, <literal>jq</literal>, <literal>nox</literal>, and <literal>silver-searcher</literal>, we could use the following in <filename>~/.config/nixpkgs/config.nix</filename>:
</para>
<screen>
@@ -343,13 +274,7 @@
</screen>
<para>
To install it into our environment, you can just run <literal>nix-env -iA
nixpkgs.myPackages</literal>. If you want to load the packages to be built
from a working copy of <literal>nixpkgs</literal> you just run
<literal>nix-env -f. -iA myPackages</literal>. To explore what's been
installed, just look through <filename>~/.nix-profile/</filename>. You can
see that a lot of stuff has been installed. Some of this stuff is useful
some of it isn't. Let's tell Nixpkgs to only link the stuff that we want:
To install it into our environment, you can just run <literal>nix-env -iA nixpkgs.myPackages</literal>. If you want to load the packages to be built from a working copy of <literal>nixpkgs</literal> you just run <literal>nix-env -f. -iA myPackages</literal>. To explore what's been installed, just look through <filename>~/.nix-profile/</filename>. You can see that a lot of stuff has been installed. Some of this stuff is useful some of it isn't. Let's tell Nixpkgs to only link the stuff that we want:
</para>
<screen>
@@ -376,12 +301,7 @@
</screen>
<para>
<literal>pathsToLink</literal> tells Nixpkgs to only link the paths listed
which gets rid of the extra stuff in the profile. <filename>/bin</filename>
and <filename>/share</filename> are good defaults for a user environment,
getting rid of the clutter. If you are running on Nix on MacOS, you may
want to add another path as well, <filename>/Applications</filename>, that
makes GUI apps available.
<literal>pathsToLink</literal> tells Nixpkgs to only link the paths listed which gets rid of the extra stuff in the profile. <filename>/bin</filename> and <filename>/share</filename> are good defaults for a user environment, getting rid of the clutter. If you are running on Nix on MacOS, you may want to add another path as well, <filename>/Applications</filename>, that makes GUI apps available.
</para>
</section>
@@ -389,13 +309,7 @@
<title>Getting documentation</title>
<para>
After building that new environment, look through
<filename>~/.nix-profile</filename> to make sure everything is there that
we wanted. Discerning readers will note that some files are missing. Look
inside <filename>~/.nix-profile/share/man/man1/</filename> to verify this.
There are no man pages for any of the Nix tools! This is because some
packages like Nix have multiple outputs for things like documentation (see
section 4). Let's make Nix install those as well.
After building that new environment, look through<filename>~/.nix-profile</filename> to make sure everything is there that we wanted. Discerning readers will note that some files are missing. Look inside <filename>~/.nix-profile/share/man/man1/</filename> to verify this. There are no man pages for any of the Nix tools! This is because some packages like Nix have multiple outputs for things like documentation (see section 4). Let's make Nix install those as well.
</para>
<screen>
@@ -422,9 +336,7 @@
</screen>
<para>
This provides us with some useful documentation for using our packages.
However, if we actually want those manpages to be detected by man, we need
to set up our environment. This can also be managed within Nix expressions.
This provides us with some useful documentation for using our packages. However, if we actually want those manpages to be detected by man, we need to set up our environment. This can also be managed within Nix expressions.
</para>
<screen>
@@ -460,9 +372,7 @@
</screen>
<para>
For this to work fully, you must also have this script sourced when you are
logged in. Try adding something like this to your
<filename>~/.profile</filename> file:
For this to work fully, you must also have this script sourced when you are logged in. Try adding something like this to your <filename>~/.profile</filename> file:
</para>
<screen>
@@ -477,8 +387,7 @@ fi
</screen>
<para>
Now just run <literal>source $HOME/.profile</literal> and you can starting
loading man pages from your environent.
Now just run <literal>source $HOME/.profile</literal> and you can starting loading man pages from your environent.
</para>
</section>
@@ -486,9 +395,7 @@ fi
<title>GNU info setup</title>
<para>
Configuring GNU info is a little bit trickier than man pages. To work
correctly, info needs a database to be generated. This can be done with
some small modifications to our environment scripts.
Configuring GNU info is a little bit trickier than man pages. To work correctly, info needs a database to be generated. This can be done with some small modifications to our environment scripts.
</para>
<screen>
@@ -534,11 +441,7 @@ fi
</screen>
<para>
<literal>postBuild</literal> tells Nixpkgs to run a command after building
the environment. In this case, <literal>install-info</literal> adds the
installed info pages to <literal>dir</literal> which is GNU info's default
root node. Note that <literal>texinfoInteractive</literal> is added to the
environment to give the <literal>install-info</literal> command.
<literal>postBuild</literal> tells Nixpkgs to run a command after building the environment. In this case, <literal>install-info</literal> adds the installed info pages to <literal>dir</literal> which is GNU info's default root node. Note that <literal>texinfoInteractive</literal> is added to the environment to give the <literal>install-info</literal> command.
"Cross-compilation" means compiling a program on one machine for another
type of machine. 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. However, there are
significant advantages to rigorously distinguishing between build-time and
run-time environments! Significant, because the benefits apply 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.
"Cross-compilation" means compiling a program on one machine for another type of machine. 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. However, there are significant advantages to rigorously distinguishing between build-time and run-time environments! Significant, because the benefits apply 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.
</para>
<para>
This chapter will be organized in three parts. First, it will describe the
basics of how to package software in a way that supports cross-compilation.
Second, it will describe how to use Nixpkgs when cross-compiling. Third, it
will describe the internal infrastructure supporting cross-compilation.
This chapter will be organized in three parts. First, it will describe the basics of how to package software in a way that supports cross-compilation. Second, it will describe how to use Nixpkgs when cross-compiling. Third, it will describe the internal infrastructure supporting cross-compilation.
of GNU autoconf</link>. We distinguish between 3 types of platforms when
building a derivation: <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
will run. The third attribute, <wordasword>target</wordasword>, is relevant
only for certain specific compilers and build tools.
Nixpkgs follows the<link
xlink:href="https://gcc.gnu.org/onlinedocs/gccint/Configure-Terms.html">conventions of GNU autoconf</link>. We distinguish between 3 types of platforms when building a derivation: <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 will run. The third attribute, <wordasword>target</wordasword>, is relevant only for certain specific compilers and build tools.
</para>
<para>
In Nixpkgs, these three platforms are defined as attribute sets under the
and <literal>targetPlatform</literal>. They are always defined as
attributes in the standard environment. That means one can access them
like:
In Nixpkgs, these three platforms are defined as attribute sets under the names <literal>buildPlatform</literal>, <literal>hostPlatform</literal>, and <literal>targetPlatform</literal>. They are always defined as attributes in the standard environment. That means one can access them like:
The "build platform" is the platform on which a package is built. Once
someone has a built package, or pre-built binary package, the build
platform should not matter and can be ignored.
The "build platform" is the platform on which a package is built. Once someone has a built package, or pre-built binary package, the build platform should not matter and can be ignored.
</para>
</listitem>
</varlistentry>
@@ -76,9 +48,7 @@
</term>
<listitem>
<para>
The "host platform" is the platform on which a package will be run. This
is the simplest platform to understand, but also the one with the worst
name.
The "host platform" is the platform on which a package will be run. This is the simplest platform to understand, but also the one with the worst name.
</para>
</listitem>
</varlistentry>
@@ -88,44 +58,23 @@
</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" 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.
</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 of specifying this single "target
platform" is thus pushed to build time of the compiler. The root cause
of this is that the compiler (which will be run on the host) and the
standard library/runtime (which will be run on the target) are built by
a single build process.
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 of specifying this single "target platform" is thus pushed to build time of the compiler. The root cause of this is that the compiler (which will be run on the host) and the standard library/runtime (which will be run on the target) are built by a single build process.
</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.
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 existence 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.
Although the existence 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.
</para>
</listitem>
</varlistentry>
</variablelist>
<para>
The exact schema these fields follow is a bit ill-defined due to a long and
convoluted evolution, but this is slowly being cleaned up. You can see
examples of ones used in practice in
<literal>lib.systems.examples</literal>; note how they are not all very
consistent. For now, here are few fields can count on them containing:
The exact schema these fields follow is a bit ill-defined due to a long and convoluted evolution, but this is slowly being cleaned up. You can see examples of ones used in practice in <literal>lib.systems.examples</literal>; note how they are not all very consistent. For now, here are few fields can count on them containing:
</para>
<variablelist>
@@ -135,13 +84,7 @@
</term>
<listitem>
<para>
This is a two-component shorthand for the platform. Examples of this
would be "x86_64-darwin" and "i686-linux"; see
<literal>lib.systems.doubles</literal> for more. The first component
corresponds to the CPU architecture of the platform and the second to
the operating system of the platform (<literal>[cpu]-[os]</literal>).
This format has built-in support in Nix, such as the
This is a two-component shorthand for the platform. Examples of this would be "x86_64-darwin" and "i686-linux"; see <literal>lib.systems.doubles</literal> for more. The first component corresponds to the CPU architecture of the platform and the second to the operating system of the platform (<literal>[cpu]-[os]</literal>). This format has built-in support in Nix, such as the <varname>builtins.currentSystem</varname> impure string.
</para>
</listitem>
</varlistentry>
@@ -151,15 +94,7 @@
</term>
<listitem>
<para>
This is a 3- or 4- component shorthand for the platform. Examples of
this would be <literal>x86_64-unknown-linux-gnu</literal> and
<literal>aarch64-apple-darwin14</literal>. This is a standard format
called the "LLVM target triple", as they are pioneered by LLVM. In the
4-part form, this corresponds to
<literal>[cpu]-[vendor]-[os]-[abi]</literal>. This format is strictly
more informative than the "Nix host double", as the previous format
could analogously be termed. This needs a better name than
<varname>config</varname>!
This is a 3- or 4- component shorthand for the platform. Examples of this would be <literal>x86_64-unknown-linux-gnu</literal> and <literal>aarch64-apple-darwin14</literal>. This is a standard format called the "LLVM target triple", as they are pioneered by LLVM. In the 4-part form, this corresponds to <literal>[cpu]-[vendor]-[os]-[abi]</literal>. This format is strictly more informative than the "Nix host double", as the previous format could analogously be termed. This needs a better name than <varname>config</varname>!
</para>
</listitem>
</varlistentry>
@@ -169,10 +104,7 @@
</term>
<listitem>
<para>
This is a Nix representation of a parsed LLVM target triple with
white-listed components. This can be specified directly, or actually
parsed from the <varname>config</varname>. See
<literal>lib.systems.parse</literal> for the exact representation.
This is a Nix representation of a parsed LLVM target triple with white-listed components. This can be specified directly, or actually parsed from the <varname>config</varname>. See <literal>lib.systems.parse</literal> for the exact representation.
</para>
</listitem>
</varlistentry>
@@ -182,10 +114,7 @@
</term>
<listitem>
<para>
This is a string identifying the standard C library used. Valid
identifiers include "glibc" for GNU libc, "libSystem" for Darwin's
Libsystem, and "uclibc" for µClibc. It should probably be refactored to
use the module system, like <varname>parse</varname>.
This is a string identifying the standard C library used. Valid identifiers include "glibc" for GNU libc, "libSystem" for Darwin's Libsystem, and "uclibc" for µClibc. It should probably be refactored to use the module system, like <varname>parse</varname>.
</para>
</listitem>
</varlistentry>
@@ -195,10 +124,7 @@
</term>
<listitem>
<para>
These predicates are defined in <literal>lib.systems.inspect</literal>,
and slapped onto every platform. They are superior to the ones in
<varname>stdenv</varname> as they force the user to be explicit about
which platform they are inspecting. Please use these instead of those.
These predicates are defined in <literal>lib.systems.inspect</literal>, and slapped onto every platform. They are superior to the ones in <varname>stdenv</varname> as they force the user to be explicit about which platform they are inspecting. Please use these instead of those.
</para>
</listitem>
</varlistentry>
@@ -208,11 +134,7 @@
</term>
<listitem>
<para>
This is, quite frankly, a dumping ground of ad-hoc settings (it's an
attribute set). See <literal>lib.systems.platforms</literal> for
examples—there's hopefully one in there that will work verbatim for
each platform that is working. Please help us triage these flags and
give them better homes!
This is, quite frankly, a dumping ground of ad-hoc settings (it's an attribute set). See <literal>lib.systems.platforms</literal> for examples—there's hopefully one in there that will work verbatim for each platform that is working. Please help us triage these flags and give them better homes!
</para>
</listitem>
</varlistentry>
@@ -224,62 +146,33 @@
<note>
<para>
This is a rather philosophical description that isn't very
Nixpkgs-specific. For an overview of all the relevant attributes given to
<varname>mkDerivation</varname>, see
<xref
linkend="ssec-stdenv-dependencies"/>. For a description of how
This is a rather philosophical description that isn't very Nixpkgs-specific. For an overview of all the relevant attributes given to <varname>mkDerivation</varname>, see <xref
linkend="ssec-stdenv-dependencies"/>. For a description of how everything is implemented, see <xreflinkend="ssec-cross-dependency-implementation"/>.
</para>
</note>
<para>
In this section we explore the relationship between both runtime and
build-time dependencies and the 3 Autoconf platforms.
In this section we explore the relationship between both runtime and build-time dependencies and the 3 Autoconf platforms.
</para>
<para>
A run time dependency between two packages requires that their host
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.
A run time dependency between two packages requires that their host 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, has a shift in platforms between the
depending package and the depended-on package. "build time dependency"
means 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.
A build time dependency, however, has a shift in platforms between the depending package and the depended-on package. "build time dependency" means 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.
</para>
<para>
If both the dependency and depending packages aren't compilers or other
machine-code-producing tools, we're done. And indeed
<varname>buildInputs</varname> and <varname>nativeBuildInputs</varname>
have covered these simpler build-time and run-time (respectively) changes
for many years. But if the dependency does produce machine code, we might
need to worry about its target platform too. In principle, that target
platform might be any of the depending package's build, host, or target
platforms, but we prohibit dependencies from a "later" platform to an
earlier platform to limit confusion because we've never seen a legitimate
use for them.
If both the dependency and depending packages aren't compilers or other machine-code-producing tools, we're done. And indeed <varname>buildInputs</varname> and <varname>nativeBuildInputs</varname> have covered these simpler build-time and run-time (respectively) changes for many years. But if the dependency does produce machine code, we might need to worry about its target platform too. In principle, that target platform might be any of the depending package's build, host, or target platforms, but we prohibit dependencies from a "later" platform to an earlier platform to limit confusion because we've never seen a legitimate use for them.
</para>
<para>
Finally, if the depending package is a compiler or other
machine-code-producing tool, it might need dependencies that run at "emit
time". This is for compilers that (regrettably) insist on being built
together with their source langauges' standard libraries. Assuming build !=
host != target, a run-time dependency of the standard library cannot be run
at the compiler's build time or run time, but only at the run time of code
emitted by the compiler.
Finally, if the depending package is a compiler or other machine-code-producing tool, it might need dependencies that run at "emit time". This is for compilers that (regrettably) insist on being built together with their source langauges' standard libraries. Assuming build != host != target, a run-time dependency of the standard library cannot be run at the compiler's build time or run time, but only at the run time of code emitted by the compiler.
</para>
<para>
Putting this all together, that means we have dependencies in the form
"host → target", in at most the following six combinations:
Putting this all together, that means we have dependencies in the form "host → target", in at most the following six combinations:
<table>
<caption>Possible dependency types</caption>
<thead>
@@ -318,16 +211,7 @@
</para>
<para>
Some examples will make this table clearer. Suppose there's some package
that is being built with a <literal>(build, host, target)</literal>
platform triple of <literal>(foo, bar, baz)</literal>. If it has a
build-time library dependency, that would be a "host → build" dependency
with a triple of <literal>(foo, foo, *)</literal> (the target platform is
irrelevant). If it needs a compiler to be built, that would be a "build →
host" dependency with a triple of <literal>(foo, foo, *)</literal> (the
target platform is irrelevant). That compiler, would be built with another
compiler, also "build → host" dependency, with a triple of <literal>(foo,
foo, foo)</literal>.
Some examples will make this table clearer. Suppose there's some package that is being built with a <literal>(build, host, target)</literal> platform triple of <literal>(foo, bar, baz)</literal>. If it has a build-time library dependency, that would be a "host → build" dependency with a triple of <literal>(foo, foo, *)</literal> (the target platform is irrelevant). If it needs a compiler to be built, that would be a "build → host" dependency with a triple of <literal>(foo, foo, *)</literal> (the target platform is irrelevant). That compiler, would be built with another compiler, also "build → host" dependency, with a triple of <literal>(foo, foo, foo)</literal>.
</para>
</section>
@@ -335,20 +219,14 @@
<title>Cross packaging cookbook</title>
<para>
Some frequently encountered problems when packaging for cross-compilation
should be answered here. Ideally, the information above is exhaustive, so
this section cannot provide any new information, but it is 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!
Some frequently encountered problems when packaging for cross-compilation should be answered here. Ideally, the information above is exhaustive, so this section cannot provide any new information, but it is 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!
What if my package's build system needs to build a C program to be run
under the build environment?
What if my package's build system needs to build a C program to be run under the build environment?
</para>
</question>
<answer>
@@ -366,11 +244,7 @@
</question>
<answer>
<para>
Many packages assume that an unprefixed <command>ar</command> is
available, but Nix doesn't provide one. It only provides a prefixed one,
just as it only does for all the other binutils programs. It may be
necessary to patch the package to fix the build system to use a prefixed
`ar`.
Many packages assume that an unprefixed <command>ar</command> is available, but Nix doesn't provide one. It only provides a prefixed one, just as it only does for all the other binutils programs. It may be necessary to patch the package to fix the build system to use a prefixed `ar`.
Add it to your <function>mkDerivation</function> invocation.
</para>
</answer>
@@ -395,82 +269,32 @@
<title>Cross-building packages</title>
<para>
Nixpkgs can be instantiated with <varname>localSystem</varname> alone, in
which case there is no cross-compiling and everything is built by and for
that system, 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:
Nixpkgs can be instantiated with <varname>localSystem</varname> alone, in which case there is no cross-compiling and everything is built by and for that system, 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>
</para>
<note>
<para>
Eventually we would like to make these platform examples an unnecessary
convenience so that
Eventually we would like to make these platform examples an unnecessary convenience so that
tracks this inconvenience along with its root cause in crufty configuration
options.
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. Additionally,
<varname>libc</varname> will be inferred from <varname>parse</varname>.
Finally, <literal>localSystem.system</literal> is also
<emphasis>impurely</emphasis> inferred based on the platform evaluation
occurs. This means it is often not necessary to pass
<varname>localSystem</varname> at all, as in the command-line example in the
previous paragraph.
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. Additionally, <varname>libc</varname> will be inferred from <varname>parse</varname>. Finally, <literal>localSystem.system</literal> is also <emphasis>impurely</emphasis> inferred based on the platform evaluation occurs. This means it is often not necessary to pass <varname>localSystem</varname> at all, as in the command-line example in the previous paragraph.
</para>
<note>
<para>
Many sources (manual, wiki, etc) probably mention passing
<varname>system</varname>, <varname>platform</varname>, along with the
optional <varname>crossSystem</varname> to nixpkgs: <literal>import
}</literal>. Passing those two instead of <varname>localSystem</varname> is
still supported for compatibility, but is discouraged. Indeed, much of the
inference we do for these parameters is motivated by compatibility as much
as convenience.
Many sources (manual, wiki, etc) probably mention passing<varname>system</varname>, <varname>platform</varname>, along with the optional <varname>crossSystem</varname> to nixpkgs: <literal>import <nixpkgs> { system = ..; platform = ..; crossSystem = ..; }</literal>. Passing those two instead of <varname>localSystem</varname> is still supported for compatibility, but is discouraged. Indeed, much of the inference we do for these parameters is motivated by compatibility as much as convenience.
</para>
</note>
<para>
One would think that <varname>localSystem</varname> and
<varname>crossSystem</varname> overlap horribly with the three
<varname>hostPlatform,</varname> and <varname>targetPlatform</varname>; see
<varname>stage.nix</varname> or the manual). Actually, those identifiers are
purposefully not used here to draw a subtle but important distinction: While
the granularity of having 3 platforms is necessary to properly *build*
packages, it is overkill for specifying the user's *intent* when making a
build plan or package set. A simple "build vs deploy" dichotomy is adequate:
the sliding window principle described in the previous section shows how to
interpolate between the these two "end points" to get the 3 platform triple
for each bootstrapping stage. That means for any package a given package
set, even those not bound on the top level but only reachable via
dependencies or <varname>buildPackages</varname>, the three platforms will
be defined as one of <varname>localSystem</varname> or
<varname>crossSystem</varname>, with the former replacing the latter as one
traverses build-time dependencies. A last simple difference is that
<varname>crossSystem</varname> should be null when one doesn't want to
cross-compile, while the <varname>*Platform</varname>s are always non-null.
<varname>localSystem</varname> is always non-null.
One would think that <varname>localSystem</varname> and<varname>crossSystem</varname> overlap horribly with the three <varname>*Platforms</varname> (<varname>buildPlatform</varname>, <varname>hostPlatform,</varname> and <varname>targetPlatform</varname>; see <varname>stage.nix</varname> or the manual). Actually, those identifiers are purposefully not used here to draw a subtle but important distinction: While the granularity of having 3 platforms is necessary to properly *build* packages, it is overkill for specifying the user's *intent* when making a build plan or package set. A simple "build vs deploy" dichotomy is adequate: the sliding window principle described in the previous section shows how to interpolate between the these two "end points" to get the 3 platform triple for each bootstrapping stage. That means for any package a given package set, even those not bound on the top level but only reachable via dependencies or <varname>buildPackages</varname>, the three platforms will be defined as one of <varname>localSystem</varname> or <varname>crossSystem</varname>, with the former replacing the latter as one traverses build-time dependencies. A last simple difference is that <varname>crossSystem</varname> should be null when one doesn't want to cross-compile, while the <varname>*Platform</varname>s are always non-null. <varname>localSystem</varname> is always non-null.
linkend="ssec-cross-dependency-categorization"/> are specified as
lists of derivations given to <varname>mkDerivation</varname>, as
documented in <xreflinkend="ssec-stdenv-dependencies"/>. In short,
each list of dependencies for "host → target" of "foo → bar" is called
<varname>depsFooBar</varname>, with exceptions for backwards
compatibility that <varname>depsBuildHost</varname> is instead called
<varname>nativeBuildInputs</varname> and <varname>depsHostTarget</varname>
is instead called <varname>buildInputs</varname>. Nixpkgs is now structured
so that each <varname>depsFooBar</varname> is automatically taken from
<varname>pkgsFooBar</varname>. (These <varname>pkgsFooBar</varname>s are
quite new, so there is no special case for
<varname>nativeBuildInputs</varname> and <varname>buildInputs</varname>.)
For example, <varname>pkgsBuildHost.gcc</varname> should be used at
build-time, while <varname>pkgsHostTarget.gcc</varname> should be used at
run-time.
The categorizes of dependencies developed in<xref
linkend="ssec-cross-dependency-categorization"/> are specified as lists of derivations given to <varname>mkDerivation</varname>, as documented in <xreflinkend="ssec-stdenv-dependencies"/>. In short, each list of dependencies for "host → target" of "foo → bar" is called <varname>depsFooBar</varname>, with exceptions for backwards compatibility that <varname>depsBuildHost</varname> is instead called <varname>nativeBuildInputs</varname> and <varname>depsHostTarget</varname> is instead called <varname>buildInputs</varname>. Nixpkgs is now structured so that each <varname>depsFooBar</varname> is automatically taken from <varname>pkgsFooBar</varname>. (These <varname>pkgsFooBar</varname>s are quite new, so there is no special case for <varname>nativeBuildInputs</varname> and <varname>buildInputs</varname>.) For example, <varname>pkgsBuildHost.gcc</varname> should be used at build-time, while <varname>pkgsHostTarget.gcc</varname> should be used at run-time.
</para>
<para>
Now, for most of Nixpkgs's history, there were no
<varname>pkgsFooBar</varname> attributes, and most packages have not been
refactored to use it explicitly. Prior to those, there were just
<varname>buildPackages</varname>, <varname>pkgs</varname>, and
<varname>targetPackages</varname>. Those are now redefined as aliases to
<varname>pkgsBuildHost</varname>, <varname>pkgsHostTarget</varname>, and
<varname>pkgsTargetTarget</varname>. It is acceptable, even
recommended, to use them for libraries to show that the host platform is
irrelevant.
Now, for most of Nixpkgs's history, there were no<varname>pkgsFooBar</varname> attributes, and most packages have not been refactored to use it explicitly. Prior to those, there were just <varname>buildPackages</varname>, <varname>pkgs</varname>, and <varname>targetPackages</varname>. Those are now redefined as aliases to <varname>pkgsBuildHost</varname>, <varname>pkgsHostTarget</varname>, and <varname>pkgsTargetTarget</varname>. It is acceptable, even recommended, to use them for libraries to show that the host platform is irrelevant.
</para>
<para>
But before that, there was just <varname>pkgs</varname>, even though both
<varname>buildInputs</varname> and <varname>nativeBuildInputs</varname>
existed. [Cross barely worked, and those were implemented with some hacks
on <varname>mkDerivation</varname> to override dependencies.] What this
means is the vast majority of packages do not use any explicit package set
to populate their dependencies, just using whatever
<varname>callPackage</varname> gives them even if they do correctly sort
their dependencies into the multiple lists described above. And indeed,
asking that users both sort their dependencies, <emphasis>and</emphasis>
take them from the right attribute set, is both too onerous and redundant,
so the recommended approach (for now) is to continue just categorizing by
list and not using an explicit package set.
But before that, there was just <varname>pkgs</varname>, even though both<varname>buildInputs</varname> and <varname>nativeBuildInputs</varname> existed. [Cross barely worked, and those were implemented with some hacks on <varname>mkDerivation</varname> to override dependencies.] What this means is the vast majority of packages do not use any explicit package set to populate their dependencies, just using whatever <varname>callPackage</varname> gives them even if they do correctly sort their dependencies into the multiple lists described above. And indeed, asking that users both sort their dependencies, <emphasis>and</emphasis> take them from the right attribute set, is both too onerous and redundant, so the recommended approach (for now) is to continue just categorizing by list and not using an explicit package set.
</para>
<para>
To make this work, we "splice" together the six
<varname>pkgsFooBar</varname> package sets and have
<varname>callPackage</varname> actually take its arguments from that. This
is currently implemented in <filename>pkgs/top-level/splice.nix</filename>.
<varname>mkDerivation</varname> then, for each dependency attribute, pulls
the right derivation out from the splice. This splicing can be skipped when
not cross-compiling as the package sets are the same, but still is a bit
slow for cross-compiling. We'd like to do something better, but haven't
come up with anything yet.
To make this work, we "splice" together the six<varname>pkgsFooBar</varname> package sets and have <varname>callPackage</varname> actually take its arguments from that. This is currently implemented in <filename>pkgs/top-level/splice.nix</filename>. <varname>mkDerivation</varname> then, for each dependency attribute, pulls the right derivation out from the splice. This splicing can be skipped when not cross-compiling as the package sets are the same, but still is a bit slow for cross-compiling. We'd like to do something better, but haven't come up with anything yet.
Each of the package sets described above come from a single bootstrapping
stage. While <filename>pkgs/top-level/default.nix</filename>, coordinates
the composition of stages at a high level,
<filename>pkgs/top-level/stage.nix</filename> "ties the knot" (creates the
fixed point) of each stage. The package sets are defined per-stage however,
so they can be thought of as edges between stages (the nodes) in a graph.
Compositions like <literal>pkgsBuildTarget.targetPackages</literal> can be
thought of as paths to this graph.
Each of the package sets described above come from a single bootstrapping stage. While <filename>pkgs/top-level/default.nix</filename>, coordinates the composition of stages at a high level, <filename>pkgs/top-level/stage.nix</filename> "ties the knot" (creates the fixed point) of each stage. The package sets are defined per-stage however, so they can be thought of as edges between stages (the nodes) in a graph. Compositions like <literal>pkgsBuildTarget.targetPackages</literal> can be thought of as paths to this graph.
</para>
<para>
While there are many package sets, and thus many edges, the stages can also
be arranged in a linear chain. In other words, many of the edges are
redundant as far as connectivity is concerned. This hinges on the type of
bootstrapping we do. Currently for cross it is:
While there are many package sets, and thus many edges, the stages can also be arranged in a linear chain. In other words, many of the edges are redundant as far as connectivity is concerned. This hinges on the type of bootstrapping we do. Currently for cross it is:
In each stage, <varname>pkgsBuildHost</varname> refers the the previous
stage, <varname>pkgsBuildBuild</varname> refers to the one before that, and
<varname>pkgsHostTarget</varname> refers to the current one, and
<varname>pkgsTargetTarget</varname> refers to the next one. When there is
no previous or next stage, they instead refer to the current stage. Note
how all the invariants regarding the mapping between dependency and depending
packages' build host and target platforms are preserved.
<varname>pkgsBuildTarget</varname> and <varname>pkgsHostHost</varname> are
more complex in that the stage fitting the requirements isn't always a
fixed chain of "prevs" and "nexts" away (modulo the "saturating"
self-references at the ends). We just special case each instead. All the primary
edges are implemented is in <filename>pkgs/stdenv/booter.nix</filename>,
and secondarily aliases in <filename>pkgs/top-level/stage.nix</filename>.
In each stage, <varname>pkgsBuildHost</varname> refers to the previous stage, <varname>pkgsBuildBuild</varname> refers to the one before that, and <varname>pkgsHostTarget</varname> refers to the current one, and <varname>pkgsTargetTarget</varname> refers to the next one. When there is no previous or next stage, they instead refer to the current stage. Note how all the invariants regarding the mapping between dependency and depending packages' build host and target platforms are preserved. <varname>pkgsBuildTarget</varname> and <varname>pkgsHostHost</varname> are more complex in that the stage fitting the requirements isn't always a fixed chain of "prevs" and "nexts" away (modulo the "saturating" self-references at the ends). We just special case each instead. All the primary edges are implemented is in <filename>pkgs/stdenv/booter.nix</filename>, and secondarily aliases in <filename>pkgs/top-level/stage.nix</filename>.
</para>
<note>
<para>
Note the native stages are bootstrapped in legacy ways that predate the
current cross implementation. This is why the the bootstrapping stages
leading up to the final stages are ignored inthe previous paragraph.
Note the native stages are bootstrapped in legacy ways that predate the current cross implementation. This is why the bootstrapping stages leading up to the final stages are ignored inthe previous paragraph.
</para>
</note>
<para>
If one looks at the 3 platform triples, one can see that they overlap such
that one could put them together into a chain like:
If one looks at the 3 platform triples, one can see that they overlap such that one could put them together into a chain like:
<programlisting>
(native, native, native, foreign, foreign)
</programlisting>
If one imagines the saturating self references at the end being replaced
with infinite stages, and then overlays those platform triples, one ends up
with the infinite tuple:
If one imagines the saturating self references at the end being replaced with infinite stages, and then overlays those platform triples, one ends up with the infinite tuple:
On can then imagine any sequence of platforms such that there are bootstrap
stages with their 3 platforms determined by "sliding a window" that is the
3 tuple through the sequence. This was the original model for
bootstrapping. Without a target platform (assume a better world where all
compilers are multi-target and all standard libraries are built in their
own derivation), this is sufficient. Conversely if one wishes to cross
compile "faster", with a "Canadian Cross" bootstraping stage where
<literal>build != host != target</literal>, more bootstrapping stages are
needed since no sliding window providess the pesky
<varname>pkgsBuildTarget</varname> package set since it skips the Canadian
cross stage's "host".
On can then imagine any sequence of platforms such that there are bootstrap stages with their 3 platforms determined by "sliding a window" that is the 3 tuple through the sequence. This was the original model for bootstrapping. Without a target platform (assume a better world where all compilers are multi-target and all standard libraries are built in their own derivation), this is sufficient. Conversely if one wishes to cross compile "faster", with a "Canadian Cross" bootstraping stage where <literal>build != host != target</literal>, more bootstrapping stages are needed since no sliding window providess the pesky <varname>pkgsBuildTarget</varname> package set since it skips the Canadian cross stage's "host".
</para>
<note>
<para>
It is much better to refer to <varname>buildPackages</varname> than
<varname>targetPackages</varname>, or more broadly package sets that do
not mention "target". There are three reasons for this.
It is much better to refer to <varname>buildPackages</varname> than<varname>targetPackages</varname>, or more broadly package sets that do not mention "target". There are three reasons for this.
</para>
<para>
First, it is because bootstrapping stages do not have a unique
<varname>targetPackages</varname>. For example a <literal>(x86-linux,
x86-linux, arm-linux)</literal> and <literal>(x86-linux, x86-linux,
x86-windows)</literal> package set both have a <literal>(x86-linux,
x86-linux, x86-linux)</literal> package set. Because there is no canonical
<varname>targetPackages</varname> for such a native (<literal>build ==
host == target</literal>) package set, we set their
<varname>targetPackages</varname>
First, it is because bootstrapping stages do not have a unique<varname>targetPackages</varname>. For example a <literal>(x86-linux, x86-linux, arm-linux)</literal> and <literal>(x86-linux, x86-linux, x86-windows)</literal> package set both have a <literal>(x86-linux, x86-linux, x86-linux)</literal> package set. Because there is no canonical <varname>targetPackages</varname> for such a native (<literal>build == host == target</literal>) package set, we set their <varname>targetPackages</varname>
</para>
<para>
Second, it is because this is a frequent source of hard-to-follow
"infinite recursions" / cycles. When only package sets that don't mention
target are used, the package set forms a directed acyclic graph. This
means that all cycles that exist are confined to one stage. This means
they are a lot smaller, and easier to follow in the code or a backtrace. It
also means they are present in native and cross builds alike, and so more
likely to be caught by CI and other users.
Second, it is because this is a frequent source of hard-to-follow "infinite recursions" / cycles. When only package sets that don't mention target are used, the package set forms a directed acyclic graph. This means that all cycles that exist are confined to one stage. This means they are a lot smaller, and easier to follow in the code or a backtrace. It also means they are present in native and cross builds alike, and so more likely to be caught by CI and other users.
</para>
<para>
Thirdly, it is because everything target-mentioning only exists to
accommodate compilers with lousy build systems that insist on the compiler
itself and standard library being built together. Of course that is bad
because bigger derivations means longer rebuilds. It is also problematic because
it tends to make the standard libraries less like other libraries than
they could be, complicating code and build systems alike. Because of the
other problems, and because of these innate disadvantages, compilers ought
to be packaged another way where possible.
Thirdly, it is because everything target-mentioning only exists to accommodate compilers with lousy build systems that insist on the compiler itself and standard library being built together. Of course that is bad because bigger derivations means longer rebuilds. It is also problematic because it tends to make the standard libraries less like other libraries than they could be, complicating code and build systems alike. Because of the other problems, and because of these innate disadvantages, compilers ought to be packaged another way where possible.
</para>
</note>
<note>
<para>
If one explores Nixpkgs, they will see derivations with names like
<literal>gccCross</literal>. Such <literal>*Cross</literal> derivations is
a holdover from before we properly distinguished between the host and
target platforms—the derivation with "Cross" in the name covered the
<literal>build = host != target</literal> case, while the other covered
the <literal>host = target</literal>, with build platform the same or not
based on whether one was using its <literal>.nativeDrv</literal> or
<literal>.crossDrv</literal>. This ugliness will disappear soon.
If one explores Nixpkgs, they will see derivations with names like<literal>gccCross</literal>. Such <literal>*Cross</literal> derivations is a holdover from before we properly distinguished between the host and target platforms—the derivation with "Cross" in the name covered the <literal>build = host != target</literal> case, while the other covered the <literal>host = target</literal>, with build platform the same or not based on whether one was using its <literal>.nativeDrv</literal> or <literal>.crossDrv</literal>. This ugliness will disappear soon.
Nix is a unityped, dynamic language, this means every value can potentially
appear anywhere. Since it is also non-strict, evaluation order and what
ultimately is evaluated might surprise you. Therefore it is important to be
able to debug nix expressions.
Nix is a unityped, dynamic language, this means every value can potentially appear anywhere. Since it is also non-strict, evaluation order and what ultimately is evaluated might surprise you. Therefore it is important to be able to debug nix expressions.
</para>
<para>
In the <literal>lib/debug.nix</literal> file you will find a number of
functions that help (pretty-)printing values while evaluation is runnnig. You
can even specify how deep these values should be printed recursively, and
transform them on the fly. Please consult the docstrings in
<literal>lib/debug.nix</literal> for usage information.
In the <literal>lib/debug.nix</literal> file you will find a number of functions that help (pretty-)printing values while evaluation is runnnig. You can even specify how deep these values should be printed recursively, and transform them on the fly. Please consult the docstrings in <literal>lib/debug.nix</literal> for usage information.
Generators are functions that create file formats from nix data structures,
e.g. for configuration files. There are generators available for:
<literal>INI</literal>, <literal>JSON</literal> and <literal>YAML</literal>
Generators are functions that create file formats from nix data structures, e.g. for configuration files. There are generators available for: <literal>INI</literal>, <literal>JSON</literal> and <literal>YAML</literal>
</para>
<para>
All generators follow a similar call interface: <code>generatorName
configFunctions data</code>, where <literal>configFunctions</literal> is an
attrset of user-defined functions that format nested parts of the content.
They each have common defaults, so often they do not need to be set manually.
An example is <code>mkSectionName ? (name: libStr.escape [ "[" "]" ]
name)</code> from the <literal>INI</literal> generator. It receives the name
of a section and sanitizes it. The default <literal>mkSectionName</literal>
escapes <literal>[</literal> and <literal>]</literal> with a backslash.
All generators follow a similar call interface: <code>generatorName configFunctions data</code>, where <literal>configFunctions</literal> is an attrset of user-defined functions that format nested parts of the content. They each have common defaults, so often they do not need to be set manually. An example is <code>mkSectionName ? (name: libStr.escape [ "[" "]" ] name)</code> from the <literal>INI</literal> generator. It receives the name of a section and sanitizes it. The default <literal>mkSectionName</literal> escapes <literal>[</literal> and <literal>]</literal> with a backslash.
</para>
<para>
Generators can be fine-tuned to produce exactly the file format required by
your application/service. One example is an INI-file format which uses
<literal>: </literal> as separator, the strings
<literal>"yes"</literal>/<literal>"no"</literal> as boolean values and
requires all string values to be quoted:
Generators can be fine-tuned to produce exactly the file format required by your application/service. One example is an INI-file format which uses <literal>: </literal> as separator, the strings <literal>"yes"</literal>/<literal>"no"</literal> as boolean values and requires all string values to be quoted:
</para>
<programlisting>
@@ -77,13 +64,11 @@ merge:"diff3"
<note>
<para>
Nix store paths can be converted to strings by enclosing a derivation
attribute like so: <code>"${drv}"</code>.
Nix store paths can be converted to strings by enclosing a derivation attribute like so: <code>"${drv}"</code>.
</para>
</note>
<para>
Detailed documentation for each generator can be found in
<literal>lib/generators.nix</literal>.
Detailed documentation for each generator can be found in<literal>lib/generators.nix</literal>.
Specialized <function>asserts.assertMsg</function> for checking if
<varname>val</varname> is one of the elements of <varname>xs</varname>.
Useful for checking enums.
Specialized <function>asserts.assertMsg</function> for checking if<varname>val</varname> is one of the elements of <varname>xs</varname>. Useful for checking enums.
</para>
<variablelist>
@@ -76,8 +73,7 @@ stderr> assert failed
</term>
<listitem>
<para>
The name of the variable the user entered <varname>val</varname> into,
for inclusion in the error message.
The name of the variable the user entered <varname>val</varname> into, for inclusion in the error message.
</para>
</listitem>
</varlistentry>
@@ -87,8 +83,7 @@ stderr> assert failed
</term>
<listitem>
<para>
The value of what the user provided, to be compared against the values in
<varname>xs</varname>.
The value of what the user provided, to be compared against the values in<varname>xs</varname>.
Recursively collect sets that verify a given predicate named
<varname>pred</varname> from the set <varname>attrs</varname>. The recursion
stops when <varname>pred</varname> returns <literal>true</literal>.
Recursively collect sets that verify a given predicate named<varname>pred</varname> from the set <varname>attrs</varname>. The recursion stops when <varname>pred</varname> returns <literal>true</literal>.
Like <function>mapAttrs</function>, but allows the name of each attribute to
be changed in addition to the value. The applied function should return both
the new name and value as a <function>nameValuePair</function>.
Like <function>mapAttrs</function>, but allows the name of each attribute to be changed in addition to the value. The applied function should return both the new name and value as a <function>nameValuePair</function>.
</para>
<variablelist>
@@ -829,10 +801,8 @@ lib.attrsets.mapAttrs
<literal>String -> Any -> { name = String; value = Any }</literal>
Like <function>mapAttrs</function>, except that it recursively applies
itself to attribute sets. Also, the first argument of the argument function
is a <emphasis>list</emphasis> of the names of the containing attributes.
Like <function>mapAttrs</function>, except that it recursively applies itself to attribute sets. Also, the first argument of the argument function is a <emphasis>list</emphasis> of the names of the containing attributes.
For example, the <varname>name_path</varname> for the
<literal>example</literal> string in the attribute set <literal>{ foo
= { bar = "example"; }; }</literal> is <literal>[ "foo" "bar"
]</literal>.
For example, the <varname>name_path</varname> for the<literal>example</literal> string in the attribute set <literal>{ foo = { bar = "example"; }; }</literal> is <literal>[ "foo" "bar" ]</literal>.
Like <function>mapAttrsRecursive</function>, but it takes an additional
predicate function that tells it whether to recursive into an attribute set.
If it returns false, <function>mapAttrsRecursiveCond</function> does not
recurse, but does apply the map function. It is returns true, it does
recurse, and does not apply the map function.
Like <function>mapAttrsRecursive</function>, but it takes an additional predicate function that tells it whether to recursive into an attribute set. If it returns false, <function>mapAttrsRecursiveCond</function> does not recurse, but does apply the map function. It is returns true, it does recurse, and does not apply the map function.
</para>
<variablelist>
@@ -1076,8 +1036,7 @@ mapAttrsRecursive
<literal>(AttrSet -> Bool)</literal>
</para>
<para>
Determine if <function>mapAttrsRecursive</function> should recurse deeper
in to the attribute set.
Determine if <function>mapAttrsRecursive</function> should recurse deeper in to the attribute set.
</para>
<variablelist>
<varlistentry>
@@ -1114,10 +1073,7 @@ mapAttrsRecursive
The list of attribute names to this value.
</para>
<para>
For example, the <varname>name_path</varname> for the
<literal>example</literal> string in the attribute set <literal>{ foo
= { bar = "example"; }; }</literal> is <literal>[ "foo" "bar"
]</literal>.
For example, the <varname>name_path</varname> for the<literal>example</literal> string in the attribute set <literal>{ foo = { bar = "example"; }; }</literal> is <literal>[ "foo" "bar" ]</literal>.
Merge sets of attributes and combine each attribute value in to a list.
Similar to <xreflinkend="function-library-lib.attrsets.zipAttrsWith"/>
where the merge function returns a list of all values.
Merge sets of attributes and combine each attribute value in to a list. Similar to <xreflinkend="function-library-lib.attrsets.zipAttrsWith"/> where the merge function returns a list of all values.
Does the same as the update operator <literal>//</literal> except that
attributes are merged until the given predicate is verified. The predicate
should accept 3 arguments which are the path to reach the attribute, a part
of the first attribute set and a part of the second attribute set. When the
predicate is verified, the value of the first attribute set is replaced by
the value of the second attribute set.
Does the same as the update operator <literal>//</literal> except that attributes are merged until the given predicate is verified. The predicate should accept 3 arguments which are the path to reach the attribute, a part of the first attribute set and a part of the second attribute set. When the predicate is verified, the value of the first attribute set is replaced by the value of the second attribute set.
A recursive variant of the update operator <literal>//</literal>. The
recursion stops when one of the attribute values is not an attribute set, in
which case the right hand side value takes precedence over the left hand
side value.
A recursive variant of the update operator <literal>//</literal>. The recursion stops when one of the attribute values is not an attribute set, in which case the right hand side value takes precedence over the left hand side value.
<function>pkgs.nix-gitignore</function> is a function that acts similarly to
<literal>builtins.filterSource</literal> but also allows filtering with the
help of the gitignore format.
<function>pkgs.nix-gitignore</function> is a function that acts similarly to<literal>builtins.filterSource</literal> but also allows filtering with the help of the gitignore format.
</para>
<sectionxml:id="sec-pkgs-nix-gitignore-usage">
<title>Usage</title>
<para>
<literal>pkgs.nix-gitignore</literal> exports a number of functions, but
you'll most likely need either <literal>gitignoreSource</literal> or
<literal>gitignoreSourcePure</literal>. As their first argument, they both
accept either 1. a file with gitignore lines or 2. a string with gitignore
lines, or 3. a list of either of the two. They will be concatenated into a
single big string.
<literal>pkgs.nix-gitignore</literal> exports a number of functions, but you'll most likely need either <literal>gitignoreSource</literal> or <literal>gitignoreSourcePure</literal>. As their first argument, they both accept either 1. a file with gitignore lines or 2. a string with gitignore lines, or 3. a list of either of the two. They will be concatenated into a single big string.
</para>
<programlisting><![CDATA[
@@ -40,8 +33,7 @@
]]></programlisting>
<para>
These functions are derived from the <literal>Filter</literal> functions by
setting the first filter argument to <literal>(_: _: true)</literal>:
These functions are derived from the <literal>Filter</literal> functions by setting the first filter argument to <literal>(_: _: true)</literal>:
Those filter functions accept the same arguments the
<literal>builtins.filterSource</literal> function would pass to its filters,
thus <literal>fn: gitignoreFilterSourcePure fn ""</literal> should be
extensionally equivalent to <literal>filterSource</literal>. The file is
blacklisted iff it's blacklisted by either your filter or the
gitignoreFilter.
Those filter functions accept the same arguments the<literal>builtins.filterSource</literal> function would pass to its filters, thus <literal>fn: gitignoreFilterSourcePure fn ""</literal> should be extensionally equivalent to <literal>filterSource</literal>. The file is blacklisted iff it's blacklisted by either your filter or the gitignoreFilter.
<function>prefer-remote-fetch</function> is an overlay that download sources
on remote builder. This is useful when the evaluating machine has a slow
upload while the builder can fetch faster directly from the source. To use
it, put the following snippet as a new overlay:
<function>prefer-remote-fetch</function> is an overlay that download sources on remote builder. This is useful when the evaluating machine has a slow upload while the builder can fetch faster directly from the source. To use it, put the following snippet as a new overlay:
<programlisting>
self: super:
(super.prefer-remote-fetch self super)
</programlisting>
A full configuration example for that sets the overlay up for your own
account, could look like this
A full configuration example for that sets the overlay up for your own account, could look like this
In this document and related Nix expressions, we use the term,
<emphasis>BEAM</emphasis>, to describe the environment. BEAM is the name of
the Erlang Virtual Machine and, as far as we're concerned, from a packaging
perspective, all languages that run on the BEAM are interchangeable. That
which varies, like the build system, is transparent to users of any given
BEAM package, so we make no distinction.
In this document and related Nix expressions, we use the term,<emphasis>BEAM</emphasis>, to describe the environment. BEAM is the name of the Erlang Virtual Machine and, as far as we're concerned, from a packaging perspective, all languages that run on the BEAM are interchangeable. That which varies, like the build system, is transparent to users of any given BEAM package, so we make no distinction.
</para>
</section>
@@ -20,57 +15,36 @@
<title>Structure</title>
<para>
All BEAM-related expressions are available via the top-level
<literal>beam</literal> attribute, which includes:
All BEAM-related expressions are available via the top-level<literal>beam</literal> attribute, which includes:
</para>
<itemizedlist>
<listitem>
<para>
<literal>interpreters</literal>: a set of compilers running on the BEAM,
(<literal>beam.interpreters.elixir</literal>) and LFE
(<literal>beam.interpreters.lfe</literal>).
<literal>interpreters</literal>: a set of compilers running on the BEAM, including multiple Erlang/OTP versions (<literal>beam.interpreters.erlangR19</literal>, etc), Elixir (<literal>beam.interpreters.elixir</literal>) and LFE (<literal>beam.interpreters.lfe</literal>).
</para>
</listitem>
<listitem>
<para>
<literal>packages</literal>: a set of package sets, each compiled with a
specific Erlang/OTP version, e.g.
<literal>beam.packages.erlangR19</literal>.
<literal>packages</literal>: a set of package sets, each compiled with a specific Erlang/OTP version, e.g. <literal>beam.packages.erlangR19</literal>.
</para>
</listitem>
</itemizedlist>
<para>
The default Erlang compiler, defined by
<literal>beam.interpreters.erlang</literal>, is aliased as
<literal>erlang</literal>. The default BEAM package set is defined by
<literal>beam.packages.erlang</literal> and aliased at the top level as
<literal>beamPackages</literal>.
The default Erlang compiler, defined by<literal>beam.interpreters.erlang</literal>, is aliased as <literal>erlang</literal>. The default BEAM package set is defined by <literal>beam.packages.erlang</literal> and aliased at the top level as <literal>beamPackages</literal>.
</para>
<para>
To create a package set built with a custom Erlang version, use the lambda,
<literal>beam.packagesWith</literal>, which accepts an Erlang/OTP derivation
and produces a package set similar to
<literal>beam.packages.erlang</literal>.
To create a package set built with a custom Erlang version, use the lambda,<literal>beam.packagesWith</literal>, which accepts an Erlang/OTP derivation and produces a package set similar to <literal>beam.packages.erlang</literal>.
</para>
<para>
Many Erlang/OTP distributions available in
<literal>beam.interpreters</literal> have versions with ODBC and/or Java
enabled. For example, there's
<literal>beam.interpreters.erlangR19_odbc_javac</literal>, which corresponds
to <literal>beam.interpreters.erlangR19</literal>.
Many Erlang/OTP distributions available in<literal>beam.interpreters</literal> have versions with ODBC and/or Java enabled. For example, there's <literal>beam.interpreters.erlangR19_odbc_javac</literal>, which corresponds to <literal>beam.interpreters.erlangR19</literal>.
</para>
<paraxml:id="erlang-call-package">
We also provide the lambda,
<literal>beam.packages.erlang.callPackage</literal>, which simplifies
writing BEAM package definitions by injecting all packages from
<literal>beam.packages.erlang</literal> into the top-level context.
We also provide the lambda,<literal>beam.packages.erlang.callPackage</literal>, which simplifies writing BEAM package definitions by injecting all packages from <literal>beam.packages.erlang</literal> into the top-level context.
</para>
</section>
@@ -81,28 +55,7 @@
<title>Rebar3</title>
<para>
By default, Rebar3 wants to manage its own dependencies. This is perfectly
acceptable in the normal, non-Nix setup, but in the Nix world, it is not.
To rectify this, we provide two versions of Rebar3:
<itemizedlist>
<listitem>
<para>
<literal>rebar3</literal>: patched to remove the ability to download
anything. When not running it via <literal>nix-shell</literal> or
<literal>nix-build</literal>, it's probably not going to work as
desired.
</para>
</listitem>
<listitem>
<para>
<literal>rebar3-open</literal>: the normal, unmodified Rebar3. It should
work exactly as would any other version of Rebar3. Any Erlang package
should rely on <literal>rebar3</literal> instead. See
<xref
linkend="rebar3-packages"/>.
</para>
</listitem>
</itemizedlist>
We provide a version of Rebar3, which is the normal, unmodified Rebar3, under <literal>rebar3</literal>. We also provide a helper to fetch Rebar3 dependencies from a lockfile under <literal>fetchRebar3Deps</literal>.
</para>
</section>
@@ -110,10 +63,7 @@
<title>Mix & Erlang.mk</title>
<para>
Both Mix and Erlang.mk work exactly as expected. There is a bootstrap
process that needs to be run for both, however, which is supported by the
<literal>buildMix</literal> and <literal>buildErlangMk</literal>
derivations, respectively.
Both Mix and Erlang.mk work exactly as expected. There is a bootstrap process that needs to be run for both, however, which is supported by the <literal>buildMix</literal> and <literal>buildErlangMk</literal> derivations, respectively.
</para>
</section>
</section>
@@ -122,13 +72,7 @@
<title>How to Install BEAM Packages</title>
<para>
BEAM packages are not registered at the top level, simply because they are
not relevant to the vast majority of Nix users. They are installable using
the <literal>beam.packages.erlang</literal> attribute set (aliased as
<literal>beamPackages</literal>), which points to packages built by the
default Erlang/OTP version in Nixpkgs, as defined by
<literal>beam.interpreters.erlang</literal>. To list the available packages
in <literal>beamPackages</literal>, use the following command:
BEAM packages are not registered at the top level, simply because they are not relevant to the vast majority of Nix users. They are installable using the <literal>beam.packages.erlang</literal> attribute set (aliased as <literal>beamPackages</literal>), which points to packages built by the default Erlang/OTP version in Nixpkgs, as defined by <literal>beam.interpreters.erlang</literal>. To list the available packages in <literal>beamPackages</literal>, use the following command:
The attribute path of any BEAM package corresponds to the name of that
particular package in <linkxlink:href="https://hex.pm">Hex</link> or its
OTP Application/Release name.
The attribute path of any BEAM package corresponds to the name of that particular package in <linkxlink:href="https://hex.pm">Hex</link> or its OTP Application/Release name.
The Nix function, <literal>buildRebar3</literal>, defined in<literal>beam.packages.erlang.buildRebar3</literal> and aliased at the top level, can be used to build a derivation that understands how to build a Rebar3 project. For example, we can build <link
xlink:href="https://github.com/erlang-nix/hex2nix">hex2nix</link> as follows:
</para>
<programlisting>
@@ -196,25 +132,16 @@ buildRebar3 rec {
</programlisting>
<para>
Such derivations are callable with
<literal>beam.packages.erlang.callPackage</literal> (see
<xref
linkend="erlang-call-package"/>). To call this package using
the normal <literal>callPackage</literal>, refer to dependency packages
via <literal>beamPackages</literal>, e.g.
<literal>beamPackages.ibrowse</literal>.
Such derivations are callable with<literal>beam.packages.erlang.callPackage</literal> (see <xref
linkend="erlang-call-package"/>). To call this package using the normal <literal>callPackage</literal>, refer to dependency packages via <literal>beamPackages</literal>, e.g. <literal>beamPackages.ibrowse</literal>.
</para>
<para>
Notably, <literal>buildRebar3</literal> includes
<literal>beamDeps</literal>, while <literal>stdenv.mkDerivation</literal>
does not. BEAM dependencies added there will be correctly handled by the
system.
Notably, <literal>buildRebar3</literal> includes<literal>beamDeps</literal>, while <literal>stdenv.mkDerivation</literal> does not. BEAM dependencies added there will be correctly handled by the system.
</para>
<para>
If a package needs to compile native code via Rebar3's port compilation
mechanism, add <literal>compilePort = true;</literal> to the derivation.
If a package needs to compile native code via Rebar3's port compilation mechanism, add <literal>compilePort = true;</literal> to the derivation.
</para>
</section>
@@ -222,9 +149,7 @@ buildRebar3 rec {
<title>Erlang.mk Packages</title>
<para>
Erlang.mk functions similarly to Rebar3, except we use
<literal>buildErlangMk</literal> instead of
<literal>buildRebar3</literal>.
Erlang.mk functions similarly to Rebar3, except we use<literal>buildErlangMk</literal> instead of <literal>buildRebar3</literal>.
</para>
<programlisting>
@@ -257,8 +182,7 @@ buildErlangMk {
<title>Mix Packages</title>
<para>
Mix functions similarly to Rebar3, except we use
<literal>buildMix</literal> instead of <literal>buildRebar3</literal>.
Mix functions similarly to Rebar3, except we use<literal>buildMix</literal> instead of <literal>buildRebar3</literal>.
</para>
<programlisting>
@@ -323,11 +247,7 @@ buildHex {
<title>Accessing an Environment</title>
<para>
Often, we simply want to access a valid environment that contains a
specific package and its dependencies. We can accomplish that with the
<literal>env</literal> attribute of a derivation. For example, let's say we
want to access an Erlang REPL with <literal>ibrowse</literal> loaded up. We
could do the following:
Often, we simply want to access a valid environment that contains a specific package and its dependencies. We can accomplish that with the <literal>env</literal> attribute of a derivation. For example, let's say we want to access an Erlang REPL with <literal>ibrowse</literal> loaded up. We could do the following:
</para>
<screen>
@@ -373,8 +293,7 @@ ok</computeroutput>
</screen>
<para>
Notice the <literal>-A beamPackages.ibrowse.env</literal>. That is the key
to this functionality.
Notice the <literal>-A beamPackages.ibrowse.env</literal>. That is the key to this functionality.
</para>
</section>
@@ -382,11 +301,7 @@ ok</computeroutput>
<title>Creating a Shell</title>
<para>
Getting access to an environment often isn't enough to do real development.
Usually, we need to create a <literal>shell.nix</literal> file and do our
development inside of the environment specified therein. This file looks a
lot like the packaging described above, except that <literal>src</literal>
points to the project root and we call the package directly.
Getting access to an environment often isn't enough to do real development. Usually, we need to create a <literal>shell.nix</literal> file and do our development inside of the environment specified therein. This file looks a lot like the packaging described above, except that <literal>src</literal> points to the project root and we call the package directly.
</para>
<programlisting>
@@ -414,8 +329,7 @@ in
<title>Building in a Shell (for Mix Projects)</title>
<para>
We can leverage the support of the derivation, irrespective of the build
derivation, by calling the commands themselves.
We can leverage the support of the derivation, irrespective of the build derivation, by calling the commands themselves.
</para>
<programlisting>
@@ -477,12 +391,8 @@ analyze: build plt
</programlisting>
<para>
Using a <literal>shell.nix</literal> as described (see
<xref
linkend="creating-a-shell"/>) should just work. Aside from
<literal>test</literal>, <literal>plt</literal>, and
<literal>analyze</literal>, the Make targets work just fine for all of the
build derivations.
Using a <literal>shell.nix</literal> as described (see<xref
linkend="creating-a-shell"/>) should just work. Aside from <literal>test</literal>, <literal>plt</literal>, and <literal>analyze</literal>, the Make targets work just fine for all of the build derivations.
</para>
</section>
</section>
@@ -492,25 +402,14 @@ analyze: build plt
<title>Generating Packages from Hex with <literal>hex2nix</literal></title>
<para>
Updating the <linkxlink:href="https://hex.pm">Hex</link> package set
<literal>pkgs/development/erlang-modules</literal>), it will dump a file
called <literal>hex-packages.nix</literal>, containing all the packages that
use a recognized build system in
<link
xlink:href="https://hex.pm">Hex</link>. It can't be determined,
however, whether every package is buildable.
Updating the <linkxlink:href="https://hex.pm">Hex</link> package set requires <link
xlink:href="https://github.com/erlang-nix/hex2nix">hex2nix</link>. Given the path to the Erlang modules (usually <literal>pkgs/development/erlang-modules</literal>), it will dump a file called <literal>hex-packages.nix</literal>, containing all the packages that use a recognized build system in <link
xlink:href="https://hex.pm">Hex</link>. It can't be determined, however, whether every package is buildable.
</para>
<para>
To make life easier for our users, try to build every
<link
xlink:href="https://hex.pm">Hex</link> package and remove those
that fail. To do that, simply run the following command in the root of your
<literal>nixpkgs</literal> repository:
To make life easier for our users, try to build every<link
xlink:href="https://hex.pm">Hex</link> package and remove those that fail. To do that, simply run the following command in the root of your <literal>nixpkgs</literal> repository:
</para>
<screen>
@@ -518,11 +417,8 @@ analyze: build plt
</screen>
<para>
That will attempt to build every package in <literal>beamPackages</literal>.
Then manually remove those that fail. Hopefully, someone will improve
That will attempt to build every package in <literal>beamPackages</literal>. Then manually remove those that fail. Hopefully, someone will improve <link
xlink:href="https://github.com/erlang-nix/hex2nix">hex2nix</link> in the future to automate the process.
<linkxlink:href="http://bower.io">Bower</link> is a package manager for web
site front-end components. Bower packages (comprising of build artefacts and
sometimes sources) are stored in <command>git</command> repositories,
typically on Github. The package registry is run by the Bower team with
package metadata coming from the <filename>bower.json</filename> file within
each package.
<linkxlink:href="http://bower.io">Bower</link> is a package manager for web site front-end components. Bower packages (comprising of build artefacts and sometimes sources) are stored in <command>git</command> repositories, typically on Github. The package registry is run by the Bower team with package metadata coming from the <filename>bower.json</filename> file within each package.
</para>
<para>
The end result of running Bower is a <filename>bower_components</filename>
directory which can be included in the web app's build process.
The end result of running Bower is a <filename>bower_components</filename> directory which can be included in the web app's build process.
</para>
<para>
Bower can be run interactively, by installing
<varname>nodePackages.bower</varname>. More interestingly, the Bower
components can be declared in a Nix derivation, with the help of
<varname>nodePackages.bower2nix</varname>.
Bower can be run interactively, by installing<varname>nodePackages.bower</varname>. More interestingly, the Bower components can be declared in a Nix derivation, with the help of <varname>nodePackages.bower2nix</varname>.
</para>
<sectionxml:id="ssec-bower2nix-usage">
<title><command>bower2nix</command> usage</title>
<para>
Suppose you have a <filename>bower.json</filename> with the following
contents:
Suppose you have a <filename>bower.json</filename> with the following contents:
<examplexml:id="ex-bowerJson">
<title><filename>bower.json</filename></title>
<programlistinglanguage="json">
@@ -45,8 +35,7 @@
</para>
<para>
Running <command>bower2nix</command> will produce something like the
following output:
Running <command>bower2nix</command> will produce something like the following output:
Using the <command>bower2nix</command> command line arguments, the output
can be redirected to a file. A name like
<filename>bower-packages.nix</filename> would be fine.
Using the <command>bower2nix</command> command line arguments, the output can be redirected to a file. A name like <filename>bower-packages.nix</filename> would be fine.
</para>
<para>
The resulting derivation is a union of all the downloaded Bower packages
(and their dependencies). To use it, they still need to be linked together
by Bower, which is where <varname>buildBowerComponents</varname> is useful.
The resulting derivation is a union of all the downloaded Bower packages (and their dependencies). To use it, they still need to be linked together by Bower, which is where <varname>buildBowerComponents</varname> is useful.
The function is implemented in<linkxlink:href="https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/bower-modules/generic/default.nix"><filename>pkgs/development/bower-modules/generic/default.nix</filename></link>. Example usage:
In <xreflinkend="ex-buildBowerComponents"/>, the following arguments are
of special significance to the function:
In <xreflinkend="ex-buildBowerComponents"/>, the following arguments are of special significance to the function:
<calloutlist>
<calloutarearefs="ex-buildBowerComponents-1">
<para>
<varname>generated</varname> specifies the file which was created by
<command>bower2nix</command>.
<varname>generated</varname> specifies the file which was created by<command>bower2nix</command>.
</para>
</callout>
<calloutarearefs="ex-buildBowerComponents-2">
<para>
<varname>src</varname> is your project's sources. It needs to contain a
<filename>bower.json</filename> file.
<varname>src</varname> is your project's sources. It needs to contain a<filename>bower.json</filename> file.
</para>
</callout>
</calloutlist>
</para>
<para>
<varname>buildBowerComponents</varname> will run Bower to link together the
output of <command>bower2nix</command>, resulting in a
<filename>bower_components</filename> directory which can be used.
<varname>buildBowerComponents</varname> will run Bower to link together the output of <command>bower2nix</command>, resulting in a <filename>bower_components</filename> directory which can be used.
</para>
<para>
Here is an example of a web frontend build process using
<command>gulp</command>. You might use <command>grunt</command>, or anything
else.
Here is an example of a web frontend build process using<command>gulp</command>. You might use <command>grunt</command>, or anything else.
Whether to symlink or copy the <filename>bower_components</filename>
directory depends on the build tool in use. In this case a copy is used
to avoid <command>gulp</command> silliness with permissions.
Whether to symlink or copy the <filename>bower_components</filename> directory depends on the build tool in use. In this case a copy is used to avoid <command>gulp</command> silliness with permissions.
This means that Bower was looking for a package version which doesn't
exist in the generated <filename>bower-packages.nix</filename>.
This means that Bower was looking for a package version which doesn't exist in the generated <filename>bower-packages.nix</filename>.
</para>
<para>
If <filename>bower.json</filename> has been updated, then run
<command>bower2nix</command> again.
If <filename>bower.json</filename> has been updated, then run<command>bower2nix</command> again.
</para>
<para>
It could also be a bug in <command>bower2nix</command> or
<command>fetchbower</command>. If possible, try reformulating the version
specification in <filename>bower.json</filename>.
It could also be a bug in <command>bower2nix</command> or<command>fetchbower</command>. If possible, try reformulating the version specification in <filename>bower.json</filename>.
<literal>$(out)/lib/coq/${coq.coq-version}/user-contrib/</literal>. Such
directories are automatically added to the <literal>$COQPATH</literal>
environment variable by the hook defined in the Coq derivation.
Coq libraries should be installed in<literal>$(out)/lib/coq/${coq.coq-version}/user-contrib/</literal>. Such directories are automatically added to the <literal>$COQPATH</literal> environment variable by the hook defined in the Coq derivation.
</para>
<para>
Some extensions (plugins) might require OCaml and sometimes other OCaml
packages. The <literal>coq.ocamlPackages</literal> attribute can be used to
depend on the same package set Coq was built against.
Some extensions (plugins) might require OCaml and sometimes other OCaml packages. The <literal>coq.ocamlPackages</literal> attribute can be used to depend on the same package set Coq was built against.
</para>
<para>
Coq libraries may be compatible with some specific versions of Coq only. The
<literal>compatibleCoqVersions</literal> attribute is used to precisely
select those versions of Coq that are compatible with this derivation.
Coq libraries may be compatible with some specific versions of Coq only. The<literal>compatibleCoqVersions</literal> attribute is used to precisely select those versions of Coq that are compatible with this derivation.
</para>
<para>
Here is a simple package example. It is a pure Coq library, thus it depends
on Coq. It builds on the Mathematical Components library, thus it also takes
<literal>mathcomp</literal> as <literal>buildInputs</literal>. Its
<literal>Makefile</literal> has been generated using
<literal>coq_makefile</literal> so we only have to set the
<literal>$COQLIB</literal> variable at install time.
Here is a simple package example. It is a pure Coq library, thus it depends on Coq. It builds on the Mathematical Components library, thus it also takes <literal>mathcomp</literal> as <literal>buildInputs</literal>. Its <literal>Makefile</literal> has been generated using <literal>coq_makefile</literal> so we only have to set the <literal>$COQLIB</literal> variable at install time.
Programs in the GNOME universe are written in various languages but they all use GObject-based libraries like GLib, GTK or GStreamer. These libraries are often modular, relying on looking into certain directories to find their modules. However, due to Nix’s specific file system organization, this will fail without our intervention. Fortunately, the libraries usually allow overriding the directories through environment variables, either natively or thanks to a patch in nixpkgs. <linkxlink:href="#fun-wrapProgram">Wrapping</link> the executables to ensure correct paths are available to the application constitutes a significant part of packaging a modern desktop application. In this section, we will describe various modules needed by such applications, environment variables needed to make the modules load, and finally a script that will do the work for us.
</para>
<sectionxml:id="ssec-gnome-settings">
<title>Settings</title>
<para>
<linkxlink:href="https://developer.gnome.org/gio/stable/GSettings.html">GSettings</link> API is often used for storing settings. GSettings schemas are required, to know the type and other metadata of the stored values. GLib looks for <filename>glib-2.0/schemas/gschemas.compiled</filename> files inside the directories of <envar>XDG_DATA_DIRS</envar>.
</para>
<para>
On Linux, GSettings API is implemented using <linkxlink:href="https://wiki.gnome.org/Projects/dconf">dconf</link> backend. You will need to add <literal>dconf</literal> GIO module to <envar>GIO_EXTRA_MODULES</envar> variable, otherwise the <literal>memory</literal> backend will be used and the saved settings will not be persistent.
</para>
<para>
Last you will need the dconf database D-Bus service itself. You can enable it using <option>programs.dconf.enable</option>.
</para>
<para>
Some applications will also require <package>gsettings-desktop-schemas</package> for things like reading proxy configuration or user interface customization. This dependency is often not mentioned by upstream, you should grep for <literal>org.gnome.desktop</literal> and <literal>org.gnome.system</literal> to see if the schemas are needed.
</para>
</section>
<sectionxml:id="ssec-gnome-icons">
<title>Icons</title>
<para>
When an application uses icons, an icon theme should be available in <envar>XDG_DATA_DIRS</envar>. The package for the default, icon-less <linkxlink:href="https://www.freedesktop.org/wiki/Software/icon-theme/">hicolor-icon-theme</link> contains <linklinkend="ssec-gnome-hooks-hicolor-icon-theme">a setup hook</link> that will pick up icon themes from <literal>buildInputs</literal> and pass it to our wrapper. Unfortunately, relying on that would mean every user has to download the theme included in the package expression no matter their preference. For that reason, we leave the installation of icon theme on the user. If you use one of the desktop environments, you probably already have an icon theme installed.
</para>
</section>
<sectionxml:id="ssec-gnome-themes">
<title>GTK Themes</title>
<para>
Previously, a GTK theme needed to be in <envar>XDG_DATA_DIRS</envar>. This is no longer necessary for most programs since GTK incorporated Adwaita theme. Some programs (for example, those designed for <linkxlink:href="https://elementary.io/docs/human-interface-guidelines#human-interface-guidelines">elementary HIG</link>) might require a special theme like <package>pantheon.elementary-gtk-theme</package>.
</para>
</section>
<sectionxml:id="ssec-gnome-typelibs">
<title>GObject introspection typelibs</title>
<para>
<linkxlink:href="https://wiki.gnome.org/Projects/GObjectIntrospection">GObject introspection</link> allows applications to use C libraries in other languages easily. It does this through <literal>typelib</literal> files searched in <envar>GI_TYPELIB_PATH</envar>.
</para>
</section>
<sectionxml:id="ssec-gnome-plugins">
<title>Various plug-ins</title>
<para>
If your application uses <linkxlink:href="https://gstreamer.freedesktop.org/">GStreamer</link> or <linkxlink:href="https://wiki.gnome.org/Projects/Grilo">Grilo</link>, you should set <envar>GST_PLUGIN_SYSTEM_PATH_1_0</envar> and <envar>GRL_PLUGIN_PATH</envar>, respectively.
Fortunately, there is <package>wrapGAppsHook</package>, that does the wrapping for us. In particular, it works in conjunction with other setup hooks that will populate the variable:
<itemizedlist>
<listitemxml:id="ssec-gnome-hooks-wrapgappshook">
<para>
<package>wrapGAppsHook</package> itself will add the package’s <filename>share</filename> directory to <envar>XDG_DATA_DIRS</envar>.
</para>
</listitem>
<listitemxml:id="ssec-gnome-hooks-glib">
<para>
<package>glib</package> setup hook will populate <envar>GSETTINGS_SCHEMAS_PATH</envar> and then <package>wrapGAppsHook</package> will prepend it to <envar>XDG_DATA_DIRS</envar>.
</para>
</listitem>
<listitemxml:id="ssec-gnome-hooks-dconf">
<para>
<package>gnome3.dconf.lib</package> is a dependency of <package>wrapGAppsHook</package>, which then also adds it to the <envar>GIO_EXTRA_MODULES</envar> variable.
<package>hicolor-icon-theme</package>’s setup hook will add icon themes to <envar>XDG_ICON_DIRS</envar> which is prepended to <envar>XDG_DATA_DIRS</envar> by <package>wrapGAppsHook</package>.
<package>gobject-introspection</package> setup hook populates <envar>GI_TYPELIB_PATH</envar> variable with <filename>lib/girepository-1.0</filename> directories of dependencies, which is then added to wrapper by <package>wrapGAppsHook</package>. It also adds <filename>share</filename> directories of dependencies to <envar>XDG_DATA_DIRS</envar>, which is intended to promote GIR files but it also <linkxlink:href="https://github.com/NixOS/nixpkgs/issues/32790">pollutes the closures</link> of packages using <package>wrapGAppsHook</package>.
</para>
<warning>
<para>
The setup hook <linkxlink:href="https://github.com/NixOS/nixpkgs/issues/56943">currently</link> does not work in expressions with <literal>strictDeps</literal> enabled, like Python packages. In those cases, you will need to disable it with <code>strictDeps = false;</code>.
Setup hooks of <package>gst_all_1.gstreamer</package> and <package>gnome3.grilo</package> will populate the <envar>GST_PLUGIN_SYSTEM_PATH_1_0</envar> and <envar>GRL_PLUGIN_PATH</envar> variables, respectively, which will then be added to the wrapper by <literal>wrapGAppsHook</literal>.
</para>
</listitem>
</itemizedlist>
</para>
<para>
You can also pass additional arguments to <literal>makeWrapper</literal> using <literal>gappsWrapperArgs</literal> in <literal>preFixup</literal> hook:
Most GNOME package offer <linklinkend="var-passthru-updateScript"><literal>updateScript</literal></link>, it is therefore possible to update to latest source tarball by running <command>nix-shell maintainers/scripts/update.nix --argstr package gnome3.nautilus</command> or even en masse with <command>nix-shell maintainers/scripts/update.nix --argstr path gnome3</command>. Read the package’s <filename>NEWS</filename> file to see what changed.
<computeroutput>GLib-GIO-ERROR **: <replaceable>06:04:50.903</replaceable>: No GSettings schemas are installed on the system</computeroutput>
</term>
<listitem>
<para>
There are no schemas avalable in <envar>XDG_DATA_DIRS</envar>. Temporarily add a random package containing schemas like <package>gsettings-desktop-schemas</package> to <literal>buildInputs</literal>. <linklinkend="ssec-gnome-hooks-glib"><package>glib</package></link> and <linklinkend="ssec-gnome-hooks-wrapgappshook"><package>wrapGAppsHook</package></link> setup hooks will take care of making the schemas available to application and you will see the actual missing schemas with the <linklinkend="ssec-gnome-common-issues-missing-schema">next error</link>. Or you can try looking through the source code for the actual schemas used.
<computeroutput>GLib-GIO-ERROR **: <replaceable>06:04:50.903</replaceable>: Settings schema ‘<replaceable>org.gnome.foo</replaceable>’ is not installed</computeroutput>
</term>
<listitem>
<para>
Package is missing some GSettings schemas. You can find out the package containing the schema with <command>nix-locate <replaceable>org.gnome.foo</replaceable>.gschema.xml</command> and let the hooks handle the wrapping as <linklinkend="ssec-gnome-common-issues-no-schemas">above</link>.
When using <package>wrapGAppsHook</package> with special derivers you can end up with double wrapped binaries.
</term>
<listitem>
<para>
This is because derivers like <function>python.pkgs.buildPythonApplication</function> or <function>qt5.mkDerivation</function> have setup-hooks automatically added that produce wrappers with <package>makeWrapper</package>. The simplest way to workaround that is to disable the <package>wrapGAppsHook</package> automatic wrapping with <code>dontWrapGApps = true;</code> and pass the arguments it intended to pass to <package>makeWrapper</package> to another.
</para>
<para>
In the case of a Python application it could look like:
<programlisting>
python3.pkgs.buildPythonApplication {
pname = "gnome-music";
version = "3.32.2";
nativeBuildInputs = [
wrapGAppsHook
gobject-introspection
...
];
dontWrapGApps = true;
# Arguments to be passed to `makeWrapper`, only used by buildPython*
makeWrapperArgs = [
"\${gappsWrapperArgs[@]}"
];
}
</programlisting>
And for a QT app like:
<programlisting>
mkDerivation {
pname = "calibre";
version = "3.47.0";
nativeBuildInputs = [
wrapGAppsHook
qmake
...
];
dontWrapGApps = true;
# Arguments to be passed to `makeWrapper`, only used by qt5’s mkDerivation
I am packaging a project that cannot be wrapped, like a library or GNOME Shell extension.
</term>
<listitem>
<para>
You can rely on applications depending on the library setting the necessary environment variables but that is often easy to miss. Instead we recommend to patch the paths in the source code whenever possible. Here are some examples:
<linkxlink:href="https://github.com/NixOS/nixpkgs/blob/7bb8f05f12ca3cff9da72b56caa2f7472d5732bc/pkgs/desktops/gnome-3/core/gnome-shell-extensions/default.nix#L21-L24">Replacing a <envar>GI_TYPELIB_PATH</envar> in GNOME Shell extension</link>– we are using <function>substituteAll</function> to include the path to a typelib into a patch.
The following examples are hardcoding GSettings schema paths. To get the schema paths we use the functions
<itemizedlist>
<listitem>
<para>
<function>glib.getSchemaPath</function> Takes a nix package attribute as an argument.
</para>
</listitem>
<listitem>
<para>
<function>glib.makeSchemaPath</function> Takes a package output like <literal>$out</literal> and a derivation name. You should use this if the schemas you need to hardcode are in the same derivation.
<linkxlink:href="https://github.com/NixOS/nixpkgs/blob/7bb8f05f12ca3cff9da72b56caa2f7472d5732bc/pkgs/desktops/pantheon/apps/elementary-files/default.nix#L78-L86">Hard-coding GSettings schema path in Vala plug-in (dynamically loaded library)</link>– here, <function>substituteAll</function> cannot be used since the schema comes from the same package preventing us from pass its path to the function, probably due to a <linkxlink:href="https://github.com/NixOS/nix/issues/1846">Nix bug</link>.
<linkxlink:href="https://github.com/NixOS/nixpkgs/blob/29c120c065d03b000224872251bed93932d42412/pkgs/development/libraries/glib-networking/default.nix#L31-L34">Hard-coding GSettings schema path in C library</link>– nothing special other than using <linkxlink:href="https://github.com/NixOS/nixpkgs/pull/67957#issuecomment-527717467">Coccinelle patch</link> to generate the patch itself.
The function <varname> buildGoModule </varname> builds Go programs managed with Go modules. It builds a <linkxlink:href="https://github.com/golang/go/wiki/Modules">Go modules</link> through a two phase build:
<itemizedlist>
<listitem>
<para>
An intermediate fetcher derivation. This derivation will be used to fetch
all of the dependencies of the Go module.
An intermediate fetcher derivation. This derivation will be used to fetch all of the dependencies of the Go module.
</para>
</listitem>
<listitem>
<para>
A final derivation will use the output of the intermediate derivation to
build the binaries and produce the final output.
A final derivation will use the output of the intermediate derivation to build the binaries and produce the final output.
</para>
</listitem>
</itemizedlist>
@@ -57,21 +52,16 @@ pet = buildGoModule rec {
</example>
<para>
<xreflinkend='ex-buildGoModule'/> is an example expression using
buildGoModule, the following arguments are of special significance to the
function:
<xreflinkend='ex-buildGoModule'/> is an example expression using buildGoModule, the following arguments are of special significance to the function:
<calloutlist>
<calloutarearefs='ex-buildGoModule-1'>
<para>
<varname>modSha256</varname> is the hash of the output of the
intermediate fetcher derivation.
<varname>modSha256</varname> is the hash of the output of the intermediate fetcher derivation.
</para>
</callout>
<calloutarearefs='ex-buildGoModule-2'>
<para>
<varname>subPackages</varname> limits the builder from building child
packages that have not been listed. If <varname>subPackages</varname> is
not specified, all child packages will be built.
<varname>subPackages</varname> limits the builder from building child packages that have not been listed. If <varname>subPackages</varname> is not specified, all child packages will be built.
</para>
</callout>
</calloutlist>
@@ -82,8 +72,7 @@ pet = buildGoModule rec {
<title>Go legacy</title>
<para>
The function <varname> buildGoPackage </varname> builds legacy Go programs,
not supporting Go modules.
The function <varname> buildGoPackage </varname> builds legacy Go programs, not supporting Go modules.
</para>
<examplexml:id='ex-buildGoPackage'>
@@ -111,49 +100,36 @@ deis = buildGoPackage rec {
</example>
<para>
<xreflinkend='ex-buildGoPackage'/> is an example expression using
buildGoPackage, the following arguments are of special significance to the
function:
<xreflinkend='ex-buildGoPackage'/> is an example expression using buildGoPackage, the following arguments are of special significance to the function:
<calloutlist>
<calloutarearefs='ex-buildGoPackage-1'>
<para>
<varname>goPackagePath</varname> specifies the package's canonical Go
import path.
<varname>goPackagePath</varname> specifies the package's canonical Go import path.
</para>
</callout>
<calloutarearefs='ex-buildGoPackage-2'>
<para>
<varname>subPackages</varname> limits the builder from building child
packages that have not been listed. If <varname>subPackages</varname> is
not specified, all child packages will be built.
<varname>subPackages</varname> limits the builder from building child packages that have not been listed. If <varname>subPackages</varname> is not specified, all child packages will be built.
</para>
<para>
In this example only <literal>github.com/deis/deis/client</literal> will
be built.
In this example only <literal>github.com/deis/deis/client</literal> will be built.
</para>
</callout>
<calloutarearefs='ex-buildGoPackage-3'>
<para>
<varname>goDeps</varname> is where the Go dependencies of a Go program
are listed as a list of package source identified by Go import path. It
could be imported as a separate <varname>deps.nix</varname> file for
readability. The dependency data structure is described below.
<varname>goDeps</varname> is where the Go dependencies of a Go program are listed as a list of package source identified by Go import path. It could be imported as a separate <varname>deps.nix</varname> file for readability. The dependency data structure is described below.
</para>
</callout>
<calloutarearefs='ex-buildGoPackage-4'>
<para>
<varname>buildFlags</varname> is a list of flags passed to the go build
command.
<varname>buildFlags</varname> is a list of flags passed to the go build command.
</para>
</callout>
</calloutlist>
</para>
<para>
The <varname>goDeps</varname> attribute can be imported from a separate
<varname>nix</varname> file that defines which Go libraries are needed and
should be included in <varname>GOPATH</varname> for
<varname>buildPhase</varname>.
The <varname>goDeps</varname> attribute can be imported from a separate<varname>nix</varname> file that defines which Go libraries are needed and should be included in <varname>GOPATH</varname> for <varname>buildPhase</varname>.
</para>
<examplexml:id='ex-goDeps'>
@@ -196,27 +172,18 @@ deis = buildGoPackage rec {
</callout>
<calloutarearefs='ex-goDeps-3'>
<para>
<varname>fetch type</varname> that needs to be used to get package
source. If <varname>git</varname> is used there should be
<varname>url</varname>, <varname>rev</varname> and
<varname>sha256</varname> defined next to it.
<varname>fetch type</varname> that needs to be used to get package source. If <varname>git</varname> is used there should be <varname>url</varname>, <varname>rev</varname> and <varname>sha256</varname> defined next to it.
</para>
</callout>
</calloutlist>
</para>
<para>
To extract dependency information from a Go package in automated way use
<linkxlink:href="https://github.com/kamilchm/go2nix">go2nix</link>. It can
produce complete derivation and <varname>goDeps</varname> file for Go
programs.
To extract dependency information from a Go package in automated way use<linkxlink:href="https://github.com/kamilchm/go2nix">go2nix</link>. It can produce complete derivation and <varname>goDeps</varname> file for Go programs.
</para>
<para>
<varname>buildGoPackage</varname> produces
<xreflinkend='chap-multiple-output'xrefstyle="select: title"/> where
<varname>bin</varname> includes program binaries. You can test build a Go
binary as follows:
<varname>buildGoPackage</varname> produces<xreflinkend='chap-multiple-output'xrefstyle="select: title"/> where <varname>bin</varname> includes program binaries. You can test build a Go binary as follows:
<screen>
<prompt>$ </prompt>nix-build -A deis.bin
</screen>
@@ -224,13 +191,11 @@ deis = buildGoPackage rec {
<screen>
<prompt>$ </prompt>nix-build -A deis.all
</screen>
<varname>bin</varname> output will be installed by default with
<varname>nix-env -i</varname> or <varname>systemPackages</varname>.
<varname>bin</varname> output will be installed by default with<varname>nix-env -i</varname> or <varname>systemPackages</varname>.
</para>
<para>
You may use Go packages installed into the active Nix profiles by adding the
following to your ~/.bashrc:
You may use Go packages installed into the active Nix profiles by adding the following to your ~/.bashrc:
<title>Support for specific programming languages and frameworks</title>
<title>Languages and frameworks</title>
<para>
The <linklinkend="chap-stdenv">standard build environment</link> makes it
easy to build typical Autotools-based packages with very little code. Any
other kind of package can be accomodated by overriding the appropriate phases
of <literal>stdenv</literal>. However, there are specialised functions in
Nixpkgs to easily build packages for other programming languages, such as
Perl or Haskell. These are described in this chapter.
The <linklinkend="chap-stdenv">standard build environment</link> makes it easy to build typical Autotools-based packages with very little code. Any other kind of package can be accomodated by overriding the appropriate phases of <literal>stdenv</literal>. However, there are specialised functions in Nixpkgs to easily build packages for other programming languages, such as Perl or Haskell. These are described in this chapter.
Note that <varname>jdk</varname> is an alias for the OpenJDK (self-built
where available, or pre-built via Zulu). Platforms with OpenJDK not (yet) in
Nixpkgs (<literal>Aarch32</literal>, <literal>Aarch64</literal>) point to the
(unfree) <literal>oraclejdk</literal>.
Note that <varname>jdk</varname> is an alias for the OpenJDK (self-built where available, or pre-built via Zulu). Platforms with OpenJDK not (yet) in Nixpkgs (<literal>Aarch32</literal>, <literal>Aarch64</literal>) point to the (unfree) <literal>oraclejdk</literal>.
</para>
<para>
JAR files that are intended to be used by other packages should be installed
in <filename>$out/share/java</filename>. JDKs have a stdenv setup hook that
add any JARs in the <filename>share/java</filename> directories of the build
inputs to the <envar>CLASSPATH</envar> environment variable. For instance, if
the package <literal>libfoo</literal> installs a JAR named
<filename>foo.jar</filename> in its <filename>share/java</filename>
directory, and another package declares the attribute
JAR files that are intended to be used by other packages should be installed in <filename>$out/share/java</filename>. JDKs have a stdenv setup hook that add any JARs in the <filename>share/java</filename> directories of the build inputs to the <envar>CLASSPATH</envar> environment variable. For instance, if the package <literal>libfoo</literal> installs a JAR named <filename>foo.jar</filename> in its <filename>share/java</filename> directory, and another package declares the attribute
Private JARs should be installed in a location like<filename>$out/share/<replaceable>package-name</replaceable></filename>.
</para>
<para>
If your Java package provides a program, you need to generate a wrapper
script to run it using the OpenJRE. You can use
<literal>makeWrapper</literal> for this:
If your Java package provides a program, you need to generate a wrapper script to run it using the OpenJRE. You can use <literal>makeWrapper</literal> for this:
Note the use of <literal>jre</literal>, which is the part of the OpenJDK
package that contains the Java Runtime Environment. By using
<literal>${jre}/bin/java</literal> instead of
<literal>${jdk}/bin/java</literal>, you prevent your package from depending
on the JDK at runtime.
Note the use of <literal>jre</literal>, which is the part of the OpenJDK package that contains the Java Runtime Environment. By using <literal>${jre}/bin/java</literal> instead of <literal>${jdk}/bin/java</literal>, you prevent your package from depending on the JDK at runtime.
</para>
<para>
Note all JDKs passthru <literal>home</literal>, so if your application
requires environment variables like <envar>JAVA_HOME</envar> being set, that
can be done in a generic fashion with the <literal>--set</literal> argument
of <literal>makeWrapper</literal>:
Note all JDKs passthru <literal>home</literal>, so if your application requires environment variables like <envar>JAVA_HOME</envar> being set, that can be done in a generic fashion with the <literal>--set</literal> argument of <literal>makeWrapper</literal>:
<programlisting>
--set JAVA_HOME ${jdk.home}
</programlisting>
</para>
<para>
It is possible to use a different Java compiler than <command>javac</command>
from the OpenJDK. For instance, to use the GNU Java Compiler:
It is possible to use a different Java compiler than <command>javac</command> from the OpenJDK. For instance, to use the GNU Java Compiler:
<programlisting>
nativeBuildInputs = [ gcj ant ];
</programlisting>
Here, Ant will automatically use <command>gij</command> (the GNU Java
Runtime) instead of the OpenJRE.
Here, Ant will automatically use <command>gij</command> (the GNU Java Runtime) instead of the OpenJRE.
and works similarly to <varname>buildPerlPackage</varname>. (See
<xreflinkend="sec-language-perl"/> for details.)
Lua packages are built by the <varname>buildLuaPackage</varname> function. This function is implemented in <linkxlink:href="https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/lua-modules/generic/default.nix"><filename>pkgs/development/lua-modules/generic/default.nix</filename></link> and works similarly to <varname>buildPerlPackage</varname>. (See <xreflinkend="sec-language-perl"/> for details.)
Lua packages are defined in<linkxlink:href="https://github.com/NixOS/nixpkgs/blob/master/pkgs/top-level/lua-packages.nix"><filename>pkgs/top-level/lua-packages.nix</filename></link>. Most of them are simple. For example:
Lua packages accept additional parameter <varname>disabled</varname>, which
defines the condition of disabling package from luaPackages. For example, if
package has <varname>disabled</varname> assigned to <literal>lua.luaversion
!= "5.1"</literal>, it will not be included in any luaPackages except
lua51Packages, making it only be built for lua 5.1.
Lua packages accept additional parameter <varname>disabled</varname>, which defines the condition of disabling package from luaPackages. For example, if package has <varname>disabled</varname> assigned to <literal>lua.luaversion != "5.1"</literal>, it will not be included in any luaPackages except lua51Packages, making it only be built for lua 5.1.
<literal>$(out)/lib/ocaml/${ocaml.version}/site-lib/</literal>. Such
directories are automatically added to the <literal>$OCAMLPATH</literal>
environment variable when building another package that depends on them or
when opening a <literal>nix-shell</literal>.
OCaml libraries should be installed in<literal>$(out)/lib/ocaml/${ocaml.version}/site-lib/</literal>. Such directories are automatically added to the <literal>$OCAMLPATH</literal> environment variable when building another package that depends on them or when opening a <literal>nix-shell</literal>.
</para>
<para>
Given that most of the OCaml ecosystem is now built with dune, nixpkgs
includes a convenience build support function called
<literal>buildDunePackage</literal> that will build an OCaml package using
dune, OCaml and findlib and any additional dependencies provided as
<literal>buildInputs</literal> or <literal>propagatedBuildInputs</literal>.
Given that most of the OCaml ecosystem is now built with dune, nixpkgs includes a convenience build support function called <literal>buildDunePackage</literal> that will build an OCaml package using dune, OCaml and findlib and any additional dependencies provided as <literal>buildInputs</literal> or <literal>propagatedBuildInputs</literal>.
</para>
<para>
Here is a simple package example. It defines an (optional) attribute
<literal>minimumOCamlVersion</literal> that will be used to throw a
descriptive evaluation error if building with an older OCaml is attempted. It
uses the <literal>fetchFromGitHub</literal> fetcher to get its source. It
sets the <literal>doCheck</literal> (optional) attribute to
<literal>true</literal> which means that tests will be run with <literal>dune
runtest -p angstrom</literal> after the build (<literal>dune build -p
angstrom</literal>) is complete. It uses <literal>alcotest</literal> as a
build input (because it is needed to run the tests) and
<literal>bigstringaf</literal> and <literal>result</literal> as propagated
build inputs (thus they will also be available to libraries depending on this
library). The library will be installed using the
<literal>angstrom.install</literal> file that dune generates.
Here is a simple package example. It defines an (optional) attribute<literal>minimumOCamlVersion</literal> that will be used to throw a descriptive evaluation error if building with an older OCaml is attempted. It uses the <literal>fetchFromGitHub</literal> fetcher to get its source. It sets the <literal>doCheck</literal> (optional) attribute to <literal>true</literal> which means that tests will be run with <literal>dune runtest -p angstrom</literal> after the build (<literal>dune build -p angstrom</literal>) is complete. It uses <literal>alcotest</literal> as a build input (because it is needed to run the tests) and <literal>bigstringaf</literal> and <literal>result</literal> as propagated build inputs (thus they will also be available to libraries depending on this library). The library will be installed using the <literal>angstrom.install</literal> file that dune generates.
</para>
<programlisting>
@@ -65,11 +45,7 @@ buildDunePackage rec {
</programlisting>
<para>
Here is a second example, this time using a source archive generated with
<literal>dune-release</literal>. It is a good idea to use this archive when
it is available as it will usually contain substituted variables such as a
<literal>%%VERSION%%</literal> field. This library does not depend on any
other OCaml library and no tests are run after building it.
Here is a second example, this time using a source archive generated with<literal>dune-release</literal>. It is a good idea to use this archive when it is available as it will usually contain substituted variables such as a <literal>%%VERSION%%</literal> field. This library does not depend on any other OCaml library and no tests are run after building it.
Nixpkgs provides a function <varname>buildPerlPackage</varname>, a generic
package builder function for any Perl package that has a standard
<varname>Makefile.PL</varname>. It’s implemented in
<link
Nixpkgs provides a function <varname>buildPerlPackage</varname>, a generic package builder function for any Perl package that has a standard <varname>Makefile.PL</varname>. It’s implemented in <link
rather than <filename>pkgs/all-packages.nix</filename>. Most Perl packages
are so straight-forward to build that they are defined here directly, rather
than having a separate function for each package called from
<filename>perl-packages.nix</filename>. However, more complicated packages
should be put in a separate file, typically in
<filename>pkgs/development/perl-modules</filename>. Here is an example of the
former:
Perl packages from CPAN are defined in<link
xlink:href="https://github.com/NixOS/nixpkgs/blob/master/pkgs/top-level/perl-packages.nix"><filename>pkgs/top-level/perl-packages.nix</filename></link>, rather than <filename>pkgs/all-packages.nix</filename>. Most Perl packages are so straight-forward to build that they are defined here directly, rather than having a separate function for each package called from <filename>perl-packages.nix</filename>. However, more complicated packages should be put in a separate file, typically in <filename>pkgs/development/perl-modules</filename>. Here is an example of the former:
Note the use of <literal>mirror://cpan/</literal>, and the
<literal>${name}</literal> in the URL definition to ensure that the name
attribute is consistent with the source that we’re actually downloading.
Perl packages are made available in <filename>all-packages.nix</filename>
through the variable <varname>perlPackages</varname>. For instance, if you
have a package that needs <varname>ClassC3</varname>, you would typically
write
Note the use of <literal>mirror://cpan/</literal>, and the<literal>${name}</literal> in the URL definition to ensure that the name attribute is consistent with the source that we’re actually downloading. Perl packages are made available in <filename>all-packages.nix</filename> through the variable <varname>perlPackages</varname>. For instance, if you have a package that needs <varname>ClassC3</varname>, you would typically write
<programlisting>
foo = import ../path/to/foo.nix {
inherit stdenv fetchurl ...;
inherit (perlPackages) ClassC3;
};
</programlisting>
in <filename>all-packages.nix</filename>. You can test building a Perl
package as follows:
in <filename>all-packages.nix</filename>. You can test building a Perl package as follows:
<screen>
<prompt>$ </prompt>nix-build -A perlPackages.ClassC3
</screen>
<varname>buildPerlPackage</varname> adds <literal>perl-</literal> to the
start of the name attribute, so the package above is actually called
<literal>perl-Class-C3-0.21</literal>. So to install it, you can say:
<varname>buildPerlPackage</varname> adds <literal>perl-</literal> to the start of the name attribute, so the package above is actually called <literal>perl-Class-C3-0.21</literal>. So to install it, you can say:
<screen>
<prompt>$ </prompt>nix-env -i perl-Class-C3
</screen>
(Of course you can also install using the attribute name: <literal>nix-env -i
-A perlPackages.ClassC3</literal>.)
(Of course you can also install using the attribute name: <literal>nix-env -i -A perlPackages.ClassC3</literal>.)
In the configure phase, it calls <literal>perl Makefile.PL</literal> to
generate a Makefile. You can set the variable
<varname>makeMakerFlags</varname> to pass flags to
<filename>Makefile.PL</filename>
In the configure phase, it calls <literal>perl Makefile.PL</literal> to generate a Makefile. You can set the variable <varname>makeMakerFlags</varname> to pass flags to <filename>Makefile.PL</filename>
</para>
</listitem>
<listitem>
<para>
It adds the contents of the <envar>PERL5LIB</envar> environment variable
to <literal>#! .../bin/perl</literal> line of Perl scripts as
<literal>-I<replaceable>dir</replaceable></literal> flags. This ensures
that a script can find its dependencies. (This can cause this shebang line
to become too long for Darwin to handle; see the note below.)
It adds the contents of the <envar>PERL5LIB</envar> environment variable to <literal>#! .../bin/perl</literal> line of Perl scripts as <literal>-I<replaceable>dir</replaceable></literal> flags. This ensures that a script can find its dependencies. (This can cause this shebang line to become too long for Darwin to handle; see the note below.)
</para>
</listitem>
<listitem>
<para>
In the fixup phase, it writes the propagated build inputs
(<varname>propagatedBuildInputs</varname>) to the file
<command>nix-env</command> recursively installs all packages listed in
this file when you install a package that has it. This ensures that a Perl
package can find its dependencies.
In the fixup phase, it writes the propagated build inputs (<varname>propagatedBuildInputs</varname>) to the file <filename>$out/nix-support/propagated-user-env-packages</filename>. <command>nix-env</command> recursively installs all packages listed in this file when you install a package that has it. This ensures that a Perl package can find its dependencies.
</para>
</listitem>
</orderedlist>
</para>
<para>
<varname>buildPerlPackage</varname> is built on top of
<varname>stdenv</varname>, so everything can be customised in the usual way.
For instance, the <literal>BerkeleyDB</literal> module has a
<varname>preConfigure</varname> hook to generate a configuration file used by
<filename>Makefile.PL</filename>:
<varname>buildPerlPackage</varname> is built on top of<varname>stdenv</varname>, so everything can be customised in the usual way. For instance, the <literal>BerkeleyDB</literal> module has a <varname>preConfigure</varname> hook to generate a configuration file used by <filename>Makefile.PL</filename>:
<programlisting>
{ buildPerlPackage, fetchurl, db }:
@@ -118,12 +81,7 @@ buildPerlPackage rec {
</para>
<para>
Dependencies on other Perl packages can be specified in the
<varname>buildInputs</varname> and <varname>propagatedBuildInputs</varname>
attributes. If something is exclusively a build-time dependency, use
<varname>buildInputs</varname>; if it’s (also) a runtime dependency, use
<varname>propagatedBuildInputs</varname>. For instance, this builds a Perl
module that has runtime dependencies on a bunch of other modules:
Dependencies on other Perl packages can be specified in the<varname>buildInputs</varname> and <varname>propagatedBuildInputs</varname> attributes. If something is exclusively a build-time dependency, use <varname>buildInputs</varname>; if it’s (also) a runtime dependency, use <varname>propagatedBuildInputs</varname>. For instance, this builds a Perl module that has runtime dependencies on a bunch of other modules:
<literal>-I<replaceable>dir</replaceable></literal> flags in its first line
(its “shebang line”), it will not run. This can be worked around by calling
the <literal>shortenPerlShebang</literal> function from the
<literal>postInstall</literal> phase:
On Darwin, if a script has too many<literal>-I<replaceable>dir</replaceable></literal> flags in its first line (its “shebang line”), it will not run. This can be worked around by calling the <literal>shortenPerlShebang</literal> function from the <literal>postInstall</literal> phase:
This will remove the <literal>-I</literal> flags from the shebang line,
rewrite them in the <literal>use lib</literal> form, and put them on the next
line instead. This function can be given any number of Perl scripts as
arguments; it will modify them in-place.
This will remove the <literal>-I</literal> flags from the shebang line, rewrite them in the <literal>use lib</literal> form, and put them on the next line instead. This function can be given any number of Perl scripts as arguments; it will modify them in-place.
</para>
<sectionxml:id="ssec-generation-from-CPAN">
<title>Generation from CPAN</title>
<para>
Nix expressions for Perl packages can be generated (almost) automatically
from CPAN. This is done by the program
<command>nix-generate-from-cpan</command>, which can be installed as
follows:
Nix expressions for Perl packages can be generated (almost) automatically from CPAN. This is done by the program <command>nix-generate-from-cpan</command>, which can be installed as follows:
This program takes a Perl module name, looks it up on CPAN, fetches and
unpacks the corresponding package, and prints a Nix expression on standard
output. For example:
This program takes a Perl module name, looks it up on CPAN, fetches and unpacks the corresponding package, and prints a Nix expression on standard output. For example:
Nixpkgs has experimental support for cross-compiling Perl modules. In many
cases, it will just work out of the box, even for modules with native
extensions. Sometimes, however, the Makefile.PL for a module may
(indirectly) import a native module. In that case, you will need to make a
stub for that module that will satisfy the Makefile.PL and install it into
<filename>lib/perl5/site_perl/cross_perl/${perl.version}</filename>. See the
<varname>postInstall</varname> for <varname>DBI</varname> for an example.
Nixpkgs has experimental support for cross-compiling Perl modules. In many cases, it will just work out of the box, even for modules with native extensions. Sometimes, however, the Makefile.PL for a module may (indirectly) import a native module. In that case, you will need to make a stub for that module that will satisfy the Makefile.PL and install it into <filename>lib/perl5/site_perl/cross_perl/${perl.version}</filename>. See the <varname>postInstall</varname> for <varname>DBI</varname> for an example.
@@ -803,6 +803,9 @@ should be used with `ignoreCollisions = true`.
The following are setup hooks specifically for Python packages. Most of these are
used in `buildPythonPackage`.
- `eggUnpackhook` to move an egg to the correct folder so it can be installed with the `eggInstallHook`
- `eggBuildHook` to skip building for eggs.
- `eggInstallHook` to install eggs.
- `flitBuildHook` to build a wheel using `flit`.
- `pipBuildHook` to build a wheel using `pip` and PEP 517. Note a build system (e.g. `setuptools` or `flit`) should still be added as `nativeBuildInput`.
This section describes the differences between Nix expressions for Qt
libraries and applications and Nix expressions for other C++ software. Some
knowledge of the latter is assumed. There are primarily two problems which
the Qt infrastructure is designed to address: ensuring consistent versioning
of all dependencies and finding dependencies at runtime.
This section describes the differences between Nix expressions for Qt libraries and applications and Nix expressions for other C++ software. Some knowledge of the latter is assumed. There are primarily two problems which the Qt infrastructure is designed to address: ensuring consistent versioning of all dependencies and finding dependencies at runtime.
</para>
<examplexml:id='qt-default-nix'>
<title>Nix expression for a Qt package (<filename>default.nix</filename>)</title>
<programlisting>
<title>Nix expression for a Qt package (<filename>default.nix</filename>)</title>
is a wrapper around <literal>stdenv.mkDerivation</literal> which
applies some Qt-specific settings.
This deriver accepts the same arguments as
<literal>stdenv.mkDerivation</literal>; refer to
<xreflinkend='chap-stdenv'/> for details.
</para>
<para>
To use another deriver instead of
<literal>stdenv.mkDerivation</literal>, use
<literal>mkDerivationWith</literal>:
<calloutarearefs='qt-default-nix-co-1'>
<para>
Import <literal>mkDerivation</literal> and Qt (such as<literal>qtbase</literal> modules directly. <emphasis>Do not</emphasis> import Qt package sets; the Qt versions of dependencies may not be coherent, causing build and runtime failures.
</para>
</callout>
<calloutarearefs='qt-default-nix-co-2'>
<para>
Use <literal>mkDerivation</literal> instead of <literal>stdenv.mkDerivation</literal>. <literal>mkDerivation</literal> is a wrapper around <literal>stdenv.mkDerivation</literal> which applies some Qt-specific settings. This deriver accepts the same arguments as <literal>stdenv.mkDerivation</literal>; refer to <xreflinkend='chap-stdenv'/> for details.
</para>
<para>
To use another deriver instead of<literal>stdenv.mkDerivation</literal>, use <literal>mkDerivationWith</literal>:
<programlisting>
mkDerivationWith myDeriver {
# ...
}
</programlisting>
If you cannot use <literal>mkDerivationWith</literal>, please refer to
<xreflinkend='qt-runtime-dependencies'/>.
</para>
</callout>
<calloutarearefs='qt-default-nix-co-3'>
<para>
<literal>mkDerivation</literal> accepts the same arguments as
<literal>stdenv.mkDerivation</literal>, such as
<literal>buildInputs</literal>.
</para>
</callout>
If you cannot use <literal>mkDerivationWith</literal>, please refer to<xreflinkend='qt-runtime-dependencies'/>.
</para>
</callout>
<callout arearefs='qt-default-nix-co-3'>
<para>
<literal>mkDerivation</literal> accepts the same arguments as <literal>stdenv.mkDerivation</literal>, such as <literal>buildInputs</literal>.
</para>
</callout>
</calloutlist>
<formalparaxml:id='qt-runtime-dependencies'>
<title>Locating runtime dependencies</title>
<para>
Qt applications need to be wrapped to find runtime dependencies. If you
cannot use <literal>mkDerivation</literal> or
<literal>mkDerivationWith</literal> above, include
<literal>wrapQtAppsHook</literal> in <literal>nativeBuildInputs</literal>:
<title>Locating runtime dependencies</title>
<para>
Qt applications need to be wrapped to find runtime dependencies. If you cannot use <literal>mkDerivation</literal> or <literal>mkDerivationWith</literal> above, include <literal>wrapQtAppsHook</literal> in <literal>nativeBuildInputs</literal>:
<programlisting>
stdenv.mkDerivation {
# ...
@@ -80,13 +59,11 @@ stdenv.mkDerivation {
nativeBuildInputs = [ wrapQtAppsHook ];
}
</programlisting>
</para>
</para>
</formalpara>
<para>
Entries added to <literal>qtWrapperArgs</literal> are used to modify the
wrappers created by <literal>wrapQtAppsHook</literal>. The entries are
passed as arguments to <xreflinkend='fun-wrapProgram'/>.
Entries added to <literal>qtWrapperArgs</literal> are used to modify the wrappers created by <literal>wrapQtAppsHook</literal>. The entries are passed as arguments to <xreflinkend='fun-wrapProgram'/>.
<programlisting>
mkDerivation {
# ...
@@ -97,10 +74,7 @@ mkDerivation {
</para>
<para>
Set <literal>dontWrapQtApps</literal> to stop applications from being
wrapped automatically. It is required to wrap applications manually with
<literal>wrapQtApp</literal>, using the syntax of
<xreflinkend='fun-wrapProgram'/>:
Set <literal>dontWrapQtApps</literal> to stop applications from being wrapped automatically. It is required to wrap applications manually with <literal>wrapQtApp</literal>, using the syntax of <xreflinkend='fun-wrapProgram'/>:
<programlisting>
mkDerivation {
# ...
@@ -115,16 +89,12 @@ mkDerivation {
<note>
<para>
<literal>wrapQtAppsHook</literal> ignores files that are non-ELF executables.
This means that scripts won't be automatically wrapped so you'll need to manually
wrap them as previously mentioned. An example of when you'd always need to do this
is with Python applications that use PyQT.
<literal>wrapQtAppsHook</literal> ignores files that are non-ELF executables. This means that scripts won't be automatically wrapped so you'll need to manually wrap them as previously mentioned. An example of when you'd always need to do this is with Python applications that use PyQT.
</para>
</note>
<para>
Libraries are built with every available version of Qt. Use the <literal>meta.broken</literal>
attribute to disable the package for unsupported Qt versions:
Libraries are built with every available version of Qt. Use the <literal>meta.broken</literal> attribute to disable the package for unsupported Qt versions:
<programlisting>
mkDerivation {
# ...
@@ -136,13 +106,11 @@ mkDerivation {
</para>
<formalpara>
<title>Adding a library to Nixpkgs</title>
<para>
Add a Qt library to <filename>all-packages.nix</filename> by adding it to the
collection inside <literal>mkLibsForQt5</literal>. This ensures that the
library is built with every available version of Qt as needed.
<examplexml:id='qt-library-all-packages-nix'>
<title>Adding a Qt library to <filename>all-packages.nix</filename></title>
<title>Adding a library to Nixpkgs</title>
<para>
Add a Qt library to <filename>all-packages.nix</filename> by adding it to the collection inside <literal>mkLibsForQt5</literal>. This ensures that the library is built with every available version of Qt as needed.
<examplexml:id='qt-library-all-packages-nix'>
<title>Adding a Qt library to <filename>all-packages.nix</filename></title>
<programlisting>
{
# ...
@@ -156,19 +124,16 @@ mkDerivation {
# ...
}
</programlisting>
</example>
</para>
</example>
</para>
</formalpara>
<formalpara>
<title>Adding an application to Nixpkgs</title>
<para>
Add a Qt application to <filename>all-packages.nix</filename> using
<literal>libsForQt5.callPackage</literal> instead of the usual
<literal>callPackage</literal>. The former ensures that all dependencies
are built with the same version of Qt.
<examplexml:id='qt-application-all-packages-nix'>
<title>Adding a Qt application to <filename>all-packages.nix</filename></title>
<title>Adding an application to Nixpkgs</title>
<para>
Add a Qt application to <filename>all-packages.nix</filename> using<literal>libsForQt5.callPackage</literal> instead of the usual <literal>callPackage</literal>. The former ensures that all dependencies are built with the same version of Qt.
<examplexml:id='qt-application-all-packages-nix'>
<title>Adding a Qt application to <filename>all-packages.nix</filename></title>
There currently is support to bundle applications that are packaged as Ruby
gems. The utility "bundix" allows you to write a
<filename>Gemfile</filename>, let bundler create a
<filename>Gemfile.lock</filename>, and then convert this into a nix
expression that contains all Gem dependencies automatically.
There currently is support to bundle applications that are packaged as Ruby gems. The utility "bundix" allows you to write a <filename>Gemfile</filename>, let bundler create a <filename>Gemfile.lock</filename>, and then convert this into a nix expression that contains all Gem dependencies automatically.
</para>
<para>
@@ -45,9 +41,7 @@ bundlerEnv rec {
</screen>
<para>
Please check in the <filename>Gemfile</filename>,
<filename>Gemfile.lock</filename> and the <filename>gemset.nix</filename> so
future updates can be run easily.
Please check in the <filename>Gemfile</filename>,<filename>Gemfile.lock</filename> and the <filename>gemset.nix</filename> so future updates can be run easily.
For tools written in Ruby - i.e. where the desire is to install a package and
then execute e.g. <command>rake</command> at the command line, there is an
alternative builder called <literal>bundlerApp</literal>. Set up the
<filename>gemset.nix</filename> the same way, and then, for example:
For tools written in Ruby - i.e. where the desire is to install a package and then execute e.g. <command>rake</command> at the command line, there is an alternative builder called <literal>bundlerApp</literal>. Set up the <filename>gemset.nix</filename> the same way, and then, for example:
</para>
<screen>
@@ -87,29 +78,11 @@ bundlerApp {
</screen>
<para>
The chief advantage of <literal>bundlerApp</literal> over
<literal>bundlerEnv</literal> is the executables introduced in the
environment are precisely those selected in the <literal>exes</literal> list,
as opposed to <literal>bundlerEnv</literal> which adds all the executables
made available by gems in the gemset, which can mean e.g.
<command>rspec</command> or <command>rake</command> in unpredictable versions
available from various packages.
The chief advantage of <literal>bundlerApp</literal> over<literal>bundlerEnv</literal> is the executables introduced in the environment are precisely those selected in the <literal>exes</literal> list, as opposed to <literal>bundlerEnv</literal> which adds all the executables made available by gems in the gemset, which can mean e.g. <command>rspec</command> or <command>rake</command> in unpredictable versions available from various packages.
</para>
<para>
Resulting derivations for both builders also have two helpful attributes,
<literal>env</literal> and <literal>wrappedRuby</literal>. The first one
allows one to quickly drop into <command>nix-shell</command> with the
specified environment present. E.g. <command>nix-shell -A sensu.env</command>
would give you an environment with Ruby preset so it has all the libraries
necessary for <literal>sensu</literal> in its paths. The second one can be
used to make derivations from custom Ruby scripts which have
<filename>Gemfile</filename>s with their dependencies specified. It is a
derivation with <command>ruby</command> wrapped so it can find all the needed
dependencies. For example, to make a derivation <literal>my-script</literal>
for a <filename>my-script.rb</filename> (which should be placed in
<filename>bin</filename>) you should run <command>bundix</command> as
specified above and then use <literal>bundlerEnv</literal> like this:
Resulting derivations for both builders also have two helpful attributes,<literal>env</literal> and <literal>wrappedRuby</literal>. The first one allows one to quickly drop into <command>nix-shell</command> with the specified environment present. E.g. <command>nix-shell -A sensu.env</command> would give you an environment with Ruby preset so it has all the libraries necessary for <literal>sensu</literal> in its paths. The second one can be used to make derivations from custom Ruby scripts which have <filename>Gemfile</filename>s with their dependencies specified. It is a derivation with <command>ruby</command> wrapped so it can find all the needed dependencies. For example, to make a derivation <literal>my-script</literal> for a <filename>my-script.rb</filename> (which should be placed in <filename>bin</filename>) you should run <command>bundix</command> as specified above and then use <literal>bundlerEnv</literal> like this:
There are all the schemes, collections and a few thousand packages, as
defined upstream (perhaps with tiny differences).
There are all the schemes, collections and a few thousand packages, as defined upstream (perhaps with tiny differences).
</para>
</listitem>
<listitem>
<para>
By default you only get executables and files needed during runtime, and a
little documentation for the core packages. To change that, you need to
add <varname>pkgFilter</varname> function to <varname>combine</varname>.
By default you only get executables and files needed during runtime, and a little documentation for the core packages. To change that, you need to add <varname>pkgFilter</varname> function to <varname>combine</varname>.
Note that the wrapper assumes that the result has a chance to be useful.
For example, the core executables should be present, as well as some core
data files. The supported way of ensuring this is by including some
scheme, for example <varname>scheme-basic</varname>, into the combination.
Note that the wrapper assumes that the result has a chance to be useful. For example, the core executables should be present, as well as some core data files. The supported way of ensuring this is by including some scheme, for example <varname>scheme-basic</varname>, into the combination.
Nix packages can declare <emphasis>meta-attributes</emphasis> that contain
information about a package such as a description, its homepage, its license,
and so on. For instance, the GNU Hello package has a <varname>meta</varname>
declaration like this:
Nix packages can declare <emphasis>meta-attributes</emphasis> that contain information about a package such as a description, its homepage, its license, and so on. For instance, the GNU Hello package has a <varname>meta</varname> declaration like this:
<programlisting>
meta = with stdenv.lib; {
description = "A program that produces a familiar, friendly greeting";
@@ -22,13 +19,10 @@ meta = with stdenv.lib; {
</programlisting>
</para>
<para>
Meta-attributes are not passed to the builder of the package. Thus, a change
to a meta-attribute doesn’t trigger a recompilation of the package. The
value of a meta-attribute must be a string.
Meta-attributes are not passed to the builder of the package. Thus, a change to a meta-attribute doesn’t trigger a recompilation of the package. The value of a meta-attribute must be a string.
</para>
<para>
The meta-attributes of a package can be queried from the command-line using
<command>nix-env</command>:
The meta-attributes of a package can be queried from the command-line using<command>nix-env</command>:
<screen>
<prompt>$ </prompt>nix-env -qa hello --json
{
@@ -67,8 +61,7 @@ meta = with stdenv.lib; {
</screen>
<command>nix-env</command> knows about the <varname>description</varname>
field specifically:
<command>nix-env</command> knows about the <varname>description</varname> field specifically:
hello-2.3 A program that produces a familiar, friendly greeting
@@ -88,18 +81,13 @@ hello-2.3 A program that produces a familiar, friendly greeting
</term>
<listitem>
<para>
A short (one-line) description of the package. This is shown by
<command>nix-env -q --description</command> and also on the Nixpkgs
release pages.
A short (one-line) description of the package. This is shown by<command>nix-env -q --description</command> and also on the Nixpkgs release pages.
</para>
<para>
Don’t include a period at the end. Don’t include newline characters.
Capitalise the first character. For brevity, don’t repeat the name of
package — just describe what it does.
Don’t include a period at the end. Don’t include newline characters. Capitalise the first character. For brevity, don’t repeat the name of package — just describe what it does.
</para>
<para>
Wrong: <literal>"libpng is a library that allows you to decode PNG
images."</literal>
Wrong: <literal>"libpng is a library that allows you to decode PNG images."</literal>
</para>
<para>
Right: <literal>"A library for decoding PNG images"</literal>
@@ -122,9 +110,7 @@ hello-2.3 A program that produces a familiar, friendly greeting
</term>
<listitem>
<para>
Release branch. Used to specify that a package is not going to receive
updates that are not in this branch; for example, Linux kernel 3.0 is
supposed to be updated to 3.0.X, not 3.1.
Release branch. Used to specify that a package is not going to receive updates that are not in this branch; for example, Linux kernel 3.0 is supposed to be updated to 3.0.X, not 3.1.
</para>
</listitem>
</varlistentry>
@@ -134,8 +120,7 @@ hello-2.3 A program that produces a familiar, friendly greeting
A link or a list of links to the location of Changelog for a package. A link may use expansion to refer to the correct changelog version. Example: <literal>"https://git.savannah.gnu.org/cgit/hello.git/plain/NEWS?h=v${version}"</literal>
</para>
</listitem>
</varlistentry>
@@ -169,46 +150,32 @@ hello-2.3 A program that produces a familiar, friendly greeting
</term>
<listitem>
<para>
The license, or licenses, for the package. One from the attribute set
<filename>nixpkgs/lib/licenses.nix</filename></link>. At this moment
using both a list of licenses and a single license is valid. If the
license field is in the form of a list representation, then it means that
parts of the package are licensed differently. Each license should
preferably be referenced by their attribute. The non-list attribute value
can also be a space delimited string representation of the contained
attribute shortNames or spdxIds. The following are all valid examples:
The license, or licenses, for the package. One from the attribute set defined in <link
xlink:href="https://github.com/NixOS/nixpkgs/blob/master/lib/licenses.nix"><filename>nixpkgs/lib/licenses.nix</filename></link>. At this moment using both a list of licenses and a single license is valid. If the license field is in the form of a list representation, then it means that parts of the package are licensed differently. Each license should preferably be referenced by their attribute. The non-list attribute value can also be a space delimited string representation of the contained attribute shortNames or spdxIds. The following are all valid examples:
<itemizedlist>
<listitem>
<para>
Single license referenced by attribute (preferred)
<literal>stdenv.lib.licenses.gpl3</literal>.
Single license referenced by attribute (preferred)<literal>stdenv.lib.licenses.gpl3</literal>.
</para>
</listitem>
<listitem>
<para>
Single license referenced by its attribute shortName (frowned upon)
<literal>"gpl3"</literal>.
Single license referenced by its attribute shortName (frowned upon)<literal>"gpl3"</literal>.
</para>
</listitem>
<listitem>
<para>
Single license referenced by its attribute spdxId (frowned upon)
<literal>"GPL-3.0"</literal>.
Single license referenced by its attribute spdxId (frowned upon)<literal>"GPL-3.0"</literal>.
</para>
</listitem>
<listitem>
<para>
Multiple licenses referenced by attribute (preferred) <literal>with
and write something like <literal>[ stdenv.lib.maintainers.alice
stdenv.lib.maintainers.bob ]</literal>.
A list of names and e-mail addresses of the maintainers of this Nix expression. If you would like to be a maintainer of a package, you may want to add yourself to <link
xlink:href="https://github.com/NixOS/nixpkgs/blob/master/maintainers/maintainer-list.nix"><filename>nixpkgs/maintainers/maintainer-list.nix</filename></link> and write something like <literal>[ stdenv.lib.maintainers.alice stdenv.lib.maintainers.bob ]</literal>.
</para>
</listitem>
</varlistentry>
@@ -238,10 +200,7 @@ hello-2.3 A program that produces a familiar, friendly greeting
</term>
<listitem>
<para>
The <emphasis>priority</emphasis> of the package, used by
<command>nix-env</command> to resolve file name conflicts between
packages. See the Nix manual page for <command>nix-env</command> for
details. Example: <literal>"10"</literal> (a low-priority package).
The <emphasis>priority</emphasis> of the package, used by<command>nix-env</command> to resolve file name conflicts between packages. See the Nix manual page for <command>nix-env</command> for details. Example: <literal>"10"</literal> (a low-priority package).
</para>
</listitem>
</varlistentry>
@@ -251,15 +210,11 @@ hello-2.3 A program that produces a familiar, friendly greeting
</term>
<listitem>
<para>
The list of Nix platform types on which the package is supported. Hydra
builds packages according to the platform specified. If no platform is
specified, the package does not have prebuilt binaries. An example is:
The list of Nix platform types on which the package is supported. Hydra builds packages according to the platform specified. If no platform is specified, the package does not have prebuilt binaries. An example is:
<programlisting>
meta.platforms = stdenv.lib.platforms.linux;
</programlisting>
Attribute Set <varname>stdenv.lib.platforms</varname> defines
Attribute Set <varname>stdenv.lib.platforms</varname> defines<linkxlink:href="https://github.com/NixOS/nixpkgs/blob/master/lib/systems/doubles.nix"> various common lists</link> of platforms types.
This attribute is special in that it is not actually under the
<literal>meta</literal> attribute set but rather under the
<literal>passthru</literal> attribute set. This is due to how
<literal>meta</literal> attributes work, and the fact that they
are supposed to contain only metadata, not derivations.
This attribute is special in that it is not actually under the<literal>meta</literal> attribute set but rather under the <literal>passthru</literal> attribute set. This is due to how <literal>meta</literal> attributes work, and the fact that they are supposed to contain only metadata, not derivations.
</para>
</warning>
<para>
An attribute set with as values tests. A test is a derivation, which
builds successfully when the test passes, and fails to build otherwise. A
derivation that is a test needs to have <literal>meta.timeout</literal>
defined.
An attribute set with as values tests. A test is a derivation, which builds successfully when the test passes, and fails to build otherwise. A derivation that is a test needs to have <literal>meta.timeout</literal> defined.
</para>
<para>
The NixOS tests are available as <literal>nixosTests</literal> in
parameters of derivations. For instance, the OpenSMTPD derivation
includes lines similar to:
The NixOS tests are available as <literal>nixosTests</literal> in parameters of derivations. For instance, the OpenSMTPD derivation includes lines similar to:
A timeout (in seconds) for building the derivation. If the derivation
takes longer than this time to build, it can fail due to breaking the
timeout. However, all computers do not have the same computing power,
hence some builders may decide to apply a multiplicative factor to this
value. When filling this value in, try to keep it approximately
consistent with other values already present in
<literal>nixpkgs</literal>.
A timeout (in seconds) for building the derivation. If the derivation takes longer than this time to build, it can fail due to breaking the timeout. However, all computers do not have the same computing power, hence some builders may decide to apply a multiplicative factor to this value. When filling this value in, try to keep it approximately consistent with other values already present in <literal>nixpkgs</literal>.
The list of Nix platform types for which the Hydra instance at
<literal>hydra.nixos.org</literal> will build the package. (Hydra is the
Nix-based continuous build system.) It defaults to the value of
<varname>meta.platforms</varname>. Thus, the only reason to set
<varname>meta.hydraPlatforms</varname> is if you want
<literal>hydra.nixos.org</literal> to build the package on a subset of
<varname>meta.platforms</varname>, or not at all, e.g.
The list of Nix platform types for which the Hydra instance at<literal>hydra.nixos.org</literal> will build the package. (Hydra is the Nix-based continuous build system.) It defaults to the value of <varname>meta.platforms</varname>. Thus, the only reason to set <varname>meta.hydraPlatforms</varname> is if you want <literal>hydra.nixos.org</literal> to build the package on a subset of <varname>meta.platforms</varname>, or not at all, e.g.
<programlisting>
meta.platforms = stdenv.lib.platforms.linux;
meta.hydraPlatforms = [];
@@ -341,10 +275,7 @@ meta.hydraPlatforms = [];
</term>
<listitem>
<para>
If set to <literal>true</literal>, the package is marked as “broken”,
meaning that it won’t show up in <literal>nix-env -qa</literal>, and
cannot be built or installed. Such packages should be removed from
Nixpkgs eventually unless they are fixed.
If set to <literal>true</literal>, the package is marked as “broken”, meaning that it won’t show up in <literal>nix-env -qa</literal>, and cannot be built or installed. Such packages should be removed from Nixpkgs eventually unless they are fixed.
</para>
</listitem>
</varlistentry>
@@ -354,12 +285,7 @@ meta.hydraPlatforms = [];
</term>
<listitem>
<para>
If set to <literal>true</literal>, the package is tested to be updated
correctly by the <literal>update-walker.sh</literal> script without
additional settings. Such packages have <varname>meta.version</varname>
set and their homepage (or the page specified by
<varname>meta.downloadPage</varname>) contains a direct link to the
package tarball.
If set to <literal>true</literal>, the package is tested to be updated correctly by the <literal>update-walker.sh</literal> script without additional settings. Such packages have <varname>meta.version</varname> set and their homepage (or the page specified by <varname>meta.downloadPage</varname>) contains a direct link to the package tarball.
</para>
</listitem>
</varlistentry>
@@ -369,17 +295,11 @@ meta.hydraPlatforms = [];
<title>Licenses</title>
<para>
The <varname>meta.license</varname> attribute should preferrably contain a
value from <varname>stdenv.lib.licenses</varname> defined in
<filename>nixpkgs/lib/licenses.nix</filename></link>, or in-place license
description of the same format if the license is unlikely to be useful in
another expression.
The <varname>meta.license</varname> attribute should preferrably contain a value from <varname>stdenv.lib.licenses</varname> defined in <linkxlink:href="https://github.com/NixOS/nixpkgs/blob/master/lib/licenses.nix"><filename>nixpkgs/lib/licenses.nix</filename></link>, or in-place license description of the same format if the license is unlikely to be useful in another expression.
</para>
<para>
Although it's typically better to indicate the specific license, a few
generic options are available:
Although it's typically better to indicate the specific license, a few generic options are available:
<variablelist>
<varlistentry>
<term>
@@ -397,18 +317,10 @@ meta.hydraPlatforms = [];
</term>
<listitem>
<para>
Unfree package that can be redistributed in binary form. That is, it’s
legal to redistribute the <emphasis>output</emphasis> of the derivation.
This means that the package can be included in the Nixpkgs channel.
Unfree package that can be redistributed in binary form. That is, it’s legal to redistribute the <emphasis>output</emphasis> of the derivation. This means that the package can be included in the Nixpkgs channel.
</para>
<para>
Sometimes proprietary software can only be redistributed unmodified.
Make sure the builder doesn’t actually modify the original binaries;
otherwise we’re breaking the license. For instance, the NVIDIA X11
drivers can be redistributed unmodified, but our builder applies
<command>patchelf</command> to make them work. Thus, its license is
<varname>"unfree"</varname> and it cannot be included in the Nixpkgs
channel.
Sometimes proprietary software can only be redistributed unmodified. Make sure the builder doesn’t actually modify the original binaries; otherwise we’re breaking the license. For instance, the NVIDIA X11 drivers can be redistributed unmodified, but our builder applies <command>patchelf</command> to make them work. Thus, its license is <varname>"unfree"</varname> and it cannot be included in the Nixpkgs channel.
</para>
</listitem>
</varlistentry>
@@ -418,9 +330,7 @@ meta.hydraPlatforms = [];
</term>
<listitem>
<para>
Unfree package that cannot be redistributed. You can build it yourself,
but you cannot redistribute the output of the derivation. Thus it cannot
be included in the Nixpkgs channel.
Unfree package that cannot be redistributed. You can build it yourself, but you cannot redistribute the output of the derivation. Thus it cannot be included in the Nixpkgs channel.
</para>
</listitem>
</varlistentry>
@@ -430,9 +340,7 @@ meta.hydraPlatforms = [];
</term>
<listitem>
<para>
This package supplies unfree, redistributable firmware. This is a
separate value from <varname>unfree-redistributable</varname> because
not everybody cares whether firmware is free.
This package supplies unfree, redistributable firmware. This is a separate value from <varname>unfree-redistributable</varname> because not everybody cares whether firmware is free.
The Nix language allows a derivation to produce multiple outputs, which is
similar to what is utilized by other Linux distribution packaging systems.
The outputs reside in separate Nix store paths, so they can be mostly
handled independently of each other, including passing to build inputs,
garbage collection or binary substitution. The exception is that building
from source always produces all the outputs.
The Nix language allows a derivation to produce multiple outputs, which is similar to what is utilized by other Linux distribution packaging systems. The outputs reside in separate Nix store paths, so they can be mostly handled independently of each other, including passing to build inputs, garbage collection or binary substitution. The exception is that building from source always produces all the outputs.
</para>
<para>
The main motivation is to save disk space by reducing runtime closure sizes;
consequently also sizes of substituted binaries get reduced. Splitting can
be used to have more granular runtime dependencies, for example the typical
reduction is to split away development-only files, as those are typically
not needed during runtime. As a result, closure sizes of many packages can
get reduced to a half or even much less.
The main motivation is to save disk space by reducing runtime closure sizes; consequently also sizes of substituted binaries get reduced. Splitting can be used to have more granular runtime dependencies, for example the typical reduction is to split away development-only files, as those are typically not needed during runtime. As a result, closure sizes of many packages can get reduced to a half or even much less.
</para>
<note>
<para>
The reduction effects could be instead achieved by building the parts in
completely separate derivations. That would often additionally reduce
build-time closures, but it tends to be much harder to write such
derivations, as build systems typically assume all parts are being built at
once. This compromise approach of single source package producing multiple
binary packages is also utilized often by rpm and deb.
The reduction effects could be instead achieved by building the parts in completely separate derivations. That would often additionally reduce build-time closures, but it tends to be much harder to write such derivations, as build systems typically assume all parts are being built at once. This compromise approach of single source package producing multiple binary packages is also utilized often by rpm and deb.
</para>
</note>
</section>
@@ -42,23 +27,18 @@
<title>Installing a split package</title>
<para>
When installing a package via <varname>systemPackages</varname> or
<command>nix-env</command> you have several options:
When installing a package via <varname>systemPackages</varname> or<command>nix-env</command> you have several options:
</para>
<itemizedlist>
<listitem>
<para>
You can install particular outputs explicitly, as each is available in the
Nix language as an attribute of the package. The
<varname>outputs</varname> attribute contains a list of output names.
You can install particular outputs explicitly, as each is available in the Nix language as an attribute of the package. The <varname>outputs</varname> attribute contains a list of output names.
</para>
</listitem>
<listitem>
<para>
You can let it use the default outputs. These are handled by
<varname>meta.outputsToInstall</varname> attribute that contains a list of
output names.
You can let it use the default outputs. These are handled by<varname>meta.outputsToInstall</varname> attribute that contains a list of output names.
</para>
<para>
TODO: more about tweaking the attribute, etc.
@@ -66,19 +46,11 @@
</listitem>
<listitem>
<para>
NixOS provides configuration option
<varname>environment.extraOutputsToInstall</varname> that allows adding
extra outputs of <varname>environment.systemPackages</varname> atop the
default ones. It's mainly meant for documentation and debug symbols, and
it's also modified by specific options.
NixOS provides configuration option<varname>environment.extraOutputsToInstall</varname> that allows adding extra outputs of <varname>environment.systemPackages</varname> atop the default ones. It's mainly meant for documentation and debug symbols, and it's also modified by specific options.
</para>
<note>
<para>
At this moment there is no similar configurability for packages installed
by <command>nix-env</command>. You can still use approach from
<xreflinkend="sec-modify-via-packageOverrides"/> to override
<varname>meta.outputsToInstall</varname> attributes, but that's a rather
inconvenient way.
At this moment there is no similar configurability for packages installed by <command>nix-env</command>. You can still use approach from <xreflinkend="sec-modify-via-packageOverrides"/> to override <varname>meta.outputsToInstall</varname> attributes, but that's a rather inconvenient way.
</para>
</note>
</listitem>
@@ -88,25 +60,15 @@
<title>Using a split package</title>
<para>
In the Nix language the individual outputs can be reached explicitly as
attributes, e.g. <varname>coreutils.info</varname>, but the typical case is
just using packages as build inputs.
In the Nix language the individual outputs can be reached explicitly as attributes, e.g. <varname>coreutils.info</varname>, but the typical case is just using packages as build inputs.
</para>
<para>
When a multiple-output derivation gets into a build input of another
derivation, the <varname>dev</varname> output is added if it exists,
otherwise the first output is added. In addition to that,
<varname>propagatedBuildOutputs</varname> of that package which by default
contain <varname>$outputBin</varname> and <varname>$outputLib</varname> are
also added. (See <xreflinkend="multiple-output-file-type-groups"/>.)
When a multiple-output derivation gets into a build input of another derivation, the <varname>dev</varname> output is added if it exists, otherwise the first output is added. In addition to that, <varname>propagatedBuildOutputs</varname> of that package which by default contain <varname>$outputBin</varname> and <varname>$outputLib</varname> are also added. (See <xreflinkend="multiple-output-file-type-groups"/>.)
</para>
<para>
In some cases it may be desirable to combine different outputs under a
single store path. A function <literal>symlinkJoin</literal> can be used to
do this. (Note that it may negate some closure size benefits of using a
multiple-output package.)
In some cases it may be desirable to combine different outputs under a single store path. A function <literal>symlinkJoin</literal> can be used to do this. (Note that it may negate some closure size benefits of using a multiple-output package.)
</para>
</section>
<sectionxml:id="sec-multiple-outputs-">
@@ -117,29 +79,18 @@
</para>
<para>
In nixpkgs there is a framework supporting multiple-output derivations. It
tries to cover most cases by default behavior. You can find the source
it's relatively well-readable. The whole machinery is triggered by defining
the <varname>outputs</varname> attribute to contain the list of desired
output names (strings).
In nixpkgs there is a framework supporting multiple-output derivations. It tries to cover most cases by default behavior. You can find the source separated in <<filename>nixpkgs/pkgs/build-support/setup-hooks/multiple-outputs.sh</filename>>; it's relatively well-readable. The whole machinery is triggered by defining the <varname>outputs</varname> attribute to contain the list of desired output names (strings).
Often such a single line is enough. For each output an equally named
environment variable is passed to the builder and contains the path in nix
store for that output. Typically you also want to have the main
<varname>out</varname> output, as it catches any files that didn't get
elsewhere.
Often such a single line is enough. For each output an equally named environment variable is passed to the builder and contains the path in nix store for that output. Typically you also want to have the main <varname>out</varname> output, as it catches any files that didn't get elsewhere.
</para>
<note>
<para>
There is a special handling of the <varname>debug</varname> output,
described at <xreflinkend="stdenv-separateDebugInfo"/>.
There is a special handling of the <varname>debug</varname> output, described at <xreflinkend="stdenv-separateDebugInfo"/>.
</para>
</note>
@@ -147,36 +98,15 @@
<title><quote>Binaries first</quote></title>
<para>
A commonly adopted convention in <literal>nixpkgs</literal> is that
executables provided by the package are contained within its first output.
This convention allows the dependent packages to reference the executables
provided by packages in a uniform manner. For instance, provided with the
knowledge that the <literal>perl</literal> package contains a
<literal>perl</literal> executable it can be referenced as
<literal>${pkgs.perl}/bin/perl</literal> within a Nix derivation that needs
to execute a Perl script.
A commonly adopted convention in <literal>nixpkgs</literal> is that executables provided by the package are contained within its first output. This convention allows the dependent packages to reference the executables provided by packages in a uniform manner. For instance, provided with the knowledge that the <literal>perl</literal> package contains a <literal>perl</literal> executable it can be referenced as <literal>${pkgs.perl}/bin/perl</literal> within a Nix derivation that needs to execute a Perl script.
</para>
<para>
The <literal>glibc</literal> package is a deliberate single exception to
the <quote>binaries first</quote> convention. The <literal>glibc</literal>
has <literal>libs</literal> as its first output allowing the libraries
provided by <literal>glibc</literal> to be referenced directly (e.g.
<literal>${stdenv.glibc}/lib/ld-linux-x86-64.so.2</literal>). The
executables provided by <literal>glibc</literal> can be accessed via its
<literal>bin</literal> attribute (e.g.
<literal>${stdenv.glibc.bin}/bin/ldd</literal>).
The <literal>glibc</literal> package is a deliberate single exception to the <quote>binaries first</quote> convention. The <literal>glibc</literal> has <literal>libs</literal> as its first output allowing the libraries provided by <literal>glibc</literal> to be referenced directly (e.g. <literal>${stdenv.glibc}/lib/ld-linux-x86-64.so.2</literal>). The executables provided by <literal>glibc</literal> can be accessed via its <literal>bin</literal> attribute (e.g. <literal>${stdenv.glibc.bin}/bin/ldd</literal>).
</para>
<para>
The reason for why <literal>glibc</literal> deviates from the convention is
because referencing a library provided by <literal>glibc</literal> is a
very common operation among Nix packages. For instance, third-party
executables packaged by Nix are typically patched and relinked with the
relevant version of <literal>glibc</literal> libraries from Nix packages
(please see the documentation on
<linkxlink:href="https://nixos.org/patchelf.html">patchelf</link> for more
details).
The reason for why <literal>glibc</literal> deviates from the convention is because referencing a library provided by <literal>glibc</literal> is a very common operation among Nix packages. For instance, third-party executables packaged by Nix are typically patched and relinked with the relevant version of <literal>glibc</literal> libraries from Nix packages (please see the documentation on <linkxlink:href="https://nixos.org/patchelf.html">patchelf</link> for more details).
</para>
</section>
@@ -184,13 +114,7 @@
<title>File type groups</title>
<para>
The support code currently recognizes some particular kinds of outputs and
either instructs the build system of the package to put files into their
desired outputs or it moves the files during the fixup phase. Each group of
file types has an <varname>outputFoo</varname> variable specifying the
output name where they should go. If that variable isn't defined by the
derivation writer, it is guessed – a default output name is defined,
falling back to other possibilities if the output isn't defined.
The support code currently recognizes some particular kinds of outputs and either instructs the build system of the package to put files into their desired outputs or it moves the files during the fixup phase. Each group of file types has an <varname>outputFoo</varname> variable specifying the output name where they should go. If that variable isn't defined by the derivation writer, it is guessed – a default output name is defined, falling back to other possibilities if the output isn't defined.
</para>
<variablelist>
@@ -200,9 +124,7 @@
</term>
<listitem>
<para>
is for development-only files. These include C(++) headers, pkg-config,
cmake and aclocal files. They go to <varname>dev</varname> or
<varname>out</varname> by default.
is for development-only files. These include C(++) headers, pkg-config, cmake and aclocal files. They go to <varname>dev</varname> or <varname>out</varname> by default.
</para>
</listitem>
</varlistentry>
@@ -212,8 +134,7 @@
</term>
<listitem>
<para>
is meant for user-facing binaries, typically residing in bin/. They go
to <varname>bin</varname> or <varname>out</varname> by default.
is meant for user-facing binaries, typically residing in bin/. They go to <varname>bin</varname> or <varname>out</varname> by default.
</para>
</listitem>
</varlistentry>
@@ -223,9 +144,7 @@
</term>
<listitem>
<para>
is meant for libraries, typically residing in <filename>lib/</filename>
and <filename>libexec/</filename>. They go to <varname>lib</varname> or
<varname>out</varname> by default.
is meant for libraries, typically residing in <filename>lib/</filename> and <filename>libexec/</filename>. They go to <varname>lib</varname> or <varname>out</varname> by default.
</para>
</listitem>
</varlistentry>
@@ -235,9 +154,7 @@
</term>
<listitem>
<para>
is for user documentation, typically residing in
<filename>share/doc/</filename>. It goes to <varname>doc</varname> or
<varname>out</varname> by default.
is for user documentation, typically residing in<filename>share/doc/</filename>. It goes to <varname>doc</varname> or <varname>out</varname> by default.
</para>
</listitem>
</varlistentry>
@@ -247,10 +164,7 @@
</term>
<listitem>
<para>
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 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.
</para>
</listitem>
</varlistentry>
@@ -260,8 +174,7 @@
</term>
<listitem>
<para>
is for man pages (except for section 3). They go to
<varname>man</varname> or <varname>$outputBin</varname> by default.
is for man pages (except for section 3). They go to<varname>man</varname> or <varname>$outputBin</varname> by default.
</para>
</listitem>
</varlistentry>
@@ -271,8 +184,7 @@
</term>
<listitem>
<para>
is for section 3 man pages. They go to <varname>devman</varname> or
<varname>$outputMan</varname> by default.
is for section 3 man pages. They go to <varname>devman</varname> or<varname>$outputMan</varname> by default.
</para>
</listitem>
</varlistentry>
@@ -282,8 +194,7 @@
</term>
<listitem>
<para>
is for info pages. They go to <varname>info</varname> or
<varname>$outputBin</varname> by default.
is for info pages. They go to <varname>info</varname> or<varname>$outputBin</varname> by default.
</para>
</listitem>
</varlistentry>
@@ -296,31 +207,22 @@
<itemizedlist>
<listitem>
<para>
Some configure scripts don't like some of the parameters passed by
default by the framework, e.g. <literal>--docdir=/foo/bar</literal>. You
can disable this by setting <literal>setOutputFlags = false;</literal>.
Some configure scripts don't like some of the parameters passed by default by the framework, e.g. <literal>--docdir=/foo/bar</literal>. You can disable this by setting <literal>setOutputFlags = false;</literal>.
</para>
</listitem>
<listitem>
<para>
The outputs of a single derivation can retain references to each other,
but note that circular references are not allowed. (And each
strongly-connected component would act as a single output anyway.)
The outputs of a single derivation can retain references to each other, but note that circular references are not allowed. (And each strongly-connected component would act as a single output anyway.)
</para>
</listitem>
<listitem>
<para>
Most of split packages contain their core functionality in libraries.
These libraries tend to refer to various kind of data that typically gets
into <varname>out</varname>, e.g. locale strings, so there is often no
advantage in separating the libraries into <varname>lib</varname>, as
keeping them in <varname>out</varname> is easier.
Most of split packages contain their core functionality in libraries. These libraries tend to refer to various kind of data that typically gets into <varname>out</varname>, e.g. locale strings, so there is often no advantage in separating the libraries into <varname>lib</varname>, as keeping them in <varname>out</varname> is easier.
</para>
</listitem>
<listitem>
<para>
Some packages have hidden assumptions on install paths, which complicates
splitting.
Some packages have hidden assumptions on install paths, which complicates splitting.
This chapter describes how to extend and change Nixpkgs using overlays.
Overlays are used to add layers in the fixed-point used by Nixpkgs to compose
the set of all packages.
This chapter describes how to extend and change Nixpkgs using overlays. Overlays are used to add layers in the fixed-point used by Nixpkgs to compose the set of all packages.
</para>
<para>
Nixpkgs can be configured with a list of overlays, which are applied in
order. This means that the order of the overlays can be significant if
multiple layers override the same package.
Nixpkgs can be configured with a list of overlays, which are applied in order. This means that the order of the overlays can be significant if multiple layers override the same package.
The list of overlays can be set either explicitly in a Nix expression, or
through <literal><nixpkgs-overlays></literal> or user configuration
files.
The list of overlays can be set either explicitly in a Nix expression, or through <literal><nixpkgs-overlays></literal> or user configuration files.
</para>
<sectionxml:id="sec-overlays-argument">
<title>Set overlays in NixOS or Nix expressions</title>
<para>
On a NixOS system the value of the <literal>nixpkgs.overlays</literal>
option, if present, is passed to the system Nixpkgs directly as an
argument. Note that this does not affect the overlays for non-NixOS
operations (e.g. <literal>nix-env</literal>), which are
<linkxlink:href="#sec-overlays-lookup">looked</link> up independently.
On a NixOS system the value of the <literal>nixpkgs.overlays</literal> option, if present, is passed to the system Nixpkgs directly as an argument. Note that this does not affect the overlays for non-NixOS operations (e.g. <literal>nix-env</literal>), which are <linkxlink:href="#sec-overlays-lookup">looked</link> up independently.
</para>
<para>
The list of overlays can be passed explicitly when importing nixpkgs, for
example <literal>import <nixpkgs> { overlays = [ overlay1 overlay2 ];
}</literal>.
The list of overlays can be passed explicitly when importing nixpkgs, for example <literal>import <nixpkgs> { overlays = [ overlay1 overlay2 ]; }</literal>.
</para>
<para>
Further overlays can be added by calling the <literal>pkgs.extend</literal>
or <literal>pkgs.appendOverlays</literal>, although it is often preferable
to avoid these functions, because they recompute the Nixpkgs fixpoint,
which is somewhat expensive to do.
Further overlays can be added by calling the <literal>pkgs.extend</literal> or <literal>pkgs.appendOverlays</literal>, although it is often preferable to avoid these functions, because they recompute the Nixpkgs fixpoint, which is somewhat expensive to do.
argument</link> to the Nixpkgs function itself is given, then that is
used and no path lookup will be performed.
First, if an<linkxlink:href="#sec-overlays-argument"><varname>overlays</varname> argument</link> to the Nixpkgs function itself is given, then that is used and no path lookup will be performed.
</para>
</listitem>
<listitem>
<para>
Otherwise, if the Nix path entry
<literal><nixpkgs-overlays></literal> exists, we look for overlays at
that path, as described below.
Otherwise, if the Nix path entry<literal><nixpkgs-overlays></literal> exists, we look for overlays at that path, as described below.
</para>
<para>
See the section on <literal>NIX_PATH</literal> in the Nix manual for
more details on how to set a value for
<literal><nixpkgs-overlays>.</literal>
See the section on <literal>NIX_PATH</literal> in the Nix manual for more details on how to set a value for <literal><nixpkgs-overlays>.</literal>
</para>
</listitem>
<listitem>
<para>
If one of <filename>~/.config/nixpkgs/overlays.nix</filename> and
<filename>~/.config/nixpkgs/overlays/</filename> exists, then we look
for overlays at that path, as described below. It is an error if both
exist.
If one of <filename>~/.config/nixpkgs/overlays.nix</filename> and<filename>~/.config/nixpkgs/overlays/</filename> exists, then we look for overlays at that path, as described below. It is an error if both exist.
</para>
</listitem>
</orderedlist>
@@ -92,15 +67,12 @@
<itemizedlist>
<listitem>
<para>
If the path is a file, then the file is imported as a Nix expression and
used as the list of overlays.
If the path is a file, then the file is imported as a Nix expression and used as the list of overlays.
</para>
</listitem>
<listitem>
<para>
If the path is a directory, then we take the content of the directory,
order it lexicographically, and attempt to interpret each as an overlay
by:
If the path is a directory, then we take the content of the directory, order it lexicographically, and attempt to interpret each as an overlay by:
<itemizedlist>
<listitem>
<para>
@@ -109,8 +81,7 @@
</listitem>
<listitem>
<para>
Importing a top-level <filename>default.nix</filename> file, if it is
a directory.
Importing a top-level <filename>default.nix</filename> file, if it is a directory.
</para>
</listitem>
</itemizedlist>
@@ -120,12 +91,7 @@
</para>
<para>
Because overlays that are set in NixOS configuration do not affect
non-NixOS operations such as <literal>nix-env</literal>, the
<filename>overlays.nix</filename> option provides a convenient way to use
the same overlays for a NixOS system configuration and user configuration:
the same file can be used as <filename>overlays.nix</filename> and imported
as the value of <literal>nixpkgs.overlays</literal>.
Because overlays that are set in NixOS configuration do not affect non-NixOS operations such as <literal>nix-env</literal>, the <filename>overlays.nix</filename> option provides a convenient way to use the same overlays for a NixOS system configuration and user configuration: the same file can be used as <filename>overlays.nix</filename> and imported as the value of <literal>nixpkgs.overlays</literal>.
</para>
<!-- TODO: Example of sharing overlays between NixOS configuration
@@ -139,9 +105,7 @@
<title>Defining overlays</title>
<para>
Overlays are Nix functions which accept two arguments, conventionally called
<varname>self</varname> and <varname>super</varname>, and return a set of
packages. For example, the following is a valid overlay.
Overlays are Nix functions which accept two arguments, conventionally called<varname>self</varname> and <varname>super</varname>, and return a set of packages. For example, the following is a valid overlay.
</para>
<programlisting>
@@ -158,38 +122,19 @@ self: super:
</programlisting>
<para>
The first argument (<varname>self</varname>) corresponds to the final
package set. You should use this set for the dependencies of all packages
specified in your overlay. For example, all the dependencies of
<varname>rr</varname> in the example above come from
<varname>self</varname>, as well as the overridden dependencies used in the
<varname>boost</varname> override.
The first argument (<varname>self</varname>) corresponds to the final package set. You should use this set for the dependencies of all packages specified in your overlay. For example, all the dependencies of <varname>rr</varname> in the example above come from <varname>self</varname>, as well as the overridden dependencies used in the <varname>boost</varname> override.
</para>
<para>
The second argument (<varname>super</varname>) corresponds to the result of
the evaluation of the previous stages of Nixpkgs. It does not contain any of
the packages added by the current overlay, nor any of the following
overlays. This set should be used either to refer to packages you wish to
override, or to access functions defined in Nixpkgs. For example, the
original recipe of <varname>boost</varname> in the above example, comes from
<varname>super</varname>, as well as the <varname>callPackage</varname>
function.
The second argument (<varname>super</varname>) corresponds to the result of the evaluation of the previous stages of Nixpkgs. It does not contain any of the packages added by the current overlay, nor any of the following overlays. This set should be used either to refer to packages you wish to override, or to access functions defined in Nixpkgs. For example, the original recipe of <varname>boost</varname> in the above example, comes from <varname>super</varname>, as well as the <varname>callPackage</varname> function.
</para>
<para>
The value returned by this function should be a set similar to
The value returned by this function should be a set similar to<filename>pkgs/top-level/all-packages.nix</filename>, containing overridden and/or new packages.
</para>
<para>
Overlays are similar to other methods for customizing Nixpkgs, in particular
the <literal>packageOverrides</literal> attribute described in
<literal>packageOverrides</literal> acts as an overlay with only the
<varname>super</varname> argument. It is therefore appropriate for basic
use, but overlays are more powerful and easier to distribute.
Overlays are similar to other methods for customizing Nixpkgs, in particular the <literal>packageOverrides</literal> attribute described in <xreflinkend="sec-modify-via-packageOverrides"/>. Indeed, <literal>packageOverrides</literal> acts as an overlay with only the <varname>super</varname> argument. It is therefore appropriate for basic use, but overlays are more powerful and easier to distribute.
Sometimes one wants to override parts of <literal>nixpkgs</literal>, e.g. derivation attributes, the results of derivations.
</para>
<para>
These functions are used to make changes to packages, returning only single packages. <linkxlink:href="#chap-overlays">Overlays</link>, on the other hand, can be used to combine the overridden packages across the entire package set of Nixpkgs.
</para>
<sectionxml:id="sec-pkg-override">
<title><pkg>.override</title>
<para>
The function <varname>override</varname> is usually available for all the derivations in the nixpkgs expression (<varname>pkgs</varname>).
</para>
<para>
It is used to override the arguments passed to a function.
<!-- TODO: move below programlisting to a new section about extending and overlays
and reference it
-->
<programlisting>
import pkgs.path { overlays = [ (self: super: {
foo = super.foo.override { barSupport = true ; };
})]};
</programlisting>
<programlisting>
mypkg = pkgs.callPackage ./mypkg.nix {
mydep = pkgs.mydep.override { ... };
}
</programlisting>
</para>
<para>
In the first example, <varname>pkgs.foo</varname> is the result of a function call with some default arguments, usually a derivation. Using <varname>pkgs.foo.override</varname> will call the same function with the given new arguments.
</para>
</section>
<sectionxml:id="sec-pkg-overrideAttrs">
<title><pkg>.overrideAttrs</title>
<para>
The function <varname>overrideAttrs</varname> allows overriding the attribute set passed to a <varname>stdenv.mkDerivation</varname> call, producing a new derivation based on the original one. This function is available on all derivations produced by the <varname>stdenv.mkDerivation</varname> function, which is most packages in the nixpkgs expression <varname>pkgs</varname>.
In the above example, the <varname>separateDebugInfo</varname> attribute is overridden to be true, thus building debug info for <varname>helloWithDebug</varname>, while all other attributes will be retained from the original <varname>hello</varname> package.
</para>
<para>
The argument <varname>oldAttrs</varname> is conventionally used to refer to the attr set originally passed to <varname>stdenv.mkDerivation</varname>.
</para>
<note>
<para>
Note that <varname>separateDebugInfo</varname> is processed only by the <varname>stdenv.mkDerivation</varname> function, not the generated, raw Nix derivation. Thus, using <varname>overrideDerivation</varname> will not work in this case, as it overrides only the attributes of the final derivation. It is for this reason that <varname>overrideAttrs</varname> should be preferred in (almost) all cases to <varname>overrideDerivation</varname>, i.e. to allow using <varname>stdenv.mkDerivation</varname> to process input arguments, as well as the fact that it is easier to use (you can use the same attribute names you see in your Nix code, instead of the ones generated (e.g. <varname>buildInputs</varname> vs <varname>nativeBuildInputs</varname>), and it involves less typing).
</para>
</note>
</section>
<sectionxml:id="sec-pkg-overrideDerivation">
<title><pkg>.overrideDerivation</title>
<warning>
<para>
You should prefer <varname>overrideAttrs</varname> in almost all cases, see its documentation for the reasons why. <varname>overrideDerivation</varname> is not deprecated and will continue to work, but is less nice to use and does not have as many abilities as <varname>overrideAttrs</varname>.
</para>
</warning>
<warning>
<para>
Do not use this function in Nixpkgs as it evaluates a Derivation before modifying it, which breaks package abstraction and removes error-checking of function arguments. In addition, this evaluation-per-function application incurs a performance penalty, which can become a problem if many overrides are used. It is only intended for ad-hoc customisation, such as in <filename>~/.config/nixpkgs/config.nix</filename>.
</para>
</warning>
<para>
The function <varname>overrideDerivation</varname> creates a new derivation based on an existing one by overriding the original's attributes with the attribute set produced by the specified function. This function is available on all derivations defined using the <varname>makeOverridable</varname> function. Most standard derivation-producing functions, such as <varname>stdenv.mkDerivation</varname>, are defined using this function, which means most packages in the nixpkgs expression, <varname>pkgs</varname>, have this function.
In the above example, the <varname>name</varname>, <varname>src</varname>, and <varname>patches</varname> of the derivation will be overridden, while all other attributes will be retained from the original derivation.
</para>
<para>
The argument <varname>oldAttrs</varname> is used to refer to the attribute set of the original derivation.
</para>
<note>
<para>
A package's attributes are evaluated *before* being modified by the <varname>overrideDerivation</varname> function. For example, the <varname>name</varname> attribute reference in <varname>url = "mirror://gnu/hello/${name}.tar.gz";</varname> is filled-in *before* the <varname>overrideDerivation</varname> function modifies the attribute set. This means that overriding the <varname>name</varname> attribute, in this example, *will not* change the value of the <varname>url</varname> attribute. Instead, we need to override both the <varname>name</varname> *and* <varname>url</varname> attributes.
</para>
</note>
</section>
<sectionxml:id="sec-lib-makeOverridable">
<title>lib.makeOverridable</title>
<para>
The function <varname>lib.makeOverridable</varname> is used to make the result of a function easily customizable. This utility only makes sense for functions that accept an argument set and return an attribute set.
</para>
<para>
Example usage:
<programlisting>
f = { a, b }: { result = a+b; };
c = lib.makeOverridable f { a = 1; b = 2; };
</programlisting>
</para>
<para>
The variable <varname>c</varname> is the value of the <varname>f</varname> function applied with some default arguments. Hence the value of <varname>c.result</varname> is <literal>3</literal>, in this example.
</para>
<para>
The variable <varname>c</varname> however also has some additional functions, like <linklinkend="sec-pkg-override">c.override</link> which can be used to override the default arguments. In this example the value of <varname>(c.override { a = 4; }).result</varname> is 6.
Please note that the <literal>citrix_receiver</literal> package has been deprecated since its development was <linkxlink:href="https://docs.citrix.com/en-us/citrix-workspace-app.html">discontinued by upstream</link> and has been replaced by <linkxlink:href="https://www.citrix.com/products/workspace-app/">the citrix workspace app</link>.
</para>
</note>
<linkxlink:href="https://www.citrix.com/products/receiver/">Citrix Receiver</link> and <linkxlink:href="https://www.citrix.com/products/workspace-app/">Citrix Workspace App</link> are a remote desktop viewers which provide access to <linkxlink:href="https://www.citrix.com/products/xenapp-xendesktop/">XenDesktop</link> installations.
</para>
<sectionxml:id="sec-citrix-base">
<title>Basic usage</title>
<para>
The tarball archive needs to be downloaded manually as the license agreements of the vendor for <linkxlink:href="https://www.citrix.com/downloads/citrix-receiver/">Citrix Receiver</link> or <linkxlink:href="https://www.citrix.de/downloads/workspace-app/linux/workspace-app-for-linux-latest.html">Citrix Workspace</link> need to be accepted first. Then run <command>nix-prefetch-url file://$PWD/linuxx64-$version.tar.gz</command>. With the archive available in the store the package can be built and installed with Nix.
</para>
<warning>
<title>Caution with <command>nix-shell</command> installs</title>
<para>
It's recommended to install <literal>Citrix Receiver</literal> and/or <literal>Citrix Workspace</literal> using <literal>nix-env -i</literal> or globally to ensure that the <literal>.desktop</literal> files are installed properly into <literal>$XDG_CONFIG_DIRS</literal>. Otherwise it won't be possible to open <literal>.ica</literal> files automatically from the browser to start a Citrix connection.
</para>
</warning>
</section>
<sectionxml:id="sec-citrix-custom-certs">
<title>Custom certificates</title>
<para>
The <literal>Citrix Workspace App</literal> in <literal>nixpkgs</literal> trust several certificates <linkxlink:href="https://curl.haxx.se/docs/caextract.html">from the Mozilla database</link> by default. However several companies using Citrix might require their own corporate certificate. On distros with imperative packaging these certs can be stored easily in <linkxlink:href="https://developer-docs.citrix.com/projects/receiver-for-linux-command-reference/en/13.7/"><literal>$ICAROOT</literal></link>, however this directory is a store path in <literal>nixpkgs</literal>. In order to work around this issue the package provides a simple mechanism to add custom certificates without rebuilding the entire package using <literal>symlinkJoin</literal>:
<linkxlink:href="http://dlib.net/">DLib</link> is a modern, C++-based toolkit which provides several machine learning algorithms.
</para>
<sectionxml:id="compiling-without-avx-support">
<title>Compiling without AVX support</title>
<para>
Especially older CPUs don't support <linkxlink:href="https://en.wikipedia.org/wiki/Advanced_Vector_Extensions">AVX</link> (<abbrev>Advanced Vector Extensions</abbrev>) instructions that are used by DLib to optimize their algorithms.
</para>
<para>
On the affected hardware errors like <literal>Illegal instruction</literal> will occur. In those cases AVX support needs to be disabled:
The Nix expressions related to the Eclipse platform and IDE are in <linkxlink:href="https://github.com/NixOS/nixpkgs/blob/master/pkgs/applications/editors/eclipse"><filename>pkgs/applications/editors/eclipse</filename></link>.
</para>
<para>
Nixpkgs provides a number of packages that will install Eclipse in its various forms. These range from the bare-bones Eclipse Platform to the more fully featured Eclipse SDK or Scala-IDE packages and multiple version are often available. It is possible to list available Eclipse packages by issuing the command:
<screen>
<prompt>$ </prompt>nix-env -f '<nixpkgs>' -qaP -A eclipses --description
</screen>
Once an Eclipse variant is installed it can be run using the <command>eclipse</command> command, as expected. From within Eclipse it is then possible to install plugins in the usual manner by either manually specifying an Eclipse update site or by installing the Marketplace Client plugin and using it to discover and install other plugins. This installation method provides an Eclipse installation that closely resemble a manually installed Eclipse.
</para>
<para>
If you prefer to install plugins in a more declarative manner then Nixpkgs also offer a number of Eclipse plugins that can be installed in an <emphasis>Eclipse environment</emphasis>. This type of environment is created using the function <varname>eclipseWithPlugins</varname> found inside the <varname>nixpkgs.eclipses</varname> attribute set. This function takes as argument <literal>{ eclipse, plugins ? [], jvmArgs ? [] }</literal> where <varname>eclipse</varname> is a one of the Eclipse packages described above, <varname>plugins</varname> is a list of plugin derivations, and <varname>jvmArgs</varname> is a list of arguments given to the JVM running the Eclipse. For example, say you wish to install the latest Eclipse Platform with the popular Eclipse Color Theme plugin and also allow Eclipse to use more RAM. You could then add
<screen>
packageOverrides = pkgs: {
myEclipse = with pkgs.eclipses; eclipseWithPlugins {
eclipse = eclipse-platform;
jvmArgs = [ "-Xmx2048m" ];
plugins = [ plugins.color-theme ];
};
}
</screen>
to your Nixpkgs configuration (<filename>~/.config/nixpkgs/config.nix</filename>) and install it by running <command>nix-env -f '<nixpkgs>' -iA myEclipse</command> and afterward run Eclipse as usual. It is possible to find out which plugins are available for installation using <varname>eclipseWithPlugins</varname> by running
<screen>
<prompt>$ </prompt>nix-env -f '<nixpkgs>' -qaP -A eclipses.plugins --description
</screen>
</para>
<para>
If there is a need to install plugins that are not available in Nixpkgs then it may be possible to define these plugins outside Nixpkgs using the <varname>buildEclipseUpdateSite</varname> and <varname>buildEclipsePlugin</varname> functions found in the <varname>nixpkgs.eclipses.plugins</varname> attribute set. Use the <varname>buildEclipseUpdateSite</varname> function to install a plugin distributed as an Eclipse update site. This function takes <literal>{ name, src }</literal> as argument where <literal>src</literal> indicates the Eclipse update site archive. All Eclipse features and plugins within the downloaded update site will be installed. When an update site archive is not available then the <varname>buildEclipsePlugin</varname> function can be used to install a plugin that consists of a pair of feature and plugin JARs. This function takes an argument <literal>{ name, srcFeature, srcPlugin }</literal> where <literal>srcFeature</literal> and <literal>srcPlugin</literal> are the feature and plugin JARs, respectively.
</para>
<para>
Expanding the previous example with two plugins using the above functions we have
<screen>
packageOverrides = pkgs: {
myEclipse = with pkgs.eclipses; eclipseWithPlugins {
The Emacs package comes with some extra helpers to make it easier to configure. <varname>emacsWithPackages</varname> allows you to manage packages from ELPA. This means that you will not have to install that packages from within Emacs. For instance, if you wanted to use <literal>company</literal>, <literal>counsel</literal>, <literal>flycheck</literal>, <literal>ivy</literal>, <literal>magit</literal>, <literal>projectile</literal>, and <literal>use-package</literal> you could use this as a <filename>~/.config/nixpkgs/config.nix</filename> override:
You can install it like any other packages via <command>nix-env -iA myEmacs</command>. However, this will only install those packages. It will not <literal>configure</literal> them for us. To do this, we need to provide a configuration file. Luckily, it is possible to do this from within Nix! By modifying the above example, we can make Emacs load a custom config file. The key is to create a package that provide a <filename>default.el</filename> file in <filename>/share/emacs/site-start/</filename>. Emacs knows to load this file automatically when it starts.
This provides a fairly full Emacs start file. It will load in addition to the user's presonal config. You can always disable it by passing <command>-q</command> to the Emacs command.
</para>
<para>
Sometimes <varname>emacsWithPackages</varname> is not enough, as this package set has some priorities imposed on packages (with the lowest priority assigned to Melpa Unstable, and the highest for packages manually defined in <filename>pkgs/top-level/emacs-packages.nix</filename>). But you can't control this priorities when some package is installed as a dependency. You can override it on per-package-basis, providing all the required dependencies manually - but it's tedious and there is always a possibility that an unwanted dependency will sneak in through some other package. To completely override such a package you can use <varname>overrideScope'</varname>.
</para>
<screen>
overrides = self: super: rec {
haskell-mode = self.melpaPackages.haskell-mode;
...
};
((emacsPackagesGen emacs).overrideScope' overrides).emacsWithPackages (p: with p; [
# here both these package will use haskell-mode of our own choice
IBus needs to be configured accordingly to activate <literal>typing-booster</literal>. The configuration depends on the desktop manager in use. For detailed instructions, please refer to the <linkxlink:href="https://mike-fabian.github.io/ibus-typing-booster/documentation.html">upstream docs</link>.
</para>
<para>
On NixOS you need to explicitly enable <literal>ibus</literal> with given engines before customizing your desktop to use <literal>typing-booster</literal>. This can be achieved using the <literal>ibus</literal> module:
<programlisting>{ pkgs, ... }: {
i18n.inputMethod = {
enabled = "ibus";
ibus.engines = with pkgs.ibus-engines; [ typing-booster ];
The IBus engine is based on <literal>hunspell</literal> to support completion in many languages. By default the dictionaries <literal>de-de</literal>, <literal>en-us</literal>, <literal>fr-moderne</literal><literal>es-es</literal>, <literal>it-it</literal>, <literal>sv-se</literal> and <literal>sv-fi</literal> are in use. To add another dictionary, the package can be overridden like this:
The <literal>ibus-engines.typing-booster</literal> package contains a program named <literal>emoji-picker</literal>. To display all emojis correctly, a special font such as <literal>noto-fonts-emoji</literal> is needed:
</para>
<para>
On NixOS it can be installed using the following expression:
This chapter contains information about how to use and maintain the Nix expressions for a number of specific packages, such as the Linux kernel or X.org.
The function that builds the kernel has an argument <varname>kernelPatches</varname> which should be a list of <literal>{name, patch, extraConfig}</literal> attribute sets, where <varname>name</varname> is the name of the patch (which is included in the kernel’s <varname>meta.description</varname> attribute), <varname>patch</varname> is the patch itself (possibly compressed), and <varname>extraConfig</varname> (optional) is a string specifying extra options to be concatenated to the kernel configuration file (<filename>.config</filename>).
</para>
<para>
The kernel derivation exports an attribute <varname>features</varname> specifying whether optional functionality is or isn’t enabled. This is used in NixOS to implement kernel-specific behaviour. For instance, if the kernel has the <varname>iwlwifi</varname> feature (i.e. has built-in support for Intel wireless chipsets), then NixOS doesn’t have to build the external <varname>iwlwifi</varname> package:
How to add a new (major) version of the Linux kernel to Nixpkgs:
<orderedlist>
<listitem>
<para>
Copy the old Nix expression (e.g. <filename>linux-2.6.21.nix</filename>) to the new one (e.g. <filename>linux-2.6.22.nix</filename>) and update it.
</para>
</listitem>
<listitem>
<para>
Add the new kernel to <filename>all-packages.nix</filename> (e.g., create an attribute <varname>kernel_2_6_22</varname>).
</para>
</listitem>
<listitem>
<para>
Now we’re going to update the kernel configuration. First unpack the kernel. Then for each supported platform (<literal>i686</literal>, <literal>x86_64</literal>, <literal>uml</literal>) do the following:
<orderedlist>
<listitem>
<para>
Make an copy from the old config (e.g. <filename>config-2.6.21-i686-smp</filename>) to the new one (e.g. <filename>config-2.6.22-i686-smp</filename>).
</para>
</listitem>
<listitem>
<para>
Copy the config file for this platform (e.g. <filename>config-2.6.22-i686-smp</filename>) to <filename>.config</filename> in the kernel source tree.
</para>
</listitem>
<listitem>
<para>
Run <literal>make oldconfig ARCH=<replaceable>{i386,x86_64,um}</replaceable></literal> and answer all questions. (For the uml configuration, also add <literal>SHELL=bash</literal>.) Make sure to keep the configuration consistent between platforms (i.e. don’t enable some feature on <literal>i686</literal> and disable it on <literal>x86_64</literal>).
</para>
</listitem>
<listitem>
<para>
If needed you can also run <literal>make menuconfig</literal>:
Copy <filename>.config</filename> over the new config file (e.g. <filename>config-2.6.22-i686-smp</filename>).
</para>
</listitem>
</orderedlist>
</para>
</listitem>
<listitem>
<para>
Test building the kernel: <literal>nix-build -A kernel_2_6_22</literal>. If it compiles, ship it! For extra credit, try booting NixOS with it.
</para>
</listitem>
<listitem>
<para>
It may be that the new kernel requires updating the external kernel modules and kernel-dependent packages listed in the <varname>linuxPackagesFor</varname> function in <filename>all-packages.nix</filename> (such as the NVIDIA drivers, AUFS, etc.). If the updated packages aren’t backwards compatible with older kernels, you may need to keep the older versions around.
To allow simultaneous use of packages linked against different versions of <literal>glibc</literal> with different locale archive formats Nixpkgs patches <literal>glibc</literal> to rely on <literal>LOCALE_ARCHIVE</literal> environment variable.
</para>
<para>
On non-NixOS distributions this variable is obviously not set. This can cause regressions in language support or even crashes in some Nixpkgs-provided programs. The simplest way to mitigate this problem is exporting the <literal>LOCALE_ARCHIVE</literal> variable pointing to <literal>${glibcLocales}/lib/locale/locale-archive</literal>. The drawback (and the reason this is not the default) is the relatively large (a hundred MiB) size of the full set of locales. It is possible to build a custom set of locales by overriding parameters <literal>allLocales</literal> and <literal>locales</literal> of the package.
<linkxlink:href="https://nginx.org/">Nginx</link> is a reverse proxy and lightweight webserver.
</para>
<sectionxml:id="sec-nginx-etag">
<title>ETags on static files served from the Nix store</title>
<para>
HTTP has a couple different mechanisms for caching to prevent clients from having to download the same content repeatedly if a resource has not changed since the last time it was requested. When nginx is used as a server for static files, it implements the caching mechanism based on the <linkxlink:href="https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Last-Modified"><literal>Last-Modified</literal></link> response header automatically; unfortunately, it works by using filesystem timestamps to determine the value of the <literal>Last-Modified</literal> header. This doesn't give the desired behavior when the file is in the Nix store, because all file timestamps are set to 0 (for reasons related to build reproducibility).
</para>
<para>
Fortunately, HTTP supports an alternative (and more effective) caching mechanism: the <linkxlink:href="https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/ETag"><literal>ETag</literal></link> response header. The value of the <literal>ETag</literal> header specifies some identifier for the particular content that the server is sending (e.g. a hash). When a client makes a second request for the same resource, it sends that value back in an <literal>If-None-Match</literal> header. If the ETag value is unchanged, then the server does not need to resend the content.
</para>
<para>
As of NixOS 19.09, the nginx package in Nixpkgs is patched such that when nginx serves a file out of <filename>/nix/store</filename>, the hash in the store path is used as the <literal>ETag</literal> header in the HTTP response, thus providing proper caching functionality. This happens automatically; you do not need to do modify any configuration to get this behavior.
Packages that use OpenGL have NixOS desktop as their primary target. The current solution for loading the GPU-specific drivers is based on <literal>libglvnd</literal> and looks for the driver implementation in <literal>LD_LIBRARY_PATH</literal>. If you are using a non-NixOS GNU/Linux/X11 desktop with free software video drivers, consider launching OpenGL-dependent programs from Nixpkgs with Nixpkgs versions of <literal>libglvnd</literal> and <literal>mesa_drivers</literal> in <literal>LD_LIBRARY_PATH</literal>. For proprietary video drivers you might have luck with also adding the corresponding video driver package.
Some packages provide the shell integration to be more useful. But unlike other systems, nix doesn't have a standard share directory location. This is why a bunch <command>PACKAGE-share</command> scripts are shipped that print the location of the corresponding shared folder. Current list of such packages is as following:
Steam is distributed as a <filename>.deb</filename> file, for now only as an i686 package (the amd64 package only has documentation). When unpacked, it has a script called <filename>steam</filename> that in Ubuntu (their target distro) would go to <filename>/usr/bin </filename>. When run for the first time, this script copies some files to the user's home, which include another script that is the ultimate responsible for launching the steam binary, which is also in $HOME.
</para>
<para>
Nix problems and constraints:
<itemizedlist>
<listitem>
<para>
We don't have <filename>/bin/bash</filename> and many scripts point there. Similarly for <filename>/usr/bin/python</filename> .
</para>
</listitem>
<listitem>
<para>
We don't have the dynamic loader in <filename>/lib </filename>.
</para>
</listitem>
<listitem>
<para>
The <filename>steam.sh</filename> script in $HOME can not be patched, as it is checked and rewritten by steam.
</para>
</listitem>
<listitem>
<para>
The steam binary cannot be patched, it's also checked.
</para>
</listitem>
</itemizedlist>
</para>
<para>
The current approach to deploy Steam in NixOS is composing a FHS-compatible chroot environment, as documented <linkxlink:href="http://sandervanderburg.blogspot.nl/2013/09/composing-fhs-compatible-chroot.html">here</link>. This allows us to have binaries in the expected paths without disrupting the system, and to avoid patching them to work in a non FHS environment.
if you are using PulseAudio - this will enable 32bit ALSA apps integration. To use the Steam controller or other Steam supported controllers such as the DualShock 4 or Nintendo Switch Pro, you need to add
All users of Nixpkgs are free software users, and many users (and developers) of Nixpkgs want to limit and tightly control their exposure to unfree software. At the same time, many users need (or want) to run some specific pieces of proprietary software. Nixpkgs includes some expressions for unfree software packages. By default unfree software cannot be installed and doesn’t show up in searches. To allow installing unfree software in a single Nix invocation one can export <literal>NIXPKGS_ALLOW_UNFREE=1</literal>. For a persistent solution, users can set <literal>allowUnfree</literal> in the Nixpkgs configuration.
</para>
<para>
Fine-grained control is possible by defining <literal>allowUnfreePredicate</literal> function in config; it takes the <literal>mkDerivation</literal> parameter attrset and returns <literal>true</literal> for unfree packages that should be allowed.
Weechat can be configured to include your choice of plugins, reducing its closure size from the default configuration which includes all available plugins. To make use of this functionality, install an expression that overrides its configuration such as
If the <literal>configure</literal> function returns an attrset without the <literal>plugins</literal> attribute, <literal>availablePlugins</literal> will be used automatically.
</para>
<para>
The plugins currently available are <literal>python</literal>, <literal>perl</literal>, <literal>ruby</literal>, <literal>guile</literal>, <literal>tcl</literal> and <literal>lua</literal>.
</para>
<para>
The python and perl plugins allows the addition of extra libraries. For instance, the <literal>inotify.py</literal> script in weechat-scripts requires D-Bus or libnotify, and the <literal>fish.py</literal> script requires pycrypto. To use these scripts, use the plugin's <literal>withPackages</literal> attribute:
python = availablePlugins.python.withPackages (ps: with ps; [ pycrypto python-dbus ]);
});
}; }
</programlisting>
</para>
<para>
WeeChat allows to set defaults on startup using the <literal>--run-command</literal>. The <literal>configure</literal> method can be used to pass commands to the program:
<programlisting>weechat.override {
configure = { availablePlugins, ... }: {
init = ''
/set foo bar
/server add freenode chat.freenode.org
'';
};
}</programlisting>
Further values can be added to the list of commands when running <literal>weechat --run-command "your-commands"</literal>.
</para>
<para>
Additionally it's possible to specify scripts to be loaded when starting <literal>weechat</literal>. These will be loaded before the commands from <literal>init</literal>:
<programlisting>weechat.override {
configure = { availablePlugins, ... }: {
scripts = with pkgs.weechatScripts; [
weechat-xmpp weechat-matrix-bridge wee-slack
];
init = ''
/set plugins.var.python.jabber.key "val"
'':
};
}</programlisting>
</para>
<para>
In <literal>nixpkgs</literal> there's a subpackage which contains derivations for WeeChat scripts. Such derivations expect a <literal>passthru.scripts</literal> attribute which contains a list of all scripts inside the store path. Furthermore all scripts have to live in <literal>$out/share</literal>. An exemplary derivation looks like this:
The Nix expressions for the X.org packages reside in <filename>pkgs/servers/x11/xorg/default.nix</filename>. This file is automatically generated from lists of tarballs in an X.org release. As such it should not be modified directly; rather, you should modify the lists, the generator script or the file <filename>pkgs/servers/x11/xorg/overrides.nix</filename>, in which you can override or add to the derivations produced by the generator.
For each of the tarballs in the <filename>.list</filename> files, the script downloads it, unpacks it, and searches its <filename>configure.ac</filename> and <filename>*.pc.in</filename> files for dependencies. This information is used to generate <filename>default.nix</filename>. The generator caches downloaded tarballs between runs. Pay close attention to the <literal>NOT FOUND: <replaceable>name</replaceable></literal> messages at the end of the run, since they may indicate missing dependencies. (Some might be optional dependencies, however.)
</para>
<para>
A file like <filename>tarballs-7.5.list</filename> contains all tarballs in a X.org release. It can be generated like this:
<filename>extra.list</filename> contains libraries that aren’t part of X.org proper, but are closely related to it, such as <literal>libxcb</literal>. <filename>old.list</filename> contains some packages that were removed from X.org, but are still needed by some people or by other packages (such as <varname>imake</varname>).
</para>
<para>
If the expression for a package requires derivation attributes that the generator cannot figure out automatically (say, <varname>patches</varname> or a <varname>postInstall</varname> hook), you should modify <filename>pkgs/servers/x11/xorg/overrides.nix</filename>.
The Darwin <literal>stdenv</literal> uses clang instead of gcc. When
referring to the compiler <varname>$CC</varname> or <command>cc</command>
will work in both cases. Some builds hardcode gcc/g++ in their build
scripts, that can usually be fixed with using something like
<literal>makeFlags = [ "CC=cc" ];</literal> or by patching the build
scripts.
The Darwin <literal>stdenv</literal> uses clang instead of gcc. When referring to the compiler <varname>$CC</varname> or <command>cc</command> will work in both cases. Some builds hardcode gcc/g++ in their build scripts, that can usually be fixed with using something like <literal>makeFlags = [ "CC=cc" ];</literal> or by patching the build scripts.
</para>
<programlisting>
stdenv.mkDerivation {
@@ -31,12 +26,7 @@ stdenv.mkDerivation {
</listitem>
<listitem>
<para>
On Darwin, libraries are linked using absolute paths, libraries are
resolved by their <literal>install_name</literal> at link time. Sometimes
packages won't set this correctly causing the library lookups to fail at
runtime. This can be fixed by adding extra linker flags or by running
<command>install_name_tool -id</command> during the
<function>fixupPhase</function>.
On Darwin, libraries are linked using absolute paths, libraries are resolved by their <literal>install_name</literal> at link time. Sometimes packages won't set this correctly causing the library lookups to fail at runtime. This can be fixed by adding extra linker flags or by running <command>install_name_tool -id</command> during the <function>fixupPhase</function>.
</para>
<programlisting>
stdenv.mkDerivation {
@@ -48,16 +38,10 @@ stdenv.mkDerivation {
</listitem>
<listitem>
<para>
Even if the libraries are linked using absolute paths and resolved via
their <literal>install_name</literal> correctly, tests can sometimes fail
to run binaries. This happens because the <varname>checkPhase</varname>
runs before the libraries are installed.
Even if the libraries are linked using absolute paths and resolved via their <literal>install_name</literal> correctly, tests can sometimes fail to run binaries. This happens because the <varname>checkPhase</varname> runs before the libraries are installed.
</para>
<para>
This can usually be solved by running the tests after the
<varname>installPhase</varname> or alternatively by using
<varname>DYLD_LIBRARY_PATH</varname>. More information about this variable
can be found in the <citerefentry>
This can usually be solved by running the tests after the<varname>installPhase</varname> or alternatively by using <varname>DYLD_LIBRARY_PATH</varname>. More information about this variable can be found in the <citerefentry>
<refentrytitle>dyld</refentrytitle>
<manvolnum>1</manvolnum></citerefentry> manpage.
</para>
@@ -78,11 +62,7 @@ stdenv.mkDerivation {
</listitem>
<listitem>
<para>
Some packages assume xcode is available and use <command>xcrun</command>
to resolve build tools like <command>clang</command>, etc. This causes
errors like <code>xcode-select: error: no developer tools were found at
'/Applications/Xcode.app'</code> while the build doesn't actually depend
on xcode.
Some packages assume xcode is available and use <command>xcrun</command> to resolve build tools like <command>clang</command>, etc. This causes errors like <code>xcode-select: error: no developer tools were found at '/Applications/Xcode.app'</code> while the build doesn't actually depend on xcode.
</para>
<programlisting>
stdenv.mkDerivation {
@@ -95,9 +75,7 @@ stdenv.mkDerivation {
}
</programlisting>
<para>
The package <literal>xcbuild</literal> can be used to build projects that
really depend on Xcode. However, this replacement is not 100% compatible
with Xcode and can occasionally cause issues.
The package <literal>xcbuild</literal> can be used to build projects that really depend on Xcode. However, this replacement is not 100% compatible with Xcode and can occasionally cause issues.
See <xreflinkend="sec-organisation"/> for some hints on the tree
organisation. Create a directory for your package, e.g.
Find a good place in the Nixpkgs tree to add the Nix expression for your package. For instance, a library package typically goes into <filename>pkgs/development/libraries/<replaceable>pkgname</replaceable></filename>, while a web browser goes into <filename>pkgs/applications/networking/browsers/<replaceable>pkgname</replaceable></filename>. See <xreflinkend="sec-organisation"/> for some hints on the tree organisation. Create a directory for your package, e.g.
In the package directory, create a Nix expression — a piece of code that
describes how to build the package. In this case, it should be a
<emphasis>function</emphasis> that is called with the package dependencies
as arguments, and returns a build of the package in the Nix store. The
expression should usually be called <filename>default.nix</filename>.
In the package directory, create a Nix expression — a piece of code that describes how to build the package. In this case, it should be a <emphasis>function</emphasis> that is called with the package dependencies as arguments, and returns a build of the package in the Nix store. The expression should usually be called <filename>default.nix</filename>.
Trivial package, which specifies some <varname>meta</varname>
attributes which is good practice.
GNU Hello:<link
xlink:href="https://github.com/NixOS/nixpkgs/blob/master/pkgs/applications/misc/hello/default.nix"><filename>pkgs/applications/misc/hello/default.nix</filename></link>. Trivial package, which specifies some <varname>meta</varname> attributes which is good practice.
Also a simple package. The generic builder in <varname>stdenv</varname>
does everything for you. It has no dependencies beyond
<varname>stdenv</varname>.
GNU cpio:<link
xlink:href="https://github.com/NixOS/nixpkgs/blob/master/pkgs/tools/archivers/cpio/default.nix"><filename>pkgs/tools/archivers/cpio/default.nix</filename></link>. Also a simple package. The generic builder in <varname>stdenv</varname> does everything for you. It has no dependencies beyond <varname>stdenv</varname>.
Also done by the generic builder, but has a dependency on
<varname>m4</varname>.
GNU Multiple Precision arithmetic library (GMP):<link
xlink:href="https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/libraries/gmp/5.1.x.nix"><filename>pkgs/development/libraries/gmp/5.1.x.nix</filename></link>. Also done by the generic builder, but has a dependency on <varname>m4</varname>.
Has an optional dependency on <varname>gtkspell</varname>, which is
only built if <varname>spellCheck</varname> is <literal>true</literal>.
Pan, a GTK-based newsreader:<link
xlink:href="https://github.com/NixOS/nixpkgs/blob/master/pkgs/applications/networking/newsreaders/pan/default.nix"><filename>pkgs/applications/networking/newsreaders/pan/default.nix</filename></link>. Has an optional dependency on <varname>gtkspell</varname>, which is only built if <varname>spellCheck</varname> is <literal>true</literal>.
A bunch of optional features, variable substitutions in the configure
flags, a post-install hook, and miscellaneous hackery.
Apache HTTPD:<link
xlink:href="https://github.com/NixOS/nixpkgs/blob/master/pkgs/servers/http/apache-httpd/2.4.nix"><filename>pkgs/servers/http/apache-httpd/2.4.nix</filename></link>. A bunch of optional features, variable substitutions in the configure flags, a post-install hook, and miscellaneous hackery.
xlink:href="https://github.com/NixOS/nixpkgs/blob/master/pkgs/applications/networking/mailreaders/thunderbird/default.nix"><filename>pkgs/applications/networking/mailreaders/thunderbird/default.nix</filename></link>. Lots of dependencies.
Nixpkgs doesn’t have a decent <varname>stdenv</varname> for Java yet
so this is pretty ad-hoc.
JDiskReport, a Java utility:<link
xlink:href="https://github.com/NixOS/nixpkgs/blob/master/pkgs/tools/misc/jdiskreport/default.nix"><filename>pkgs/tools/misc/jdiskreport/default.nix</filename></link> (and the <link
xlink:href="https://github.com/NixOS/nixpkgs/blob/master/pkgs/tools/misc/jdiskreport/builder.sh">builder</link>). Nixpkgs doesn’t have a decent <varname>stdenv</varname> for Java yet so this is pretty ad-hoc.
(search for the <varname>XMLSimple</varname> attribute). Most Perl
modules are so simple to build that they are defined directly in
<filename>perl-packages.nix</filename>; no need to make a separate file
for them.
XML::Simple, a Perl module:<link
xlink:href="https://github.com/NixOS/nixpkgs/blob/master/pkgs/top-level/perl-packages.nix"><filename>pkgs/top-level/perl-packages.nix</filename></link> (search for the <varname>XMLSimple</varname> attribute). Most Perl modules are so simple to build that they are defined directly in <filename>perl-packages.nix</filename>; no need to make a separate file for them.
uses <command>patchelf</command> to set the RUNPATH and ELF interpreter
of the executables so that the right libraries are found at runtime.
Adobe Reader:<link
xlink:href="https://github.com/NixOS/nixpkgs/blob/master/pkgs/applications/misc/adobe-reader/default.nix"><filename>pkgs/applications/misc/adobe-reader/default.nix</filename></link>. Shows how binary-only packages can be supported. In particular the <link
xlink:href="https://github.com/NixOS/nixpkgs/blob/master/pkgs/applications/misc/adobe-reader/builder.sh">builder</link> uses <command>patchelf</command> to set the RUNPATH and ELF interpreter of the executables so that the right libraries are found at runtime.
</para>
</listitem>
</itemizedlist>
@@ -138,67 +93,45 @@
<itemizedlist>
<listitem>
<para>
All <varnamelinkend="chap-meta">meta</varname> attributes are
optional, but it’s still a good idea to provide at least the
<varname>description</varname>, <varname>homepage</varname> and
<varname
All <varnamelinkend="chap-meta">meta</varname> attributes are optional, but it’s still a good idea to provide at least the <varname>description</varname>, <varname>homepage</varname> and <varname
linkend="sec-meta-license">license</varname>.
</para>
</listitem>
<listitem>
<para>
You can use <command>nix-prefetch-url</command>
<replaceable>url</replaceable> to get the SHA-256 hash of source
distributions. There are similar commands as
<command>nix-prefetch-git</command> and
<command>nix-prefetch-hg</command> available in
<literal>nix-prefetch-scripts</literal> package.
You can use <command>nix-prefetch-url</command><replaceable>url</replaceable> to get the SHA-256 hash of source distributions. There are similar commands as <command>nix-prefetch-git</command> and <command>nix-prefetch-hg</command> available in <literal>nix-prefetch-scripts</literal> package.
</para>
</listitem>
<listitem>
<para>
A list of schemes for <literal>mirror://</literal> URLs can be found in
<link
A list of schemes for <literal>mirror://</literal> URLs can be found in<link
The exact syntax and semantics of the Nix expression language, including the built-in function, are described in the Nix manual in the <link
xlink:href="http://hydra.nixos.org/job/nix/trunk/tarball/latest/download-by-type/doc/manual/#chap-writing-nix-expressions">chapter on writing Nix expressions</link>.
</para>
</listitem>
<listitem>
<para>
Add a call to the function defined in the previous step to
Add a call to the function defined in the previous step to<link
xlink:href="https://github.com/NixOS/nixpkgs/blob/master/pkgs/top-level/all-packages.nix"><filename>pkgs/top-level/all-packages.nix</filename></link> with some descriptive name for the variable, e.g. <varname>libfoo</varname>.
The attributes in that file are sorted by category (like “Development /
Libraries”) that more-or-less correspond to the directory structure of
Nixpkgs, and then by attribute name.
The attributes in that file are sorted by category (like “Development / Libraries”) that more-or-less correspond to the directory structure of Nixpkgs, and then by attribute name.
</para>
</listitem>
<listitem>
<para>
To test whether the package builds, run the following command from the
root of the nixpkgs source tree:
To test whether the package builds, run the following command from the root of the nixpkgs source tree:
<screen>
<prompt>$ </prompt>nix-build -A libfoo</screen>
where <varname>libfoo</varname> should be the variable name defined in the
previous step. You may want to add the flag <option>-K</option> to keep
the temporary build directory in case something fails. If the build
succeeds, a symlink <filename>./result</filename> to the package in the
Nix store is created.
where <varname>libfoo</varname> should be the variable name defined in the previous step. You may want to add the flag <option>-K</option> to keep the temporary build directory in case something fails. If the build succeeds, a symlink <filename>./result</filename> to the package in the Nix store is created.
</para>
</listitem>
<listitem>
@@ -211,11 +144,8 @@
<listitem>
<para>
Optionally commit the new package and open a pull request <link
xlink:href="https://github.com/NixOS/nixpkgs/pulls">to nixpkgs</link>, or
the Patches category</link> on Discourse for sending a patch without a
GitHub account.
xlink:href="https://github.com/NixOS/nixpkgs/pulls">to nixpkgs</link>, or use <link
xlink:href="https://discourse.nixos.org/t/about-the-patches-category/477"> the Patches category</link> on Discourse for sending a patch without a GitHub account.
In preparation for the switch from Subversion to Git, this release is mainly
the prevent the Nixpkgs version number from going backwards. (This would
happen because prerelease version numbers produced for the Git repository
are lower than those for the Subversion repository.)
In preparation for the switch from Subversion to Git, this release is mainly the prevent the Nixpkgs version number from going backwards. (This would happen because prerelease version numbers produced for the Git repository are lower than those for the Subversion repository.)
</para>
<para>
Since the last release, there have been thousands of changes and new
packages by numerous contributors. For details, see the commit logs.
Since the last release, there have been thousands of changes and new packages by numerous contributors. For details, see the commit logs.
</para>
</section>
<sectionxml:id="release-notes-0.13">
@@ -55,14 +51,11 @@
<title>Release 0.12 (April 24, 2009)</title>
<para>
There are way too many additions to Nixpkgs since the last release to list
here: for example, the number of packages on Linux has increased from 1002
to 2159. However, some specific improvements are worth listing:
There are way too many additions to Nixpkgs since the last release to list here: for example, the number of packages on Linux has increased from 1002 to 2159. However, some specific improvements are worth listing:
<itemizedlist>
<listitem>
<para>
Nixpkgs now has a manual. In particular, it describes the standard build
environment in detail.
Nixpkgs now has a manual. In particular, it describes the standard build environment in detail.
</para>
</listitem>
<listitem>
@@ -122,9 +115,7 @@
</listitem>
<listitem>
<para>
Support for building derivations in a virtual machine, including RPM and
Debian builds in automatically generated VM images. See
<filename>pkgs/build-support/vm/default.nix</filename> for details.
Support for building derivations in a virtual machine, including RPM and Debian builds in automatically generated VM images. See <filename>pkgs/build-support/vm/default.nix</filename> for details.
</para>
</listitem>
<listitem>
@@ -136,13 +127,7 @@
</para>
<para>
The following people contributed to this release: Andres Löh, Arie
Marc Weber, Mart Kolthof, Martin Bravenboer, Michael Raskin, Nicolas
Pierron, Peter Simons, Pjotr Prins, Rob Vermaas, Sander van der Burg, Tobias
Hammerschmidt, Valentin David, Wouter den Breejen and Yury G. Kudryashov. In
addition, several people contributed patches on the
<literal>nix-dev</literal> mailing list.
The following people contributed to this release: Andres Löh, Arie Middelkoop, Armijn Hemel, Eelco Dolstra, Lluís Batlle, Ludovic Courtès, Marc Weber, Mart Kolthof, Martin Bravenboer, Michael Raskin, Nicolas Pierron, Peter Simons, Pjotr Prins, Rob Vermaas, Sander van der Burg, Tobias Hammerschmidt, Valentin David, Wouter den Breejen and Yury G. Kudryashov. In addition, several people contributed patches on the <literal>nix-dev</literal> mailing list.
</para>
</section>
<sectionxml:id="release-notes-0.11">
@@ -153,25 +138,12 @@
<itemizedlist>
<listitem>
<para>
The standard build environment (<literal>stdenv</literal>) is now pure on
the <literal>x86_64-linux</literal> and <literal>powerpc-linux</literal>
platforms, just as on <literal>i686-linux</literal>. (Purity means that
building and using the standard environment has no dependencies outside
of the Nix store. For instance, it doesn’t require an external C
compiler such as <filename>/usr/bin/gcc</filename>.) Also, the statically
linked binaries used in the bootstrap process are now automatically
reproducible, making it easy to update the bootstrap tools and to add
support for other Linux platforms. See
<filename>pkgs/stdenv/linux/make-bootstrap-tools.nix</filename> for
details.
The standard build environment (<literal>stdenv</literal>) is now pure on the <literal>x86_64-linux</literal> and <literal>powerpc-linux</literal> platforms, just as on <literal>i686-linux</literal>. (Purity means that building and using the standard environment has no dependencies outside of the Nix store. For instance, it doesn’t require an external C compiler such as <filename>/usr/bin/gcc</filename>.) Also, the statically linked binaries used in the bootstrap process are now automatically reproducible, making it easy to update the bootstrap tools and to add support for other Linux platforms. See <filename>pkgs/stdenv/linux/make-bootstrap-tools.nix</filename> for details.
</para>
</listitem>
<listitem>
<para>
Hook variables in the generic builder are now executed using the
<function>eval</function> shell command. This has a major advantage: you
can write hooks directly in Nix expressions. For instance, rather than
writing a builder like this:
Hook variables in the generic builder are now executed using the<function>eval</function> shell command. This has a major advantage: you can write hooks directly in Nix expressions. For instance, rather than writing a builder like this:
<programlisting>
source $stdenv/setup
@@ -182,91 +154,57 @@ postInstall() {
}
genericBuild</programlisting>
(the <literal>gzip</literal> builder), you can just add this attribute to
the derivation:
(the <literal>gzip</literal> builder), you can just add this attribute to the derivation:
and so a separate build script becomes unnecessary. This should allow us
to get rid of most builders in Nixpkgs.
and so a separate build script becomes unnecessary. This should allow us to get rid of most builders in Nixpkgs.
</para>
</listitem>
<listitem>
<para>
It is now possible to have the generic builder pass arguments to
<command>configure</command> and <command>make</command> that contain
whitespace. Previously, for example, you could say in a builder,
It is now possible to have the generic builder pass arguments to<command>configure</command> and <command>make</command> that contain whitespace. Previously, for example, you could say in a builder,
<programlisting>
configureFlags="CFLAGS=-O0"</programlisting>
but not
<programlisting>
configureFlags="CFLAGS=-O0 -g"</programlisting>
since the <literal>-g</literal> would be interpreted as a separate
argument to <command>configure</command>. Now you can say
since the <literal>-g</literal> would be interpreted as a separate argument to <command>configure</command>. Now you can say
which does the right thing. Idem for <literal>makeFlags</literal>,
<literal>installFlags</literal>, <literal>checkFlags</literal> and
<literal>distFlags</literal>.
which does the right thing. Idem for <literal>makeFlags</literal>,<literal>installFlags</literal>, <literal>checkFlags</literal> and <literal>distFlags</literal>.
</para>
<para>
Unfortunately you can't pass arrays to Bash through the environment, so
you can't put the array above in a Nix expression, e.g.,
Unfortunately you can't pass arrays to Bash through the environment, so you can't put the array above in a Nix expression, e.g.,
The function <function>fetchurl</function> now has support for two
different kinds of mirroring of files. First, it has support for
<emphasis>content-addressable mirrors</emphasis>. For example, given the
<function>fetchurl</function> call
The function <function>fetchurl</function> now has support for two different kinds of mirroring of files. First, it has support for <emphasis>content-addressable mirrors</emphasis>. For example, given the <function>fetchurl</function> call
There is currently only one content-addressable mirror
(<link
xlink:href="http://tarballs.nixos.org"/>), but more can be
specified in the <varname>hashedMirrors</varname> attribute in
<filename>pkgs/build-support/fetchurl/mirrors.nix</filename>, or by
setting the <envar>NIX_HASHED_MIRRORS</envar> environment variable to a
whitespace-separated list of URLs.
<function>fetchurl</function> will first try to download this file from<link
xlink:href="http://tarballs.nixos.org/sha1/eb72f55e4a8bf08e8c6ef227c0ade3d068ba1082"/>. If that file doesn’t exist, it will try the original URL. In general, the “content-addressed” location is <replaceable>mirror</replaceable><literal>/</literal><replaceable>hash-type</replaceable><literal>/</literal><replaceable>hash</replaceable>. There is currently only one content-addressable mirror (<link
xlink:href="http://tarballs.nixos.org"/>), but more can be specified in the <varname>hashedMirrors</varname> attribute in <filename>pkgs/build-support/fetchurl/mirrors.nix</filename>, or by setting the <envar>NIX_HASHED_MIRRORS</envar> environment variable to a whitespace-separated list of URLs.
</para>
<para>
Second, <function>fetchurl</function> has support for widely-mirrored
distribution sites such as SourceForge or the Linux kernel archives.
it will try to download <replaceable>path</replaceable> from a
configurable list of mirrors for <replaceable>site</replaceable>. (This
idea was borrowed from Gentoo Linux.) Example:
Second, <function>fetchurl</function> has support for widely-mirrored distribution sites such as SourceForge or the Linux kernel archives. Given a URL of the form <literal>mirror://<replaceable>site</replaceable>/<replaceable>path</replaceable></literal>, it will try to download <replaceable>path</replaceable> from a configurable list of mirrors for <replaceable>site</replaceable>. (This idea was borrowed from Gentoo Linux.) Example:
<literal>sourceforge</literal>, <literal>gnu</literal> and
<literal>kernel</literal>. The list of mirrors is defined in
<filename>pkgs/build-support/fetchurl/mirrors.nix</filename>. You can
override the list of mirrors for a particular site by setting the
environment variable
<envar>NIX_MIRRORS_<replaceable>site</replaceable></envar>, e.g.
Currently <replaceable>site</replaceable> can be<literal>sourceforge</literal>, <literal>gnu</literal> and <literal>kernel</literal>. The list of mirrors is defined in <filename>pkgs/build-support/fetchurl/mirrors.nix</filename>. You can override the list of mirrors for a particular site by setting the environment variable <envar>NIX_MIRRORS_<replaceable>site</replaceable></envar>, e.g.
The following people contributed to this release: Andres Löh, Arie
Middelkoop, Armijn Hemel, Eelco Dolstra, Marc Weber, Mart Kolthof, Martin
Bravenboer, Michael Raskin, Wouter den Breejen and Yury G. Kudryashov.
The following people contributed to this release: Andres Löh, Arie Middelkoop, Armijn Hemel, Eelco Dolstra, Marc Weber, Mart Kolthof, Martin Bravenboer, Michael Raskin, Wouter den Breejen and Yury G. Kudryashov.
<filename>pkgs/system/all-packages-generic.nix</filename> is gone, we now
just have <filename>pkgs/top-level/all-packages.nix</filename> that
contains all available packages. This should cause much less confusion
with users. <filename>all-packages.nix</filename> is a function that by
default returns packages for the current platform, but you can override
this by specifying a different <varname>system</varname> argument.
<filename>pkgs/system/all-packages-generic.nix</filename> is gone, we now just have <filename>pkgs/top-level/all-packages.nix</filename> that contains all available packages. This should cause much less confusion with users. <filename>all-packages.nix</filename> is a function that by default returns packages for the current platform, but you can override this by specifying a different <varname>system</varname> argument.
</para>
</listitem>
<listitem>
<para>
Certain packages in Nixpkgs are now user-configurable through a
configuration file, i.e., without having to edit the Nix expressions in
Nixpkgs. For instance, the Firefox provided in the Nixpkgs channel is
built without the RealPlayer plugin (for legal reasons). Previously, you
could easily enable RealPlayer support by editing the call to the Firefox
function in <filename>all-packages.nix</filename>, but such changes are
not respected when Firefox is subsequently updated through the Nixpkgs
channel.
Certain packages in Nixpkgs are now user-configurable through a configuration file, i.e., without having to edit the Nix expressions in Nixpkgs. For instance, the Firefox provided in the Nixpkgs channel is built without the RealPlayer plugin (for legal reasons). Previously, you could easily enable RealPlayer support by editing the call to the Firefox function in <filename>all-packages.nix</filename>, but such changes are not respected when Firefox is subsequently updated through the Nixpkgs channel.
</para>
<para>
The Nixpkgs configuration file (found in
<filename>~/.nixpkgs/config.nix</filename> or through the
<envar>NIXPKGS_CONFIG</envar> environment variable) is an attribute set
that contains configuration options that
<filename>all-packages.nix</filename> reads and uses for certain packages.
For instance, the following configuration file:
The Nixpkgs configuration file (found in<filename>~/.nixpkgs/config.nix</filename> or through the <envar>NIXPKGS_CONFIG</envar> environment variable) is an attribute set that contains configuration options that <filename>all-packages.nix</filename> reads and uses for certain packages. For instance, the following configuration file:
persistently enables RealPlayer support in the Firefox build.
</para>
<para>
(Actually, <literal>firefox.enableRealPlayer</literal> is the
<emphasis>only</emphasis> configuration option currently available, but
more are sure to be added.)
(Actually, <literal>firefox.enableRealPlayer</literal> is the<emphasis>only</emphasis> configuration option currently available, but more are sure to be added.)
<literal>i686-cygwin</literal>, i.e., Windows (using
<linkxlink:href="http://www.cygwin.com/">Cygwin</link>). The standard
environment on <literal>i686-cygwin</literal> by default builds
binaries for the Cygwin environment (i.e., it uses Cygwin tools and
produces executables that use the Cygwin library). However, there is
also a standard environment that produces binaries that use
<link
xlink:href="http://www.mingw.org/">MinGW</link>. You can
use it by calling <filename>all-package.nix</filename> with the
<varname>stdenvType</varname> argument set to
<literal>"i686-mingw"</literal>.
<literal>i686-cygwin</literal>, i.e., Windows (using<linkxlink:href="http://www.cygwin.com/">Cygwin</link>). The standard environment on <literal>i686-cygwin</literal> by default builds binaries for the Cygwin environment (i.e., it uses Cygwin tools and produces executables that use the Cygwin library). However, there is also a standard environment that produces binaries that use <link
xlink:href="http://www.mingw.org/">MinGW</link>. You can use it by calling <filename>all-package.nix</filename> with the <varname>stdenvType</varname> argument set to <literal>"i686-mingw"</literal>.
<literal>x86_64-linux</literal>, i.e., Linux on 64-bit AMD/Intel CPUs.
Unlike <literal>i686-linux</literal>, this platform doesn’t have a
pure <literal>stdenv</literal> yet.
<literal>x86_64-linux</literal>, i.e., Linux on 64-bit AMD/Intel CPUs. Unlike <literal>i686-linux</literal>, this platform doesn’t have a pure <literal>stdenv</literal> yet.
It is now <emphasis>much</emphasis> easier to override the default C compiler and other tools in <literal>stdenv</literal> for specific packages. <filename>all-packages.nix</filename> provides two utility functions for this purpose: <function>overrideGCC</function> and <function>overrideInStdenv</function>. Both take a <literal>stdenv</literal> and return an augmented <literal>stdenv</literal>; the formed changes the C compiler, and the latter adds additional packages to the front of <literal>stdenv</literal>’s initial <envar>PATH</envar>, allowing tools to be overridden.
</para>
<para>
For instance, the package <varname>strategoxt</varname> doesn’t build
with the GNU Make in <literal>stdenv</literal> (version 3.81), so we call
it with an augmented <literal>stdenv</literal> that uses GNU Make 3.80:
For instance, the package <varname>strategoxt</varname> doesn’t build with the GNU Make in <literal>stdenv</literal> (version 3.81), so we call it with an augmented <literal>stdenv</literal> that uses GNU Make 3.80:
It has also become much easier to experiment with changes to the
<literal>stdenv</literal> setup script (which notably contains the generic
builder). Since edits to <filename>pkgs/stdenv/generic/setup.sh</filename>
trigger a rebuild of <emphasis>everything</emphasis>, this was formerly
quite painful. But now <literal>stdenv</literal> contains a function to
“regenerate” <literal>stdenv</literal> with a different setup script,
allowing the use of a different setup script for specific packages:
It has also become much easier to experiment with changes to the<literal>stdenv</literal> setup script (which notably contains the generic builder). Since edits to <filename>pkgs/stdenv/generic/setup.sh</filename> trigger a rebuild of <emphasis>everything</emphasis>, this was formerly quite painful. But now <literal>stdenv</literal> contains a function to “regenerate” <literal>stdenv</literal> with a different setup script, allowing the use of a different setup script for specific packages:
Packages can now have a human-readable <emphasis>description</emphasis>
field. Package descriptions are shown by <literal>nix-env -qa
--description</literal>. In addition, they’re shown on the Nixpkgs
release page. A description can be added to a package as follows:
Packages can now have a human-readable <emphasis>description</emphasis> field. Package descriptions are shown by <literal>nix-env -qa --description</literal>. In addition, they’re shown on the Nixpkgs release page. A description can be added to a package as follows:
<programlisting>
stdenv.mkDerivation {
name = "exult-1.2";
@@ -533,34 +416,26 @@ stdenv.mkDerivation {
description = "A reimplementation of the Ultima VII game engine";
};
}</programlisting>
The <varname>meta</varname> attribute is not passed to the builder, so
changes to the description do not trigger a rebuild. Additional
<varname>meta</varname> attributes may be defined in the future (such as
the URL of the package’s homepage, the license, etc.).
The <varname>meta</varname> attribute is not passed to the builder, so changes to the description do not trigger a rebuild. Additional <varname>meta</varname> attributes may be defined in the future (such as the URL of the package’s homepage, the license, etc.).
</para>
</listitem>
</itemizedlist>
<para>
The following people contributed to this release: Andres Löh, Armijn Hemel,
Christof Douma, Eelco Dolstra, Eelco Visser, Mart Kolthof, Martin
Bravenboer, Merijn de Jonge, Rob Vermaas and Roy van den Broek.
The following people contributed to this release: Andres Löh, Armijn Hemel, Christof Douma, Eelco Dolstra, Eelco Visser, Mart Kolthof, Martin Bravenboer, Merijn de Jonge, Rob Vermaas and Roy van den Broek.
</para>
</section>
<sectionxml:id="release-notes-0.9">
<title>Release 0.9 (January 31, 2006)</title>
<para>
There have been zillions of changes since the last release of Nixpkgs. Many
packages have been added or updated. The following are some of the more
notable changes:
There have been zillions of changes since the last release of Nixpkgs. Many packages have been added or updated. The following are some of the more notable changes:
</para>
<itemizedlist>
<listitem>
<para>
Distribution files have been moved to
<link
Distribution files have been moved to<link
xlink:href="http://nixos.org/"/>.
</para>
</listitem>
@@ -576,24 +451,17 @@ stdenv.mkDerivation {
</listitem>
<listitem>
<para>
The old, unofficial Xlibs has been replaced by the official modularised
X11 distribution from X.org, i.e., X11R7.0. X11R7.0 consists of 287 (!)
packages, all of which are in Nixpkgs though not all have been tested. It
is now possible to build a working X server (previously we only had X
client libraries). We use a fully Nixified X server on NixOS.
The old, unofficial Xlibs has been replaced by the official modularised X11 distribution from X.org, i.e., X11R7.0. X11R7.0 consists of 287 (!) packages, all of which are in Nixpkgs though not all have been tested. It is now possible to build a working X server (previously we only had X client libraries). We use a fully Nixified X server on NixOS.
</para>
</listitem>
<listitem>
<para>
The Sun JDK 5 has been purified, i.e., it doesn’t require any non-Nix
components such as <filename>/lib/ld-linux.so.2</filename>. This means
that Java applications such as Eclipse and Azureus can run on NixOS.
The Sun JDK 5 has been purified, i.e., it doesn’t require any non-Nix components such as <filename>/lib/ld-linux.so.2</filename>. This means that Java applications such as Eclipse and Azureus can run on NixOS.
</para>
</listitem>
<listitem>
<para>
Hardware-accelerated OpenGL support, used by games like Quake 3 (which is
now built from source).
Hardware-accelerated OpenGL support, used by games like Quake 3 (which is now built from source).
</para>
</listitem>
<listitem>
@@ -608,8 +476,7 @@ stdenv.mkDerivation {
</listitem>
<listitem>
<para>
Some support for cross-compilation: cross-compiling builds of GCC and
Binutils, and cross-compiled builds of the C library uClibc.
Some support for cross-compilation: cross-compiling builds of GCC and Binutils, and cross-compiled builds of the C library uClibc.
</para>
</listitem>
<listitem>
@@ -618,8 +485,7 @@ stdenv.mkDerivation {
<itemizedlist>
<listitem>
<para>
teTeX, including support for building LaTeX documents using Nix (with
automatic dependency determination).
teTeX, including support for building LaTeX documents using Nix (with automatic dependency determination).
</para>
</listitem>
<listitem>
@@ -629,14 +495,12 @@ stdenv.mkDerivation {
</listitem>
<listitem>
<para>
System-level packages to support NixOS, e.g. Grub, GNU
<literal>parted</literal> and so on.
System-level packages to support NixOS, e.g. Grub, GNU<literal>parted</literal> and so on.
</para>
</listitem>
<listitem>
<para>
<literal>ecj</literal>, the Eclipse Compiler for Java, so we finally
have a freely distributable compiler that supports Java 5.0.
<literal>ecj</literal>, the Eclipse Compiler for Java, so we finally have a freely distributable compiler that supports Java 5.0.
</para>
</listitem>
<listitem>
@@ -661,8 +525,7 @@ stdenv.mkDerivation {
</listitem>
<listitem>
<para>
<literal>kdelibs</literal>. This allows us to add KDE-based packages
(such as <literal>kcachegrind</literal>).
<literal>kdelibs</literal>. This allows us to add KDE-based packages (such as <literal>kcachegrind</literal>).
</para>
</listitem>
</itemizedlist>
@@ -671,17 +534,14 @@ stdenv.mkDerivation {
</itemizedlist>
<para>
The following people contributed to this release: Andres Löh, Armijn Hemel,
Bogdan Dumitriu, Christof Douma, Eelco Dolstra, Eelco Visser, Mart Kolthof,
Martin Bravenboer, Rob Vermaas and Roy van den Broek.
The following people contributed to this release: Andres Löh, Armijn Hemel, Bogdan Dumitriu, Christof Douma, Eelco Dolstra, Eelco Visser, Mart Kolthof, Martin Bravenboer, Rob Vermaas and Roy van den Broek.
</para>
</section>
<sectionxml:id="release-notes-0.8">
<title>Release 0.8 (April 11, 2005)</title>
<para>
This release is mostly to remain synchronised with the changed hashing
scheme in Nix 0.8.
This release is mostly to remain synchronised with the changed hashing scheme in Nix 0.8.
</para>
<para>
@@ -706,16 +566,10 @@ stdenv.mkDerivation {
<itemizedlist>
<listitem>
<para>
The bootstrap process for the standard build environment on Linux
(stdenv-linux) has been improved. It is no longer dependent in its initial
bootstrap stages on the system Glibc, GCC, and other tools. Rather,
Nixpkgs contains a statically linked bash and curl, and uses that to
download other statically linked tools. These are then used to build a
Glibc and dynamically linked versions of all other tools.
The bootstrap process for the standard build environment on Linux (stdenv-linux) has been improved. It is no longer dependent in its initial bootstrap stages on the system Glibc, GCC, and other tools. Rather, Nixpkgs contains a statically linked bash and curl, and uses that to download other statically linked tools. These are then used to build a Glibc and dynamically linked versions of all other tools.
</para>
<para>
This change also makes the bootstrap process faster. For instance, GCC is
built only once instead of three times.
This change also makes the bootstrap process faster. For instance, GCC is built only once instead of three times.
</para>
<para>
(Contributed by Armijn Hemel.)
@@ -723,17 +577,13 @@ stdenv.mkDerivation {
</listitem>
<listitem>
<para>
Tarballs used by Nixpkgs are now obtained from the same server that hosts
Nixpkgs (<link
xlink:href="http://catamaran.labs.cs.uu.nl/"/>). This
reduces the risk of packages being unbuildable due to moved or deleted
files on various servers.
Tarballs used by Nixpkgs are now obtained from the same server that hosts Nixpkgs (<link
xlink:href="http://catamaran.labs.cs.uu.nl/"/>). This reduces the risk of packages being unbuildable due to moved or deleted files on various servers.
</para>
</listitem>
<listitem>
<para>
There now is a generic mechanism for building Perl modules. See the
various Perl modules defined in pkgs/system/all-packages-generic.nix.
There now is a generic mechanism for building Perl modules. See the various Perl modules defined in pkgs/system/all-packages-generic.nix.
The Nixpkgs project receives a fairly high number of contributions via GitHub
pull requests. Reviewing and approving these is an important task and a way
to contribute to the project.
The Nixpkgs project receives a fairly high number of contributions via GitHub pull requests. Reviewing and approving these is an important task and a way to contribute to the project.
</para>
<para>
The high change rate of Nixpkgs makes any pull request that remains open for
too long subject to conflicts that will require extra work from the submitter
or the merger. Reviewing pull requests in a timely manner and being
responsive to the comments is the key to avoid this issue. GitHub provides
this list of ready to merge, unreviewed pull requests</link>.
The high change rate of Nixpkgs makes any pull request that remains open for too long subject to conflicts that will require extra work from the submitter or the merger. Reviewing pull requests in a timely manner and being responsive to the comments is the key to avoid this issue. GitHub provides sort filters that can be used to see the <link
xlink:href="https://github.com/NixOS/nixpkgs/pulls?q=is%3Apr+is%3Aopen+sort%3Aupdated-desc">most recently</link> and the <link
xlink:href="https://github.com/NixOS/nixpkgs/pulls?q=is%3Apr+is%3Aopen+sort%3Aupdated-asc">least recently</link> updated pull requests. We highly encourage looking at <linkxlink:href="https://github.com/NixOS/nixpkgs/pulls?q=is%3Apr+is%3Aopen+review%3Anone+status%3Asuccess+-label%3A%222.status%3A+work-in-progress%22+no%3Aproject+no%3Aassignee+no%3Amilestone"> this list of ready to merge, unreviewed pull requests</link>.
</para>
<para>
When reviewing a pull request, please always be nice and polite.
Controversial changes can lead to controversial opinions, but it is important
to respect every community member and their work.
When reviewing a pull request, please always be nice and polite. Controversial changes can lead to controversial opinions, but it is important to respect every community member and their work.
</para>
<para>
GitHub provides reactions as a simple and quick way to provide feedback to
pull requests or any comments. The thumb-down reaction should be used with
care and if possible accompanied with some explanation so the submitter has
directions to improve their contribution.
GitHub provides reactions as a simple and quick way to provide feedback to pull requests or any comments. The thumb-down reaction should be used with care and if possible accompanied with some explanation so the submitter has directions to improve their contribution.
</para>
<para>
pull request reviews should include a list of what has been reviewed in a
comment, so other reviewers and mergers can know the state of the review.
pull request reviews should include a list of what has been reviewed in a comment, so other reviewers and mergers can know the state of the review.
</para>
<para>
All the review template samples provided in this section are generic and
meant as examples. Their usage is optional and the reviewer is free to adapt
them to their liking.
All the review template samples provided in this section are generic and meant as examples. Their usage is optional and the reviewer is free to adapt them to their liking.
A package update is the most trivial and common type of pull request. These
pull requests mainly consist of updating the version part of the package
name and the source hash.
A package update is the most trivial and common type of pull request. These pull requests mainly consist of updating the version part of the package name and the source hash.
</para>
<para>
It can happen that non-trivial updates include patches or more complex
changes.
It can happen that non-trivial updates include patches or more complex changes.
</para>
<para>
@@ -82,8 +54,7 @@
<itemizedlist>
<listitem>
<para>
<literal>8.has: package (update)</literal> and any topic label that fit
the updated package.
<literal>8.has: package (update)</literal> and any topic label that fit the updated package.
will make GitHub notify users based on the submitted changes, but it can
happen that it misses some of the package maintainers.
<linkxlink:href="https://help.github.com/articles/about-codeowners/">CODEOWNERS</link> will make GitHub notify users based on the submitted changes, but it can happen that it misses some of the package maintainers.
</para>
</listitem>
</itemizedlist>
@@ -119,15 +88,12 @@
<itemizedlist>
<listitem>
<para>
License can change with version updates, so it should be checked to
match the upstream license.
License can change with version updates, so it should be checked to match the upstream license.
</para>
</listitem>
<listitem>
<para>
If the package has no maintainer, a maintainer must be set. This can be
the update submitter or a community member that accepts to take
maintainership of the package.
If the package has no maintainer, a maintainer must be set. This can be the update submitter or a community member that accepts to take maintainership of the package.
</para>
</listitem>
</itemizedlist>
@@ -144,14 +110,10 @@
<itemizedlist>
<listitem>
<para>
pull requests are often targeted to the master or staging branch, and
building the pull request locally when it is submitted can trigger many
source builds.
pull requests are often targeted to the master or staging branch, and building the pull request locally when it is submitted can trigger many source builds.
</para>
<para>
It is possible to rebase the changes on nixos-unstable or
nixpkgs-unstable for easier review by running the following commands
from a nixpkgs clone.
It is possible to rebase the changes on nixos-unstable or nixpkgs-unstable for easier review by running the following commands from a nixpkgs clone.
This should be done only once to be able to fetch channel branches
from the nixpkgs-channels repository.
This should be done only once to be able to fetch channel branches from the nixpkgs-channels repository.
</para>
</callout>
<calloutarearefs='reviewing-rebase-2'>
@@ -174,9 +135,7 @@
</callout>
<calloutarearefs='reviewing-rebase-3'>
<para>
Fetching the pull request changes, <varname>PRNUMBER</varname> is the
number at the end of the pull request title and
<varname>BASEBRANCH</varname> the base branch of the pull request.
Fetching the pull request changes, <varname>PRNUMBER</varname> is the number at the end of the pull request title and <varname>BASEBRANCH</varname> the base branch of the pull request.
tool can be used to review a pull request content in a single command.
<varname>PRNUMBER</varname> should be replaced by the number at the end
of the pull request title. You can also provide the full github pull
request url.
The<linkxlink:href="https://github.com/Mic92/nixpkgs-review">nixpkgs-review</link> tool can be used to review a pull request content in a single command. <varname>PRNUMBER</varname> should be replaced by the number at the end of the pull request title. You can also provide the full github pull request url.
will make GitHub notify users based on the submitted changes, but it can
happen that it misses some of the package maintainers.
<linkxlink:href="https://help.github.com/articles/about-codeowners/">CODEOWNERS</link> will make GitHub notify users based on the submitted changes, but it can happen that it misses some of the package maintainers.
</para>
</listitem>
</itemizedlist>
@@ -399,9 +345,7 @@
<itemizedlist>
<listitem>
<para>
Type should be appropriate (string related types differs in their
merging capabilities, <literal>optionSet</literal> and
<literal>string</literal> types are deprecated).
Type should be appropriate (string related types differs in their merging capabilities, <literal>optionSet</literal> and <literal>string</literal> types are deprecated).
</para>
</listitem>
<listitem>
@@ -418,23 +362,19 @@
<itemizedlist>
<listitem>
<para>
<literal>mkRenamedOptionModule</literal> and
<literal>mkAliasOptionModule</literal> functions provide way to make
option changes backward compatible.
<literal>mkRenamedOptionModule</literal> and<literal>mkAliasOptionModule</literal> functions provide way to make option changes backward compatible.
</para>
</listitem>
</itemizedlist>
</listitem>
<listitem>
<para>
Ensure that removed options are declared with
<literal>mkRemovedOptionModule</literal>
Ensure that removed options are declared with<literal>mkRemovedOptionModule</literal>
</para>
</listitem>
<listitem>
<para>
Ensure that changes that are not backward compatible are mentioned in
release notes.
Ensure that changes that are not backward compatible are mentioned in release notes.
</para>
</listitem>
<listitem>
@@ -480,8 +420,7 @@
<itemizedlist>
<listitem>
<para>
<literal>8.has: module (new)</literal> and any topic label that fit the
module.
<literal>8.has: module (new)</literal> and any topic label that fit the module.
</para>
</listitem>
</itemizedlist>
@@ -498,9 +437,7 @@
<itemizedlist>
<listitem>
<para>
Type should be appropriate (string related types differs in their
merging capabilities, <literal>optionSet</literal> and
<literal>string</literal> types are deprecated).
Type should be appropriate (string related types differs in their merging capabilities, <literal>optionSet</literal> and <literal>string</literal> types are deprecated).
</para>
</listitem>
<listitem>
@@ -522,8 +459,7 @@
</listitem>
<listitem>
<para>
Module documentation should be declared with
<literal>meta.doc</literal>.
Module documentation should be declared with<literal>meta.doc</literal>.
</para>
</listitem>
</itemizedlist>
@@ -535,8 +471,7 @@
<itemizedlist>
<listitem>
<para>
For example, enabling a module should not open firewall ports by
default.
For example, enabling a module should not open firewall ports by default.
</para>
</listitem>
</itemizedlist>
@@ -573,25 +508,18 @@
</para>
<para>
If you consider having enough knowledge and experience in a topic and would
like to be a long-term reviewer for related submissions, please contact the
current reviewers for that topic. They will give you information about the
reviewing process. The main reviewers for a topic can be hard to find as
there is no list, but checking past pull requests to see who reviewed or
git-blaming the code to see who committed to that topic can give some hints.
If you consider having enough knowledge and experience in a topic and would like to be a long-term reviewer for related submissions, please contact the current reviewers for that topic. They will give you information about the reviewing process. The main reviewers for a topic can be hard to find as there is no list, but checking past pull requests to see who reviewed or git-blaming the code to see who committed to that topic can give some hints.
</para>
<para>
Container system, boot system and library changes are some examples of the
pull requests fitting this category.
Container system, boot system and library changes are some examples of the pull requests fitting this category.
It is possible for community members that have enough knowledge and
experience on a special topic to contribute by merging pull requests.
It is possible for community members that have enough knowledge and experience on a special topic to contribute by merging pull requests.
</para>
<para>
@@ -608,12 +536,8 @@ policy.
-->
<para>
In a case a contributor definitively leaves the Nix community, they should
create an issue or post on
<link
xlink:href="https://discourse.nixos.org">Discourse</link> with
references of packages and modules they maintain so the maintainership can
be taken over by other contributors.
In a case a contributor definitively leaves the Nix community, they should create an issue or post on <link
xlink:href="https://discourse.nixos.org">Discourse</link> with references of packages and modules they maintain so the maintainership can be taken over by other contributors.
Read <linkxlink:href="https://nixos.org/nixpkgs/manual/">Manual (How to
write packages for Nix)</link>.
Read <linkxlink:href="https://nixos.org/nixpkgs/manual/">Manual (How to write packages for Nix)</link>.
</para>
</listitem>
<listitem>
@@ -23,15 +22,11 @@
<itemizedlist>
<listitem>
<para>
You can make branch from a commit of your local
<command>nixos-version</command>. That will help you to avoid
additional local compilations. Because you will receive packages from
binary cache.
You can make branch from a commit of your local<command>nixos-version</command>. That will help you to avoid additional local compilations. Because you will receive packages from binary cache.
<itemizedlist>
<listitem>
<para>
For example: <command>nixos-version</command> returns
<command>15.05.git.0998212 (Dingo)</command>. So you can do:
For example: <command>nixos-version</command> returns<command>15.05.git.0998212 (Dingo)</command>. So you can do:
</para>
</listitem>
</itemizedlist>
@@ -55,9 +50,7 @@
<itemizedlist>
<listitem>
<para>
If you removed pkgs, made some major NixOS changes etc., write about
Make sure it's in<command>pkgs/top-level/all-packages.nix</command>
</para>
</listitem>
<listitem>
<para>
<command>nix-env -i pkg-name -f <path to your local nixpkgs
folder></command>
<command>nix-env -i pkg-name -f <path to your local nixpkgs folder></command>
</para>
</listitem>
</itemizedlist>
@@ -149,15 +138,11 @@ Additional information.
</listitem>
<listitem>
<para>
<emphasis>If you don't want to install pkg in you
profile</emphasis>.
<emphasis>If you don't want to install pkg in you profile</emphasis>.
<itemizedlist>
<listitem>
<para>
<command>nix-build -A pkg-attribute-name <path to your local
nixpkgs folder>/default.nix</command> and check results in the
folder <command>result</command>. It will appear in the same
directory where you did <command>nix-build</command>.
<command>nix-build -A pkg-attribute-name <path to your local nixpkgs folder>/default.nix</command> and check results in the folder <command>result</command>. It will appear in the same directory where you did <command>nix-build</command>.
</para>
</listitem>
</itemizedlist>
@@ -165,9 +150,7 @@ Additional information.
</listitem>
<listitem>
<para>
If you did <command>nix-env -i pkg-name</command> you can do
<command>nix-env -e pkg-name</command> to uninstall it from your
system.
If you did <command>nix-env -i pkg-name</command> you can do<command>nix-env -e pkg-name</command> to uninstall it from your system.
</para>
</listitem>
</itemizedlist>
@@ -179,10 +162,7 @@ Additional information.
<itemizedlist>
<listitem>
<para>
You can add new module to your NixOS configuration file (usually
it's <command>/etc/nixos/configuration.nix</command>). And do
<command>sudo nixos-rebuild test -I nixpkgs=<path to your local
nixpkgs folder> --fast</command>.
You can add new module to your NixOS configuration file (usually it's <command>/etc/nixos/configuration.nix</command>). And do <command>sudo nixos-rebuild test -I nixpkgs=<path to your local nixpkgs folder> --fast</command>.
</para>
</listitem>
</itemizedlist>
@@ -193,9 +173,7 @@ Additional information.
</listitem>
<listitem>
<para>
If you have commits <command>pkg-name: oh, forgot to insert
whitespace</command>: squash commits in this case. Use <command>git rebase
-i</command>.
If you have commits <command>pkg-name: oh, forgot to insert whitespace</command>: squash commits in this case. Use <command>git rebase -i</command>.
</para>
</listitem>
<listitem>
@@ -220,8 +198,7 @@ Additional information.
<itemizedlist>
<listitem>
<para>
Write the title in format <command>(pkg-name | nixos/<module>):
improvement</command>.
Write the title in format <command>(pkg-name | nixos/<module>): improvement</command>.
<itemizedlist>
<listitem>
<para>
@@ -233,8 +210,7 @@ Additional information.
</listitem>
<listitem>
<para>
Write in comment if you have tested your patch. Do not rely much on
<command>TravisCI</command>.
Write in comment if you have tested your patch. Do not rely much on<command>TravisCI</command>.
</para>
</listitem>
<listitem>
@@ -244,8 +220,7 @@ Additional information.
</listitem>
<listitem>
<para>
Notify maintainers of the package. For example add to the message:
<command>cc @jagajaga @domenkozar</command>.
Notify maintainers of the package. For example add to the message:<command>cc @jagajaga @domenkozar</command>.
</para>
</listitem>
</itemizedlist>
@@ -257,64 +232,39 @@ Additional information.
<title>Pull Request Template</title>
<para>
The pull request template helps determine what steps have been made for a
contribution so far, and will help guide maintainers on the status of a
change. The motivation section of the PR should include any extra details
the title does not address and link any existing issues related to the pull
request.
The pull request template helps determine what steps have been made for a contribution so far, and will help guide maintainers on the status of a change. The motivation section of the PR should include any extra details the title does not address and link any existing issues related to the pull request.
</para>
<para>
When a PR is created, it will be pre-populated with some checkboxes detailed
below:
When a PR is created, it will be pre-populated with some checkboxes detailed below:
When sandbox builds are enabled, Nix will setup an isolated environment for each build process. It is used to remove further hidden dependencies set by the build environment to improve reproducibility. This includes access to the network during the build outside of <function>fetch*</function> functions and files outside the Nix store. Depending on the operating system access to other resources are blocked as well (ex. inter process communication is isolated on Linux); see <link
xlink:href="https://nixos.org/nix/manual/#description-45">build-use-sandbox</link> in Nix manual for details.
</para>
<para>
Sandboxing is not enabled by default in Nix due to a small performance hit
Sandboxing is not enabled by default in Nix due to a small performance hit on each build. In pull requests for <link
xlink:href="https://github.com/NixOS/nixpkgs/">nixpkgs</link> people are asked to test builds with sandboxing enabled (see <literal>Tested using sandboxing</literal> in the pull request template) because in<link
xlink:href="https://nixos.org/hydra/">https://nixos.org/hydra/</link> sandboxing is also used.
</para>
<para>
Depending if you use NixOS or other platforms you can use one of the
following methods to enable sandboxing
<emphasisrole="bold">before</emphasis> building the package:
Depending if you use NixOS or other platforms you can use one of the following methods to enable sandboxing <emphasisrole="bold">before</emphasis> building the package:
<itemizedlist>
<listitem>
<para>
<emphasisrole="bold">Globally enable sandboxing on NixOS</emphasis>:
add the following to <filename>configuration.nix</filename>
<emphasisrole="bold">Globally enable sandboxing on NixOS</emphasis>: add the following to <filename>configuration.nix</filename>
<screen>nix.useSandbox = true;</screen>
</para>
</listitem>
<listitem>
<para>
<emphasisrole="bold">Globally enable sandboxing on non-NixOS
platforms</emphasis>: add the following to:
<filename>/etc/nix/nix.conf</filename>
<emphasisrole="bold">Globally enable sandboxing on non-NixOS platforms</emphasis>: add the following to: <filename>/etc/nix/nix.conf</filename>
<screen>build-use-sandbox = true</screen>
</para>
</listitem>
@@ -326,11 +276,7 @@ Additional information.
<title>Built on platform(s)</title>
<para>
Many Nix packages are designed to run on multiple platforms. As such, it's
important to let the maintainer know which platforms your changes have been
tested on. It's not always practical to test a change on all platforms, and
is not required for a pull request to be merged. Only check the systems you
tested the build on in this section.
Many Nix packages are designed to run on multiple platforms. As such, it's important to let the maintainer know which platforms your changes have been tested on. It's not always practical to test a change on all platforms, and is not required for a pull request to be merged. Only check the systems you tested the build on in this section.
</para>
</section>
@@ -338,37 +284,31 @@ Additional information.
<title>Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)</title>
<para>
Packages with automated tests are much more likely to be merged in a timely
fashion because it doesn't require as much manual testing by the maintainer
to verify the functionality of the package. If there are existing tests for
the package, they should be run to verify your changes do not break the
tests. Tests only apply to packages with NixOS modules defined and can only
be run on Linux. For more details on writing and running tests, see the
Packages with automated tests are much more likely to be merged in a timely fashion because it doesn't require as much manual testing by the maintainer to verify the functionality of the package. If there are existing tests for the package, they should be run to verify your changes do not break the tests. Tests only apply to packages with NixOS modules defined and can only be run on Linux. For more details on writing and running tests, see the <link
xlink:href="https://nixos.org/nixos/manual/index.html#sec-nixos-tests">section in the NixOS manual</link>.
<title>Tested compilation of all pkgs that depend on this change using <command>nix-review</command></title>
<title>Tested compilation of all pkgs that depend on this change using <command>nixpkgs-review</command></title>
<para>
If you are updating a package's version, you can use nix-review to make
sure all packages that depend on the updated package still compile
correctly. The <command>nix-review</command> utility can look for and build
all dependencies either based on uncommited changes with the
<literal>wip</literal> option or specifying a github pull request number.
If you are updating a package's version, you can use nixpkgs-review to make sure all packages that depend on the updated package still compile correctly. The <command>nixpkgs-review</command> utility can look for and build all dependencies either based on uncommited changes with the <literal>wip</literal> option or specifying a github pull request number.
<screen>nix run nixpkgs.nixpkgs-review -c nixpkgs-review wip</screen>
</para>
<para>
review changes from last commit:
<screen>nix run nixpkgs.nixpkgs-review -c nixpkgs-review rev HEAD</screen>
</para>
</section>
@@ -376,13 +316,7 @@ Additional information.
<title>Tested execution of all binary files (usually in <filename>./result/bin/</filename>)</title>
<para>
It's important to test any executables generated by a build when you change
or create a package in nixpkgs. This can be done by looking in
<filename>./result/bin</filename> and running any files in there, or at a
minimum, the main executable for the package. For example, if you make a
change to <package>texlive</package>, you probably would only check the
binaries associated with the change you made rather than testing all of
them.
It's important to test any executables generated by a build when you change or create a package in nixpkgs. This can be done by looking in <filename>./result/bin</filename> and running any files in there, or at a minimum, the main executable for the package. For example, if you make a change to <package>texlive</package>, you probably would only check the binaries associated with the change you made rather than testing all of them.
The contributing document has detailed information on standards the Nix
community has for commit messages, reviews, licensing of contributions you
make to the project, etc... Everyone should read and understand the
standards the community has for contributing before submitting a pull
request.
The last checkbox is fits<link
xlink:href="https://github.com/NixOS/nixpkgs/blob/master/.github/CONTRIBUTING.md">CONTRIBUTING.md</link>. The contributing document has detailed information on standards the Nix community has for commit messages, reviews, licensing of contributions you make to the project, etc... Everyone should read and understand the standards the community has for contributing before submitting a pull request.
</para>
</section>
</section>
@@ -435,61 +363,49 @@ Additional information.
<itemizedlist>
<listitem>
<para>
Commits must be sufficiently tested before being merged, both for the
master and staging branches.
Commits must be sufficiently tested before being merged, both for the master and staging branches.
</para>
</listitem>
<listitem>
<para>
Hydra builds for master and staging should not be used as testing
platform, it's a build farm for changes that have been already tested.
Hydra builds for master and staging should not be used as testing platform, it's a build farm for changes that have been already tested.
</para>
</listitem>
<listitem>
<para>
When changing the bootloader installation process, extra care must be
taken. Grub installations cannot be rolled back, hence changes may break
people's installations forever. For any non-trivial change to the
bootloader please file a PR asking for review, especially from @edolstra.
When changing the bootloader installation process, extra care must be taken. Grub installations cannot be rolled back, hence changes may break people's installations forever. For any non-trivial change to the bootloader please file a PR asking for review, especially from @edolstra.
The <literal>staging-next</literal> branch is for stabilizing mass-rebuilds submitted to the <literal>staging</literal> branch prior to merging them into <literal>master</literal>.
Mass-rebuilds should go via the <literal>staging</literal> branch.
It should only see non-breaking commits that are fixing issues blocking it from being merged into the <literal>master </literal> branch.
</para>
<para>
If the branch is already in a broken state, please refrain from adding extra new breakages. Stabilize it for a few days and then merge into master.
If you're cherry-picking a commit to a stable release branch, always use
<command>git cherry-pick -xe</command> and ensure the message contains a
clear description about why this needs to be included in the stable
branch.
If you're cherry-picking a commit to a stable release branch, always use<command>git cherry-pick -xe</command> and ensure the message contains a clear description about why this needs to be included in the stable branch.
</para>
<para>
An example of a cherry-picked commit would look like this:
configuration for known-hardware</link> at this point or after
installation.
</para>
<note>
<para>
@@ -414,11 +418,11 @@
Do the installation:
<screen>
<prompt># </prompt>nixos-install</screen>
Cross fingers. If this fails due to a temporary problem (such as a network
issue while downloading binaries from the NixOS binary cache), you can
just re-run <command>nixos-install</command>. Otherwise, fix your
<filename>configuration.nix</filename> and then re-run
<command>nixos-install</command>.
This will install your system based on the configuration you provided.
If anything fails due to a configuration problem or any other issue
(such as a network outage while downloading binaries from the NixOS
binary cache), you can re-run <command>nixos-install</command> after
fixing your <filename>configuration.nix</filename>.
</para>
<para>
As the last step, <command>nixos-install</command> will ask you to set the
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.
