···55 <para>
66 This chapter describes tools for creating various types of images.
77 </para>
88- <xi:include href="images/appimagetools.xml" />
88+ <xi:include href="images/appimagetools.section.xml" />
99 <xi:include href="images/dockertools.section.xml" />
1010 <xi:include href="images/ocitools.section.xml" />
1111- <xi:include href="images/snaptools.xml" />
1111+ <xi:include href="images/snaptools.section.xml" />
1212</chapter>
+48
doc/builders/images/appimagetools.section.md
···11+# pkgs.appimageTools {#sec-pkgs-appimageTools}
22+33+`pkgs.appimageTools` is a set of functions for extracting and wrapping [AppImage](https://appimage.org/) 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, `pkgs.appimage-run` can be used as well.
44+55+::: warning
66+The `appimageTools` API is unstable and may be subject to backwards-incompatible changes in the future.
77+:::
88+99+## AppImage formats {#ssec-pkgs-appimageTools-formats}
1010+1111+There are different formats for AppImages, see [the specification](https://github.com/AppImage/AppImageSpec/blob/74ad9ca2f94bf864a4a0dac1f369dd4f00bd1c28/draft.md#image-format) for details.
1212+1313+- Type 1 images are ISO 9660 files that are also ELF executables.
1414+- Type 2 images are ELF executables with an appended filesystem.
1515+1616+They can be told apart with `file -k`:
1717+1818+```ShellSession
1919+$ file -k type1.AppImage
2020+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,
2121+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
2222+2323+$ file -k type2.AppImage
2424+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
2525+```
2626+2727+Note how the type 1 AppImage is described as an `ISO 9660 CD-ROM filesystem`, and the type 2 AppImage is not.
2828+2929+## Wrapping {#ssec-pkgs-appimageTools-wrapping}
3030+3131+Depending on the type of AppImage you're wrapping, you'll have to use `wrapType1` or `wrapType2`.
3232+3333+```nix
3434+appimageTools.wrapType2 { # or wrapType1
3535+ name = "patchwork";
3636+ src = fetchurl {
3737+ url = "https://github.com/ssbc/patchwork/releases/download/v3.11.4/Patchwork-3.11.4-linux-x86_64.AppImage";
3838+ sha256 = "1blsprpkvm0ws9b96gb36f0rbf8f5jgmw4x6dsb1kswr4ysf591s";
3939+ };
4040+ extraPkgs = pkgs: with pkgs; [ ];
4141+}
4242+```
4343+4444+- `name` specifies the name of the resulting image.
4545+- `src` specifies the AppImage file to extract.
4646+- `extraPkgs` 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:
4747+ - Looking through the extracted AppImage files, reading its scripts and running `patchelf` and `ldd` on its executables. This can also be done in `appimage-run`, by setting `APPIMAGE_DEBUG_EXEC=bash`.
4848+ - Running `strace -vfefile` on the wrapped executable, looking for libraries that can't be found.
-102
doc/builders/images/appimagetools.xml
···11-<section xmlns="http://docbook.org/ns/docbook"
22- xmlns:xlink="http://www.w3.org/1999/xlink"
33- xmlns:xi="http://www.w3.org/2001/XInclude"
44- xml:id="sec-pkgs-appimageTools">
55- <title>pkgs.appimageTools</title>
66-77- <para>
88- <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.
99- </para>
1010-1111- <warning>
1212- <para>
1313- The <varname>appimageTools</varname> API is unstable and may be subject to backwards-incompatible changes in the future.
1414- </para>
1515- </warning>
1616-1717- <section xml:id="ssec-pkgs-appimageTools-formats">
1818- <title>AppImage formats</title>
1919-2020- <para>
2121- 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.
2222- </para>
2323-2424- <itemizedlist>
2525- <listitem>
2626- <para>
2727- Type 1 images are ISO 9660 files that are also ELF executables.
2828- </para>
2929- </listitem>
3030- <listitem>
3131- <para>
3232- Type 2 images are ELF executables with an appended filesystem.
3333- </para>
3434- </listitem>
3535- </itemizedlist>
3636-3737- <para>
3838- They can be told apart with <command>file -k</command>:
3939- </para>
4040-4141-<screen>
4242-<prompt>$ </prompt>file -k type1.AppImage
4343-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,
4444-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
4545-4646-<prompt>$ </prompt>file -k type2.AppImage
4747-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
4848-</screen>
4949-5050- <para>
5151- Note how the type 1 AppImage is described as an <literal>ISO 9660 CD-ROM filesystem</literal>, and the type 2 AppImage is not.
5252- </para>
5353- </section>
5454-5555- <section xml:id="ssec-pkgs-appimageTools-wrapping">
5656- <title>Wrapping</title>
5757-5858- <para>
5959- Depending on the type of AppImage you're wrapping, you'll have to use <varname>wrapType1</varname> or <varname>wrapType2</varname>.
6060- </para>
6161-6262-<programlisting>
6363-appimageTools.wrapType2 { # or wrapType1
6464- name = "patchwork"; <co xml:id='ex-appimageTools-wrapping-1' />
6565- src = fetchurl { <co xml:id='ex-appimageTools-wrapping-2' />
6666- url = "https://github.com/ssbc/patchwork/releases/download/v3.11.4/Patchwork-3.11.4-linux-x86_64.AppImage";
6767- sha256 = "1blsprpkvm0ws9b96gb36f0rbf8f5jgmw4x6dsb1kswr4ysf591s";
6868- };
6969- extraPkgs = pkgs: with pkgs; [ ]; <co xml:id='ex-appimageTools-wrapping-3' />
7070-}</programlisting>
7171-7272- <calloutlist>
7373- <callout arearefs='ex-appimageTools-wrapping-1'>
7474- <para>
7575- <varname>name</varname> specifies the name of the resulting image.
7676- </para>
7777- </callout>
7878- <callout arearefs='ex-appimageTools-wrapping-2'>
7979- <para>
8080- <varname>src</varname> specifies the AppImage file to extract.
8181- </para>
8282- </callout>
8383- <callout arearefs='ex-appimageTools-wrapping-3'>
8484- <para>
8585- <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:
8686- <itemizedlist>
8787- <listitem>
8888- <para>
8989- 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>.
9090- </para>
9191- </listitem>
9292- <listitem>
9393- <para>
9494- Running <command>strace -vfefile</command> on the wrapped executable, looking for libraries that can't be found.
9595- </para>
9696- </listitem>
9797- </itemizedlist>
9898- </para>
9999- </callout>
100100- </calloutlist>
101101- </section>
102102-</section>
···11+# pkgs.snapTools {#sec-pkgs-snapTools}
22+33+`pkgs.snapTools` is a set of functions for creating Snapcraft images. Snap and Snapcraft is not used to perform these operations.
44+55+## The makeSnap Function {#ssec-pkgs-snapTools-makeSnap-signature}
66+77+`makeSnap` takes a single named argument, `meta`. This argument mirrors [the upstream `snap.yaml` format](https://docs.snapcraft.io/snap-format) exactly.
88+99+The `base` should not be specified, as `makeSnap` will force set it.
1010+1111+Currently, `makeSnap` does not support creating GUI stubs.
1212+1313+## Build a Hello World Snap {#ssec-pkgs-snapTools-build-a-snap-hello}
1414+1515+The following expression packages GNU Hello as a Snapcraft snap.
1616+1717+```{#ex-snapTools-buildSnap-hello .nix}
1818+let
1919+ inherit (import <nixpkgs> { }) snapTools hello;
2020+in snapTools.makeSnap {
2121+ meta = {
2222+ name = "hello";
2323+ summary = hello.meta.description;
2424+ description = hello.meta.longDescription;
2525+ architectures = [ "amd64" ];
2626+ confinement = "strict";
2727+ apps.hello.command = "${hello}/bin/hello";
2828+ };
2929+}
3030+```
3131+3232+`nix-build` this expression and install it with `snap install ./result --dangerous`. `hello` will now be the Snapcraft version of the package.
3333+3434+## Build a Graphical Snap {#ssec-pkgs-snapTools-build-a-snap-firefox}
3535+3636+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.
3737+3838+```{#ex-snapTools-buildSnap-firefox .nix}
3939+let
4040+ inherit (import <nixpkgs> { }) snapTools firefox;
4141+in snapTools.makeSnap {
4242+ meta = {
4343+ name = "nix-example-firefox";
4444+ summary = firefox.meta.description;
4545+ architectures = [ "amd64" ];
4646+ apps.nix-example-firefox = {
4747+ command = "${firefox}/bin/firefox";
4848+ plugs = [
4949+ "pulseaudio"
5050+ "camera"
5151+ "browser-support"
5252+ "avahi-observe"
5353+ "cups-control"
5454+ "desktop"
5555+ "desktop-legacy"
5656+ "gsettings"
5757+ "home"
5858+ "network"
5959+ "mount-observe"
6060+ "removable-media"
6161+ "x11"
6262+ ];
6363+ };
6464+ confinement = "strict";
6565+ };
6666+}
6767+```
6868+6969+`nix-build` this expression and install it with `snap install ./result --dangerous`. `nix-example-firefox` will now be the Snapcraft version of the Firefox package.
7070+7171+The specific meaning behind plugs can be looked up in the [Snapcraft interface documentation](https://docs.snapcraft.io/supported-interfaces).
-59
doc/builders/images/snaptools.xml
···11-<section xmlns="http://docbook.org/ns/docbook"
22- xmlns:xlink="http://www.w3.org/1999/xlink"
33- xmlns:xi="http://www.w3.org/2001/XInclude"
44- xml:id="sec-pkgs-snapTools">
55- <title>pkgs.snapTools</title>
66-77- <para>
88- <varname>pkgs.snapTools</varname> is a set of functions for creating Snapcraft images. Snap and Snapcraft is not used to perform these operations.
99- </para>
1010-1111- <section xml:id="ssec-pkgs-snapTools-makeSnap-signature">
1212- <title>The makeSnap Function</title>
1313-1414- <para>
1515- <function>makeSnap</function> takes a single named argument, <parameter>meta</parameter>. This argument mirrors <link xlink:href="https://docs.snapcraft.io/snap-format">the upstream <filename>snap.yaml</filename> format</link> exactly.
1616- </para>
1717-1818- <para>
1919- The <parameter>base</parameter> should not be specified, as <function>makeSnap</function> will force set it.
2020- </para>
2121-2222- <para>
2323- Currently, <function>makeSnap</function> does not support creating GUI stubs.
2424- </para>
2525- </section>
2626-2727- <section xml:id="ssec-pkgs-snapTools-build-a-snap-hello">
2828- <title>Build a Hello World Snap</title>
2929-3030- <example xml:id="ex-snapTools-buildSnap-hello">
3131- <title>Making a Hello World Snap</title>
3232- <para>
3333- The following expression packages GNU Hello as a Snapcraft snap.
3434- </para>
3535-<programlisting><xi:include href="./snap/example-hello.nix" parse="text" /></programlisting>
3636- <para>
3737- <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.
3838- </para>
3939- </example>
4040- </section>
4141-4242- <section xml:id="ssec-pkgs-snapTools-build-a-snap-firefox">
4343- <title>Build a Hello World Snap</title>
4444-4545- <example xml:id="ex-snapTools-buildSnap-firefox">
4646- <title>Making a Graphical Snap</title>
4747- <para>
4848- 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.
4949- </para>
5050-<programlisting><xi:include href="./snap/example-firefox.nix" parse="text" /></programlisting>
5151- <para>
5252- <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.
5353- </para>
5454- <para>
5555- The specific meaning behind plugs can be looked up in the <link xlink:href="https://docs.snapcraft.io/supported-interfaces">Snapcraft interface documentation</link>.
5656- </para>
5757- </example>
5858- </section>
5959-</section>
···110110 buildPath = "out/${buildType}";
111111 libExecPath = "$out/libexec/${packageName}";
112112113113+ warnObsoleteVersionConditional = min-version: result:
114114+ let ungoogled-version = (importJSON ./upstream-info.json).ungoogled-chromium.version;
115115+ in if versionAtLeast ungoogled-version min-version
116116+ then warn "chromium: ungoogled version ${ungoogled-version} is newer than a conditional bounded at ${min-version}. You can safely delete it."
117117+ result
118118+ else result;
113119 chromiumVersionAtLeast = min-version:
114114- versionAtLeast upstream-info.version min-version;
120120+ let result = versionAtLeast upstream-info.version min-version;
121121+ in warnObsoleteVersionConditional min-version result;
115122 versionRange = min-version: upto-version:
116123 let inherit (upstream-info) version;
117124 result = versionAtLeast version min-version && versionOlder version upto-version;
118118- ungoogled-version = (importJSON ./upstream-info.json).ungoogled-chromium.version;
119119- in if versionAtLeast ungoogled-version upto-version
120120- then warn "chromium: ungoogled version ${ungoogled-version} is newer than a patchset bounded at ${upto-version}. You can safely delete it."
121121- result
122122- else result;
125125+ in warnObsoleteVersionConditional upto-version result;
123126124127 ungoogler = ungoogled-chromium {
125128 inherit (upstream-info.deps.ungoogled-patches) rev sha256;
···162165 patches = [
163166 ./patches/no-build-timestamps.patch # Optional patch to use SOURCE_DATE_EPOCH in compute_build_timestamp.py (should be upstreamed)
164167 ./patches/widevine-79.patch # For bundling Widevine (DRM), might be replaceable via bundle_widevine_cdm=true in gnFlags
165165- # ++ optional (versionRange "68" "72") (githubPatch "<patch>" "0000000000000000000000000000000000000000000000000000000000000000")
166166- ] ++ optional (versionRange "89" "90.0.4402.0") (githubPatch
167167- # To fix the build of chromiumBeta and chromiumDev:
168168- "b5b80df7dafba8cafa4c6c0ba2153dfda467dfc9" # add dependency on opus in webcodecs
169169- "1r4wmwaxz5xbffmj5wspv2xj8s32j9p6jnwimjmalqg3al2ba64x"
170170- ) ++ optional (versionRange "89" "90.0.4422.0") (fetchpatch {
171171- url = "https://raw.githubusercontent.com/archlinux/svntogit-packages/61b0ab526d2aa3c62fa20bb756461ca9a482f6c6/trunk/chromium-fix-libva-redef.patch";
172172- sha256 = "1qj4sn1ngz0p1l1w3346kanr1sqlr3xdzk1f1i86lqa45mhv77ny";
173173- }) ++ optional (chromiumVersionAtLeast "90")
168168+ # Fix the build by adding a missing dependency (s. https://crbug.com/1197837):
174169 ./patches/fix-missing-atspi2-dependency.patch
175175- ++ optionals (chromiumVersionAtLeast "91") [
170170+ ] ++ optionals (chromiumVersionAtLeast "91") [
176171 ./patches/closure_compiler-Use-the-Java-binary-from-the-system.patch
177172 ];
178173···285280 } // optionalAttrs pulseSupport {
286281 use_pulseaudio = true;
287282 link_pulseaudio = true;
288288- } // optionalAttrs (chromiumVersionAtLeast "89") {
289289- rtc_pipewire_version = "0.3"; # TODO: Can be removed once ungoogled-chromium is at M90
290283 # Disable PGO (defaults to 2 since M89) because it fails without additional changes:
291284 # error: Could not read profile ../../chrome/build/pgo_profiles/chrome-linux-master-1610647094-405a32bcf15e5a84949640f99f84a5b9f61e2f2e.profdata: Unsupported instrumentation profile format version
292285 chrome_pgo_phase = 0;
293293- } // optionalAttrs (chromiumVersionAtLeast "90") {
294286 # Disable build with TFLite library because it fails without additional changes:
295287 # ninja: error: '../../chrome/test/data/simple_test.tflite', needed by 'test_data/simple_test.tflite', missing and no known rule to make it
296288 # Note: chrome/test/data/simple_test.tflite is in the Git repository but not in chromium-90.0.4400.8.tar.xz
···6262 "-DBUILD_TESTING:BOOL=${if doCheck then "TRUE" else "FALSE"}"
6363 ] ++ lib.optional doCheck "-DCMAKE_PREFIX_PATH=${gtest.dev}/lib/cmake";
64646565- doCheck = true;
6565+ # macFUSE needs to be installed for the test to succeed on Darwin
6666+ doCheck = !stdenv.isDarwin;
66676768 checkPhase = ''
6869 # Skip CMakeFiles directory and tests depending on fuse (does not work well with sandboxing)