From 360f420ac7df37e8987473f49e00175ef70732b8 Mon Sep 17 00:00:00 2001 From: Graham Christensen Date: Mon, 27 Aug 2018 19:54:41 -0400 Subject: [PATCH] nixpkgs docs: normalize --- doc/functions.xml | 31 ++++++++++---------- doc/languages-frameworks/java.xml | 24 +++++++--------- doc/package-notes.xml | 48 +++++++++++++++++++------------ doc/platform-notes.xml | 8 ++---- doc/reviewing-contributions.xml | 39 +++++++++++++------------ 5 files changed, 80 insertions(+), 70 deletions(-) diff --git a/doc/functions.xml b/doc/functions.xml index 9bbf97c5c71e..ec188e234543 100644 --- a/doc/functions.xml +++ b/doc/functions.xml @@ -523,7 +523,8 @@ merge:"diff3" tag specifies the tag of the resulting image. By - default it's null, which indicates that the nix output hash will be used as tag. + default it's null, which indicates that the nix output + hash will be used as tag. @@ -669,12 +670,12 @@ merge:"diff3" imageDigest specifies the digest of the image to be downloaded. Skopeo can be used to get the digest of an image, with its - inspect subcommand. Since a given imageName - may transparently refer to a manifest list of images which support - multiple architectures and/or operating systems, supply the `--override-os` - and `--override-arch` 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. + inspect subcommand. Since a given + imageName may transparently refer to a manifest list + of images which support multiple architectures and/or operating systems, + supply the `--override-os` and `--override-arch` 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. $ nix-shell --packages skopeo jq --command "skopeo --override-os linux --override-arch x86_64 inspect docker://docker.io/nixos/nix:1.11 | jq -r '.Digest'" sha256:20d9485b25ecfd89204e843a962c1bd70e9cc6858d65d7f5fadc340246e2116b @@ -697,16 +698,16 @@ merge:"diff3" - - os, if specified, is the operating system of the fetched image. - By default it's linux. - + + os, if specified, is the operating system of the + fetched image. By default it's linux. + - - arch, if specified, is the cpu architecture of the fetched image. - By default it's x86_64. - + + arch, if specified, is the cpu architecture of the + fetched image. By default it's x86_64. + diff --git a/doc/languages-frameworks/java.xml b/doc/languages-frameworks/java.xml index 1acea6a7547a..667a795a8d3a 100644 --- a/doc/languages-frameworks/java.xml +++ b/doc/languages-frameworks/java.xml @@ -16,18 +16,17 @@ stdenv.mkDerivation { } Note that jdk is an alias for the OpenJDK (self-built - where available, or pre-built via Zulu). - Platforms with OpenJDK not (yet) in Nixpkgs (Aarch32, - Aarch64) point to the (unfree) - oraclejdk. - + where available, or pre-built via Zulu). Platforms with OpenJDK not (yet) in + Nixpkgs (Aarch32, Aarch64) point to the + (unfree) oraclejdk. + JAR files that are intended to be used by other packages should be installed - in $out/share/java. JDKs have a stdenv setup hook - that add any JARs in the share/java directories of the - build inputs to the CLASSPATH environment variable. For - instance, if the package libfoo installs a JAR named + in $out/share/java. JDKs have a stdenv setup hook that + add any JARs in the share/java directories of the build + inputs to the CLASSPATH environment variable. For instance, if + the package libfoo installs a JAR named foo.jar in its share/java directory, and another package declares the attribute @@ -61,18 +60,17 @@ installPhase = ${jre}/bin/java instead of ${jdk}/bin/java, you prevent your package from depending on the JDK at runtime. - + - + Note all JDKs passthru home, so if your application requires environment variables like JAVA_HOME being set, that can be done in a generic fashion with the --set argument of makeWrapper: - --set JAVA_HOME ${jdk.home} - + It is possible to use a different Java compiler than javac diff --git a/doc/package-notes.xml b/doc/package-notes.xml index 0634432fe95a..8c7c63c8c8d7 100644 --- a/doc/package-notes.xml +++ b/doc/package-notes.xml @@ -709,40 +709,50 @@ overrides = super: self: rec { Citrix Receiver - The Citrix Receiver is a remote - desktop viewer which provides access to - XenDesktop installations. + The Citrix + Receiver is a remote desktop viewer which provides access to + XenDesktop + installations.
Basic usage + - The tarball archive needs to be downloaded manually as the licenses agreements of the vendor - need to be accepted first. This is available at the - download page at citrix.com. - Then run nix-prefetch-url file://$PWD/linuxx64-$version.tar.gz. - With the archive available in the store the package can be built and installed with Nix. + The tarball archive needs to be downloaded manually as the licenses + agreements of the vendor need to be accepted first. This is available at + the + download + page at citrix.com. Then run nix-prefetch-url + file://$PWD/linuxx64-$version.tar.gz. With the archive available + in the store the package can be built and installed with Nix. - Note: it's recommended to install Citrix Receiver using - nix-env -i or globally to ensure that the .desktop files - are installed properly into $XDG_CONFIG_DIRS. Otherwise it won't - be possible to open .ica files - automatically from the browser to start a Citrix connection. + Note: it's recommended to install Citrix + Receiver using nix-env -i or globally to + ensure that the .desktop files are installed properly + into $XDG_CONFIG_DIRS. Otherwise it won't be possible to + open .ica files automatically from the browser to start + a Citrix connection.
+
Custom certificates + - The Citrix Receiver in nixpkgs trusts several certificates - from the Mozilla database by default. - However several companies using Citrix might require their own corporate certificate. On distros with imperative + The Citrix Receiver in nixpkgs trusts + several certificates + from the + Mozilla database 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 $ICAROOT, - however this directory is a store path in nixpkgs. In order to work around this issue the package provides a simple - mechanism to add custom certificates without rebuilding the entire package using symlinkJoin: - + however this directory is a store path in nixpkgs. In + order to work around this issue the package provides a simple mechanism to + add custom certificates without rebuilding the entire package using + symlinkJoin: { config.allowUnfree = true; }; let extraCerts = [ ./custom-cert-1.pem ./custom-cert-2.pem /* ... */ ]; in diff --git a/doc/platform-notes.xml b/doc/platform-notes.xml index ea581421547d..cde27b8a5edf 100644 --- a/doc/platform-notes.xml +++ b/doc/platform-notes.xml @@ -29,7 +29,6 @@ } - On darwin libraries are linked using absolute paths, libraries are @@ -47,19 +46,19 @@ } - Even if the libraries are linked using absolute paths and resolved via their install_name correctly, tests can sometimes fail - to run binaries. This happens because the checkPhase + to run binaries. This happens because the checkPhase runs before the libraries are installed. This can usually be solved by running the tests after the installPhase or alternatively by using DYLD_LIBRARY_PATH. More information about this variable - can be found in the dyld + can be found in the + dyld 1 manpage. @@ -77,7 +76,6 @@ } - Some packages assume xcode is available and use xcrun diff --git a/doc/reviewing-contributions.xml b/doc/reviewing-contributions.xml index b2a2675c3e65..6b854e085549 100644 --- a/doc/reviewing-contributions.xml +++ b/doc/reviewing-contributions.xml @@ -6,18 +6,20 @@ Reviewing contributions - The following section is a draft, and the policy for reviewing is still being - discussed in issues such as #11166 - and and + #20836 . - 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. The high change rate of nixpkgs makes any pull request that remains open for @@ -40,10 +42,10 @@ to respect every community member and their work. - 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. Pull-request reviews should include a list of what has been reviewed in a @@ -117,8 +119,8 @@ - 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. @@ -143,8 +145,8 @@ 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. + building the pull-request locally when it is submitted can trigger many + source builds. It is possible to rebase the changes on nixos-unstable or @@ -605,11 +607,12 @@ policy. --> - In a case a contributor leaves definitively the Nix community, he - should create an issue or post on Discourse with - references of packages and modules he maintains so the - maintainership can be taken over by other contributors. + references of packages and modules he maintains so the maintainership can be + taken over by other contributors.