forked from NixOS/nixpkgs
-
Notifications
You must be signed in to change notification settings - Fork 1
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Merge remote-tracking branch 'upstream/master' into mingw-rocksdb
Can just use single commit from facebook/rocksdb#6076 for rocksdb!
- Loading branch information
Showing
5,229 changed files
with
170,356 additions
and
101,546 deletions.
The diff you're trying to view is too large. We only load the first 3000 changed files.
There are no files selected for viewing
Validating CODEOWNERS rules …
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1 +1 @@ | ||
| 19.09 | ||
| 20.03 |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,139 @@ | ||
| <chapter xmlns="http://docbook.org/ns/docbook" | ||
| xmlns:xlink="http://www.w3.org/1999/xlink" | ||
| xmlns:xi="http://www.w3.org/2001/XInclude" | ||
| xml:id="chap-pkgs-fetchers"> | ||
| <title>Fetchers</title> | ||
| <para> | ||
| 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. | ||
| </para> | ||
| <programlisting><![CDATA[ | ||
| { stdenv, fetchurl }: | ||
| stdenv.mkDerivation { | ||
| name = "hello"; | ||
| src = fetchurl { | ||
| url = "http://www.example.org/hello.tar.gz"; | ||
| sha256 = "1111111111111111111111111111111111111111111111111111"; | ||
| }; | ||
| } | ||
| ]]></programlisting> | ||
| <para> | ||
| 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. | ||
| </para> | ||
| </listitem> | ||
| </varlistentry> | ||
| </variablelist> | ||
| </chapter> |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,12 @@ | ||
| <chapter xmlns="http://docbook.org/ns/docbook" | ||
| xmlns:xi="http://www.w3.org/2001/XInclude" | ||
| xml:id="chap-images"> | ||
| <title>Images</title> | ||
| <para> | ||
| This chapter describes tools for creating various types of images. | ||
| </para> | ||
| <xi:include href="images/appimagetools.xml" /> | ||
| <xi:include href="images/dockertools.xml" /> | ||
| <xi:include href="images/ocitools.xml" /> | ||
| <xi:include href="images/snaptools.xml" /> | ||
| </chapter> |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,102 @@ | ||
| <section xmlns="http://docbook.org/ns/docbook" | ||
| xmlns:xlink="http://www.w3.org/1999/xlink" | ||
| xmlns:xi="http://www.w3.org/2001/XInclude" | ||
| xml:id="sec-pkgs-appimageTools"> | ||
| <title>pkgs.appimageTools</title> | ||
|
|
||
| <para> | ||
| <varname>pkgs.appimageTools</varname> is a set of functions for extracting and wrapping <link xlink: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. | ||
| </para> | ||
| </warning> | ||
|
|
||
| <section xml:id="ssec-pkgs-appimageTools-formats"> | ||
| <title>AppImage formats</title> | ||
|
|
||
| <para> | ||
| There are different formats for AppImages, see <link xlink:href="https://github.com/AppImage/AppImageSpec/blob/74ad9ca2f94bf864a4a0dac1f369dd4f00bd1c28/draft.md#image-format">the specification</link> for details. | ||
| </para> | ||
|
|
||
| <itemizedlist> | ||
| <listitem> | ||
| <para> | ||
| Type 1 images are ISO 9660 files that are also ELF executables. | ||
| </para> | ||
| </listitem> | ||
| <listitem> | ||
| <para> | ||
| Type 2 images are ELF executables with an appended filesystem. | ||
| </para> | ||
| </listitem> | ||
| </itemizedlist> | ||
|
|
||
| <para> | ||
| They can be told apart with <command>file -k</command>: | ||
| </para> | ||
|
|
||
| <screen> | ||
| <prompt>$ </prompt>file -k type1.AppImage | ||
| type1.AppImage: ELF 64-bit LSB executable, x86-64, version 1 (SYSV) ISO 9660 CD-ROM filesystem data 'AppImage' (Lepton 3.x), scale 0-0, | ||
| spot sensor temperature 0.000000, unit celsius, color scheme 0, calibration: offset 0.000000, slope 0.000000, dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.18, BuildID[sha1]=d629f6099d2344ad82818172add1d38c5e11bc6d, stripped\012- data | ||
|
|
||
| <prompt>$ </prompt>file -k type2.AppImage | ||
| type2.AppImage: ELF 64-bit LSB executable, x86-64, version 1 (SYSV) (Lepton 3.x), scale 232-60668, spot sensor temperature -4.187500, color scheme 15, show scale bar, calibration: offset -0.000000, slope 0.000000 (Lepton 2.x), scale 4111-45000, spot sensor temperature 412442.250000, color scheme 3, minimum point enabled, calibration: offset -75402534979642766821519867692934234112.000000, slope 5815371847733706829839455140374904832.000000, dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.18, BuildID[sha1]=79dcc4e55a61c293c5e19edbd8d65b202842579f, stripped\012- data | ||
| </screen> | ||
|
|
||
| <para> | ||
| Note how the type 1 AppImage is described as an <literal>ISO 9660 CD-ROM filesystem</literal>, and the type 2 AppImage is not. | ||
| </para> | ||
| </section> | ||
|
|
||
| <section xml:id="ssec-pkgs-appimageTools-wrapping"> | ||
| <title>Wrapping</title> | ||
|
|
||
| <para> | ||
| Depending on the type of AppImage you're wrapping, you'll have to use <varname>wrapType1</varname> or <varname>wrapType2</varname>. | ||
| </para> | ||
|
|
||
| <programlisting> | ||
| appimageTools.wrapType2 { # or wrapType1 | ||
| name = "patchwork"; <co xml:id='ex-appimageTools-wrapping-1' /> | ||
| src = fetchurl { <co xml:id='ex-appimageTools-wrapping-2' /> | ||
| url = https://github.com/ssbc/patchwork/releases/download/v3.11.4/Patchwork-3.11.4-linux-x86_64.AppImage; | ||
| sha256 = "1blsprpkvm0ws9b96gb36f0rbf8f5jgmw4x6dsb1kswr4ysf591s"; | ||
| }; | ||
| extraPkgs = pkgs: with pkgs; [ ]; <co xml:id='ex-appimageTools-wrapping-3' /> | ||
| }</programlisting> | ||
|
|
||
| <calloutlist> | ||
| <callout arearefs='ex-appimageTools-wrapping-1'> | ||
| <para> | ||
| <varname>name</varname> specifies the name of the resulting image. | ||
| </para> | ||
| </callout> | ||
| <callout arearefs='ex-appimageTools-wrapping-2'> | ||
| <para> | ||
| <varname>src</varname> specifies the AppImage file to extract. | ||
| </para> | ||
| </callout> | ||
| <callout arearefs='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: | ||
| <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>. | ||
| </para> | ||
| </listitem> | ||
| <listitem> | ||
| <para> | ||
| Running <command>strace -vfefile</command> on the wrapped executable, looking for libraries that can't be found. | ||
| </para> | ||
| </listitem> | ||
| </itemizedlist> | ||
| </para> | ||
| </callout> | ||
| </calloutlist> | ||
| </section> | ||
| </section> |
Oops, something went wrong.