tjh.dev
1<chapter xmlns="http://docbook.org/ns/docbook"
2 xmlns:xlink="http://www.w3.org/1999/xlink"
3 xml:id="chap-package-notes">
4 <title>Package Notes</title>
5 <para>
6 This chapter contains information about how to use and maintain the Nix
7 expressions for a number of specific packages, such as the Linux kernel or
8 X.org.
9 </para>
10<!--============================================================-->
11 <section xml:id="sec-linux-kernel">
12 <title>Linux kernel</title>
13
14 <para>
15 The Nix expressions to build the Linux kernel are in
16 <link
17xlink:href="https://github.com/NixOS/nixpkgs/blob/master/pkgs/os-specific/linux/kernel"><filename>pkgs/os-specific/linux/kernel</filename></link>.
18 </para>
19
20 <para>
21 The function that builds the kernel has an argument
22 <varname>kernelPatches</varname> which should be a list of <literal>{name,
23 patch, extraConfig}</literal> attribute sets, where <varname>name</varname>
24 is the name of the patch (which is included in the kernel’s
25 <varname>meta.description</varname> attribute), <varname>patch</varname> is
26 the patch itself (possibly compressed), and <varname>extraConfig</varname>
27 (optional) is a string specifying extra options to be concatenated to the
28 kernel configuration file (<filename>.config</filename>).
29 </para>
30
31 <para>
32 The kernel derivation exports an attribute <varname>features</varname>
33 specifying whether optional functionality is or isn’t enabled. This is
34 used in NixOS to implement kernel-specific behaviour. For instance, if the
35 kernel has the <varname>iwlwifi</varname> feature (i.e. has built-in support
36 for Intel wireless chipsets), then NixOS doesn’t have to build the
37 external <varname>iwlwifi</varname> package:
38<programlisting>
39modulesTree = [kernel]
40 ++ pkgs.lib.optional (!kernel.features ? iwlwifi) kernelPackages.iwlwifi
41 ++ ...;
42</programlisting>
43 </para>
44
45 <para>
46 How to add a new (major) version of the Linux kernel to Nixpkgs:
47 <orderedlist>
48 <listitem>
49 <para>
50 Copy the old Nix expression (e.g. <filename>linux-2.6.21.nix</filename>)
51 to the new one (e.g. <filename>linux-2.6.22.nix</filename>) and update
52 it.
53 </para>
54 </listitem>
55 <listitem>
56 <para>
57 Add the new kernel to <filename>all-packages.nix</filename> (e.g., create
58 an attribute <varname>kernel_2_6_22</varname>).
59 </para>
60 </listitem>
61 <listitem>
62 <para>
63 Now we’re going to update the kernel configuration. First unpack the
64 kernel. Then for each supported platform (<literal>i686</literal>,
65 <literal>x86_64</literal>, <literal>uml</literal>) do the following:
66 <orderedlist>
67 <listitem>
68 <para>
69 Make an copy from the old config (e.g.
70 <filename>config-2.6.21-i686-smp</filename>) to the new one (e.g.
71 <filename>config-2.6.22-i686-smp</filename>).
72 </para>
73 </listitem>
74 <listitem>
75 <para>
76 Copy the config file for this platform (e.g.
77 <filename>config-2.6.22-i686-smp</filename>) to
78 <filename>.config</filename> in the kernel source tree.
79 </para>
80 </listitem>
81 <listitem>
82 <para>
83 Run <literal>make oldconfig
84 ARCH=<replaceable>{i386,x86_64,um}</replaceable></literal> and answer
85 all questions. (For the uml configuration, also add
86 <literal>SHELL=bash</literal>.) Make sure to keep the configuration
87 consistent between platforms (i.e. don’t enable some feature on
88 <literal>i686</literal> and disable it on <literal>x86_64</literal>).
89 </para>
90 </listitem>
91 <listitem>
92 <para>
93 If needed you can also run <literal>make menuconfig</literal>:
94<screen>
95$ nix-env -i ncurses
96$ export NIX_CFLAGS_LINK=-lncurses
97$ make menuconfig ARCH=<replaceable>arch</replaceable></screen>
98 </para>
99 </listitem>
100 <listitem>
101 <para>
102 Copy <filename>.config</filename> over the new config file (e.g.
103 <filename>config-2.6.22-i686-smp</filename>).
104 </para>
105 </listitem>
106 </orderedlist>
107 </para>
108 </listitem>
109 <listitem>
110 <para>
111 Test building the kernel: <literal>nix-build -A kernel_2_6_22</literal>.
112 If it compiles, ship it! For extra credit, try booting NixOS with it.
113 </para>
114 </listitem>
115 <listitem>
116 <para>
117 It may be that the new kernel requires updating the external kernel
118 modules and kernel-dependent packages listed in the
119 <varname>linuxPackagesFor</varname> function in
120 <filename>all-packages.nix</filename> (such as the NVIDIA drivers, AUFS,
121 etc.). If the updated packages aren’t backwards compatible with older
122 kernels, you may need to keep the older versions around.
123 </para>
124 </listitem>
125 </orderedlist>
126 </para>
127 </section>
128<!--============================================================-->
129 <section xml:id="sec-xorg">
130 <title>X.org</title>
131
132 <para>
133 The Nix expressions for the X.org packages reside in
134 <filename>pkgs/servers/x11/xorg/default.nix</filename>. This file is
135 automatically generated from lists of tarballs in an X.org release. As such
136 it should not be modified directly; rather, you should modify the lists, the
137 generator script or the file
138 <filename>pkgs/servers/x11/xorg/overrides.nix</filename>, in which you can
139 override or add to the derivations produced by the generator.
140 </para>
141
142 <para>
143 The generator is invoked as follows:
144<screen>
145$ cd pkgs/servers/x11/xorg
146$ cat tarballs-7.5.list extra.list old.list \
147 | perl ./generate-expr-from-tarballs.pl
148</screen>
149 For each of the tarballs in the <filename>.list</filename> files, the script
150 downloads it, unpacks it, and searches its <filename>configure.ac</filename>
151 and <filename>*.pc.in</filename> files for dependencies. This information is
152 used to generate <filename>default.nix</filename>. The generator caches
153 downloaded tarballs between runs. Pay close attention to the <literal>NOT
154 FOUND: <replaceable>name</replaceable></literal> messages at the end of the
155 run, since they may indicate missing dependencies. (Some might be optional
156 dependencies, however.)
157 </para>
158
159 <para>
160 A file like <filename>tarballs-7.5.list</filename> contains all tarballs in
161 a X.org release. It can be generated like this:
162<screen>
163$ export i="mirror://xorg/X11R7.4/src/everything/"
164$ cat $(PRINT_PATH=1 nix-prefetch-url $i | tail -n 1) \
165 | perl -e 'while (<>) { if (/(href|HREF)="([^"]*.bz2)"/) { print "$ENV{'i'}$2\n"; }; }' \
166 | sort > tarballs-7.4.list
167</screen>
168 <filename>extra.list</filename> contains libraries that aren’t part of
169 X.org proper, but are closely related to it, such as
170 <literal>libxcb</literal>. <filename>old.list</filename> contains some
171 packages that were removed from X.org, but are still needed by some people
172 or by other packages (such as <varname>imake</varname>).
173 </para>
174
175 <para>
176 If the expression for a package requires derivation attributes that the
177 generator cannot figure out automatically (say, <varname>patches</varname>
178 or a <varname>postInstall</varname> hook), you should modify
179 <filename>pkgs/servers/x11/xorg/overrides.nix</filename>.
180 </para>
181 </section>
182<!--============================================================-->
183<!--
184<section xml:id="sec-package-notes-gnome">
185 <title>Gnome</title>
186 <para>* Expression is auto-generated</para>
187 <para>* How to update</para>
188</section>
189-->
190<!--============================================================-->
191<!--
192<section xml:id="sec-package-notes-gcc">
193 <title>GCC</title>
194 <para>…</para>
195</section>
196-->
197<!--============================================================-->
198 <section xml:id="sec-eclipse">
199 <title>Eclipse</title>
200
201 <para>
202 The Nix expressions related to the Eclipse platform and IDE are in
203 <link xlink:href="https://github.com/NixOS/nixpkgs/blob/master/pkgs/applications/editors/eclipse"><filename>pkgs/applications/editors/eclipse</filename></link>.
204 </para>
205
206 <para>
207 Nixpkgs provides a number of packages that will install Eclipse in its
208 various forms. These range from the bare-bones Eclipse Platform to the more
209 fully featured Eclipse SDK or Scala-IDE packages and multiple version are
210 often available. It is possible to list available Eclipse packages by
211 issuing the command:
212<screen>
213$ nix-env -f '<nixpkgs>' -qaP -A eclipses --description
214</screen>
215 Once an Eclipse variant is installed it can be run using the
216 <command>eclipse</command> command, as expected. From within Eclipse it is
217 then possible to install plugins in the usual manner by either manually
218 specifying an Eclipse update site or by installing the Marketplace Client
219 plugin and using it to discover and install other plugins. This installation
220 method provides an Eclipse installation that closely resemble a manually
221 installed Eclipse.
222 </para>
223
224 <para>
225 If you prefer to install plugins in a more declarative manner then Nixpkgs
226 also offer a number of Eclipse plugins that can be installed in an
227 <emphasis>Eclipse environment</emphasis>. This type of environment is
228 created using the function <varname>eclipseWithPlugins</varname> found
229 inside the <varname>nixpkgs.eclipses</varname> attribute set. This function
230 takes as argument <literal>{ eclipse, plugins ? [], jvmArgs ? [] }</literal>
231 where <varname>eclipse</varname> is a one of the Eclipse packages described
232 above, <varname>plugins</varname> is a list of plugin derivations, and
233 <varname>jvmArgs</varname> is a list of arguments given to the JVM running
234 the Eclipse. For example, say you wish to install the latest Eclipse
235 Platform with the popular Eclipse Color Theme plugin and also allow Eclipse
236 to use more RAM. You could then add
237<screen>
238packageOverrides = pkgs: {
239 myEclipse = with pkgs.eclipses; eclipseWithPlugins {
240 eclipse = eclipse-platform;
241 jvmArgs = [ "-Xmx2048m" ];
242 plugins = [ plugins.color-theme ];
243 };
244}
245</screen>
246 to your Nixpkgs configuration
247 (<filename>~/.config/nixpkgs/config.nix</filename>) and install it by
248 running <command>nix-env -f '<nixpkgs>' -iA myEclipse</command> and
249 afterward run Eclipse as usual. It is possible to find out which plugins are
250 available for installation using <varname>eclipseWithPlugins</varname> by
251 running
252<screen>
253$ nix-env -f '<nixpkgs>' -qaP -A eclipses.plugins --description
254</screen>
255 </para>
256
257 <para>
258 If there is a need to install plugins that are not available in Nixpkgs then
259 it may be possible to define these plugins outside Nixpkgs using the
260 <varname>buildEclipseUpdateSite</varname> and
261 <varname>buildEclipsePlugin</varname> functions found in the
262 <varname>nixpkgs.eclipses.plugins</varname> attribute set. Use the
263 <varname>buildEclipseUpdateSite</varname> function to install a plugin
264 distributed as an Eclipse update site. This function takes <literal>{ name,
265 src }</literal> as argument where <literal>src</literal> indicates the
266 Eclipse update site archive. All Eclipse features and plugins within the
267 downloaded update site will be installed. When an update site archive is not
268 available then the <varname>buildEclipsePlugin</varname> function can be
269 used to install a plugin that consists of a pair of feature and plugin JARs.
270 This function takes an argument <literal>{ name, srcFeature, srcPlugin
271 }</literal> where <literal>srcFeature</literal> and
272 <literal>srcPlugin</literal> are the feature and plugin JARs, respectively.
273 </para>
274
275 <para>
276 Expanding the previous example with two plugins using the above functions we
277 have
278<screen>
279packageOverrides = pkgs: {
280 myEclipse = with pkgs.eclipses; eclipseWithPlugins {
281 eclipse = eclipse-platform;
282 jvmArgs = [ "-Xmx2048m" ];
283 plugins = [
284 plugins.color-theme
285 (plugins.buildEclipsePlugin {
286 name = "myplugin1-1.0";
287 srcFeature = fetchurl {
288 url = "http://…/features/myplugin1.jar";
289 sha256 = "123…";
290 };
291 srcPlugin = fetchurl {
292 url = "http://…/plugins/myplugin1.jar";
293 sha256 = "123…";
294 };
295 });
296 (plugins.buildEclipseUpdateSite {
297 name = "myplugin2-1.0";
298 src = fetchurl {
299 stripRoot = false;
300 url = "http://…/myplugin2.zip";
301 sha256 = "123…";
302 };
303 });
304 ];
305 };
306}
307</screen>
308 </para>
309 </section>
310
311 <section xml:id="sec-elm">
312 <title>Elm</title>
313
314 <para>
315 To update Elm compiler, see <filename>nixpkgs/pkgs/development/compilers/elm/README.md</filename>.
316 </para>
317
318 <para>
319 To package Elm applications, <link xlink:href="https://github.com/hercules-ci/elm2nix#elm2nix">read about elm2nix</link>.
320 </para>
321 </section>
322
323 <section xml:id="sec-shell-helpers">
324 <title>Interactive shell helpers</title>
325
326 <para>
327 Some packages provide the shell integration to be more useful. But unlike
328 other systems, nix doesn't have a standard share directory location. This is
329 why a bunch <command>PACKAGE-share</command> scripts are shipped that print
330 the location of the corresponding shared folder. Current list of such
331 packages is as following:
332 <itemizedlist>
333 <listitem>
334 <para>
335 <literal>autojump</literal>: <command>autojump-share</command>
336 </para>
337 </listitem>
338 <listitem>
339 <para>
340 <literal>fzf</literal>: <command>fzf-share</command>
341 </para>
342 </listitem>
343 </itemizedlist>
344 E.g. <literal>autojump</literal> can then used in the .bashrc like this:
345<screen>
346 source "$(autojump-share)/autojump.bash"
347</screen>
348 </para>
349 </section>
350 <section xml:id="sec-steam">
351 <title>Steam</title>
352
353 <section xml:id="sec-steam-nix">
354 <title>Steam in Nix</title>
355
356 <para>
357 Steam is distributed as a <filename>.deb</filename> file, for now only as
358 an i686 package (the amd64 package only has documentation). When unpacked,
359 it has a script called <filename>steam</filename> that in ubuntu (their
360 target distro) would go to <filename>/usr/bin </filename>. When run for the
361 first time, this script copies some files to the user's home, which include
362 another script that is the ultimate responsible for launching the steam
363 binary, which is also in $HOME.
364 </para>
365
366 <para>
367 Nix problems and constraints:
368 <itemizedlist>
369 <listitem>
370 <para>
371 We don't have <filename>/bin/bash</filename> and many scripts point
372 there. Similarly for <filename>/usr/bin/python</filename> .
373 </para>
374 </listitem>
375 <listitem>
376 <para>
377 We don't have the dynamic loader in <filename>/lib </filename>.
378 </para>
379 </listitem>
380 <listitem>
381 <para>
382 The <filename>steam.sh</filename> script in $HOME can not be patched, as
383 it is checked and rewritten by steam.
384 </para>
385 </listitem>
386 <listitem>
387 <para>
388 The steam binary cannot be patched, it's also checked.
389 </para>
390 </listitem>
391 </itemizedlist>
392 </para>
393
394 <para>
395 The current approach to deploy Steam in NixOS is composing a FHS-compatible
396 chroot environment, as documented
397 <link xlink:href="http://sandervanderburg.blogspot.nl/2013/09/composing-fhs-compatible-chroot.html">here</link>.
398 This allows us to have binaries in the expected paths without disrupting
399 the system, and to avoid patching them to work in a non FHS environment.
400 </para>
401 </section>
402
403 <section xml:id="sec-steam-play">
404 <title>How to play</title>
405
406 <para>
407 For 64-bit systems it's important to have
408<programlisting>hardware.opengl.driSupport32Bit = true;</programlisting>
409 in your <filename>/etc/nixos/configuration.nix</filename>. You'll also need
410<programlisting>hardware.pulseaudio.support32Bit = true;</programlisting>
411 if you are using PulseAudio - this will enable 32bit ALSA apps integration.
412 To use the Steam controller or other Steam supported controllers such as
413 the DualShock 4 or Nintendo Switch Pro, you need to add
414<programlisting>hardware.steam-hardware.enable = true;</programlisting>
415 to your configuration.
416 </para>
417 </section>
418
419 <section xml:id="sec-steam-troub">
420 <title>Troubleshooting</title>
421
422 <para>
423 <variablelist>
424 <varlistentry>
425 <term>
426 Steam fails to start. What do I do?
427 </term>
428 <listitem>
429 <para>
430 Try to run
431<programlisting>strace steam</programlisting>
432 to see what is causing steam to fail.
433 </para>
434 </listitem>
435 </varlistentry>
436 <varlistentry>
437 <term>
438 Using the FOSS Radeon or nouveau (nvidia) drivers
439 </term>
440 <listitem>
441 <itemizedlist>
442 <listitem>
443 <para>
444 The <literal>newStdcpp</literal> parameter was removed since NixOS
445 17.09 and should not be needed anymore.
446 </para>
447 </listitem>
448 <listitem>
449 <para>
450 Steam ships statically linked with a version of libcrypto that
451 conflics with the one dynamically loaded by radeonsi_dri.so. If you
452 get the error
453<programlisting>steam.sh: line 713: 7842 Segmentation fault (core dumped)</programlisting>
454 have a look at
455 <link xlink:href="https://github.com/NixOS/nixpkgs/pull/20269">this
456 pull request</link>.
457 </para>
458 </listitem>
459 </itemizedlist>
460 </listitem>
461 </varlistentry>
462 <varlistentry>
463 <term>
464 Java
465 </term>
466 <listitem>
467 <orderedlist>
468 <listitem>
469 <para>
470 There is no java in steam chrootenv by default. If you get a message
471 like
472<programlisting>/home/foo/.local/share/Steam/SteamApps/common/towns/towns.sh: line 1: java: command not found</programlisting>
473 You need to add
474<programlisting> steam.override { withJava = true; };</programlisting>
475 to your configuration.
476 </para>
477 </listitem>
478 </orderedlist>
479 </listitem>
480 </varlistentry>
481 </variablelist>
482 </para>
483 </section>
484
485 <section xml:id="sec-steam-run">
486 <title>steam-run</title>
487
488 <para>
489 The FHS-compatible chroot used for steam can also be used to run other
490 linux games that expect a FHS environment. To do it, add
491<programlisting>pkgs.(steam.override {
492 nativeOnly = true;
493 newStdcpp = true;
494 }).run</programlisting>
495 to your configuration, rebuild, and run the game with
496<programlisting>steam-run ./foo</programlisting>
497 </para>
498 </section>
499 </section>
500 <section xml:id="sec-emacs">
501 <title>Emacs</title>
502
503 <section xml:id="sec-emacs-config">
504 <title>Configuring Emacs</title>
505
506 <para>
507 The Emacs package comes with some extra helpers to make it easier to
508 configure. <varname>emacsWithPackages</varname> allows you to manage
509 packages from ELPA. This means that you will not have to install that
510 packages from within Emacs. For instance, if you wanted to use
511 <literal>company</literal>, <literal>counsel</literal>,
512 <literal>flycheck</literal>, <literal>ivy</literal>,
513 <literal>magit</literal>, <literal>projectile</literal>, and
514 <literal>use-package</literal> you could use this as a
515 <filename>~/.config/nixpkgs/config.nix</filename> override:
516 </para>
517
518<screen>
519{
520 packageOverrides = pkgs: with pkgs; {
521 myEmacs = emacsWithPackages (epkgs: (with epkgs.melpaStablePackages; [
522 company
523 counsel
524 flycheck
525 ivy
526 magit
527 projectile
528 use-package
529 ]));
530 }
531}
532</screen>
533
534 <para>
535 You can install it like any other packages via <command>nix-env -iA
536 myEmacs</command>. However, this will only install those packages. It will
537 not <literal>configure</literal> them for us. To do this, we need to
538 provide a configuration file. Luckily, it is possible to do this from
539 within Nix! By modifying the above example, we can make Emacs load a custom
540 config file. The key is to create a package that provide a
541 <filename>default.el</filename> file in
542 <filename>/share/emacs/site-start/</filename>. Emacs knows to load this
543 file automatically when it starts.
544 </para>
545
546<screen>
547{
548 packageOverrides = pkgs: with pkgs; rec {
549 myEmacsConfig = writeText "default.el" ''
550;; initialize package
551
552(require 'package)
553(package-initialize 'noactivate)
554(eval-when-compile
555 (require 'use-package))
556
557;; load some packages
558
559(use-package company
560 :bind ("<C-tab>" . company-complete)
561 :diminish company-mode
562 :commands (company-mode global-company-mode)
563 :defer 1
564 :config
565 (global-company-mode))
566
567(use-package counsel
568 :commands (counsel-descbinds)
569 :bind (([remap execute-extended-command] . counsel-M-x)
570 ("C-x C-f" . counsel-find-file)
571 ("C-c g" . counsel-git)
572 ("C-c j" . counsel-git-grep)
573 ("C-c k" . counsel-ag)
574 ("C-x l" . counsel-locate)
575 ("M-y" . counsel-yank-pop)))
576
577(use-package flycheck
578 :defer 2
579 :config (global-flycheck-mode))
580
581(use-package ivy
582 :defer 1
583 :bind (("C-c C-r" . ivy-resume)
584 ("C-x C-b" . ivy-switch-buffer)
585 :map ivy-minibuffer-map
586 ("C-j" . ivy-call))
587 :diminish ivy-mode
588 :commands ivy-mode
589 :config
590 (ivy-mode 1))
591
592(use-package magit
593 :defer
594 :if (executable-find "git")
595 :bind (("C-x g" . magit-status)
596 ("C-x G" . magit-dispatch-popup))
597 :init
598 (setq magit-completing-read-function 'ivy-completing-read))
599
600(use-package projectile
601 :commands projectile-mode
602 :bind-keymap ("C-c p" . projectile-command-map)
603 :defer 5
604 :config
605 (projectile-global-mode))
606 '';
607 myEmacs = emacsWithPackages (epkgs: (with epkgs.melpaStablePackages; [
608 (runCommand "default.el" {} ''
609mkdir -p $out/share/emacs/site-lisp
610cp ${myEmacsConfig} $out/share/emacs/site-lisp/default.el
611'')
612 company
613 counsel
614 flycheck
615 ivy
616 magit
617 projectile
618 use-package
619 ]));
620 };
621}
622</screen>
623
624 <para>
625 This provides a fairly full Emacs start file. It will load in addition to
626 the user's presonal config. You can always disable it by passing
627 <command>-q</command> to the Emacs command.
628 </para>
629
630 <para>
631 Sometimes <varname>emacsWithPackages</varname> is not enough, as this
632 package set has some priorities imposed on packages (with the lowest
633 priority assigned to Melpa Unstable, and the highest for packages manually
634 defined in <filename>pkgs/top-level/emacs-packages.nix</filename>). But you
635 can't control this priorities when some package is installed as a
636 dependency. You can override it on per-package-basis, providing all the
637 required dependencies manually - but it's tedious and there is always a
638 possibility that an unwanted dependency will sneak in through some other
639 package. To completely override such a package you can use
640 <varname>overrideScope'</varname>.
641 </para>
642
643<screen>
644overrides = self: super: rec {
645 haskell-mode = self.melpaPackages.haskell-mode;
646 ...
647};
648((emacsPackagesNgGen emacs).overrideScope' overrides).emacsWithPackages (p: with p; [
649 # here both these package will use haskell-mode of our own choice
650 ghc-mod
651 dante
652])
653</screen>
654 </section>
655 </section>
656 <section xml:id="sec-weechat">
657 <title>Weechat</title>
658
659 <para>
660 Weechat can be configured to include your choice of plugins, reducing its
661 closure size from the default configuration which includes all available
662 plugins. To make use of this functionality, install an expression that
663 overrides its configuration such as
664<programlisting>weechat.override {configure = {availablePlugins, ...}: {
665 plugins = with availablePlugins; [ python perl ];
666 }
667}</programlisting>
668 If the <literal>configure</literal> function returns an attrset without the
669 <literal>plugins</literal> attribute, <literal>availablePlugins</literal>
670 will be used automatically.
671 </para>
672
673 <para>
674 The plugins currently available are <literal>python</literal>,
675 <literal>perl</literal>, <literal>ruby</literal>, <literal>guile</literal>,
676 <literal>tcl</literal> and <literal>lua</literal>.
677 </para>
678
679 <para>
680 The python and perl plugins allows the addition of extra libraries. For
681 instance, the <literal>inotify.py</literal> script in weechat-scripts
682 requires D-Bus or libnotify, and the <literal>fish.py</literal> script
683 requires pycrypto. To use these scripts, use the plugin's
684 <literal>withPackages</literal> attribute:
685<programlisting>weechat.override { configure = {availablePlugins, ...}: {
686 plugins = with availablePlugins; [
687 (python.withPackages (ps: with ps; [ pycrypto python-dbus ]))
688 ];
689 };
690}
691</programlisting>
692 </para>
693
694 <para>
695 In order to also keep all default plugins installed, it is possible to use
696 the following method:
697<programlisting>weechat.override { configure = { availablePlugins, ... }: {
698 plugins = builtins.attrValues (availablePlugins // {
699 python = availablePlugins.python.withPackages (ps: with ps; [ pycrypto python-dbus ]);
700 });
701}; }
702</programlisting>
703 </para>
704
705 <para>
706 WeeChat allows to set defaults on startup using the
707 <literal>--run-command</literal>. The <literal>configure</literal> method
708 can be used to pass commands to the program:
709<programlisting>weechat.override {
710 configure = { availablePlugins, ... }: {
711 init = ''
712 /set foo bar
713 /server add freenode chat.freenode.org
714 '';
715 };
716}</programlisting>
717 Further values can be added to the list of commands when running
718 <literal>weechat --run-command "your-commands"</literal>.
719 </para>
720
721 <para>
722 Additionally it's possible to specify scripts to be loaded when starting
723 <literal>weechat</literal>. These will be loaded before the commands from
724 <literal>init</literal>:
725<programlisting>weechat.override {
726 configure = { availablePlugins, ... }: {
727 scripts = with pkgs.weechatScripts; [
728 weechat-xmpp weechat-matrix-bridge wee-slack
729 ];
730 init = ''
731 /set plugins.var.python.jabber.key "val"
732 '':
733 };
734}</programlisting>
735 </para>
736
737 <para>
738 In <literal>nixpkgs</literal> there's a subpackage which contains
739 derivations for WeeChat scripts. Such derivations expect a
740 <literal>passthru.scripts</literal> attribute which contains a list of all
741 scripts inside the store path. Furthermore all scripts have to live in
742 <literal>$out/share</literal>. An exemplary derivation looks like this:
743<programlisting>{ stdenv, fetchurl }:
744
745stdenv.mkDerivation {
746 name = "exemplary-weechat-script";
747 src = fetchurl {
748 url = "https://scripts.tld/your-scripts.tar.gz";
749 sha256 = "...";
750 };
751 passthru.scripts = [ "foo.py" "bar.lua" ];
752 installPhase = ''
753 mkdir $out/share
754 cp foo.py $out/share
755 cp bar.lua $out/share
756 '';
757}</programlisting>
758 </para>
759 </section>
760 <section xml:id="sec-citrix">
761 <title>Citrix Receiver</title>
762
763 <para>
764 The <link xlink:href="https://www.citrix.com/products/receiver/">Citrix
765 Receiver</link> is a remote desktop viewer which provides access to
766 <link xlink:href="https://www.citrix.com/products/xenapp-xendesktop/">XenDesktop</link>
767 installations.
768 </para>
769
770 <section xml:id="sec-citrix-base">
771 <title>Basic usage</title>
772
773 <para>
774 The tarball archive needs to be downloaded manually as the licenses
775 agreements of the vendor need to be accepted first. This is available at
776 the
777 <link xlink:href="https://www.citrix.com/downloads/citrix-receiver/">download
778 page at citrix.com</link>. Then run <literal>nix-prefetch-url
779 file://$PWD/linuxx64-$version.tar.gz</literal>. With the archive available
780 in the store the package can be built and installed with Nix.
781 </para>
782
783 <para>
784 <emphasis>Note: it's recommended to install <literal>Citrix
785 Receiver</literal> using <literal>nix-env -i</literal> or globally to
786 ensure that the <literal>.desktop</literal> files are installed properly
787 into <literal>$XDG_CONFIG_DIRS</literal>. Otherwise it won't be possible to
788 open <literal>.ica</literal> files automatically from the browser to start
789 a Citrix connection.</emphasis>
790 </para>
791 </section>
792
793 <section xml:id="sec-citrix-custom-certs">
794 <title>Custom certificates</title>
795
796 <para>
797 The <literal>Citrix Receiver</literal> in <literal>nixpkgs</literal> trusts
798 several certificates
799 <link xlink:href="https://curl.haxx.se/docs/caextract.html">from the
800 Mozilla database</link> by default. However several companies using Citrix
801 might require their own corporate certificate. On distros with imperative
802 packaging these certs can be stored easily in
803 <link xlink:href="https://developer-docs.citrix.com/projects/receiver-for-linux-command-reference/en/13.7/"><literal>$ICAROOT</literal></link>,
804 however this directory is a store path in <literal>nixpkgs</literal>. In
805 order to work around this issue the package provides a simple mechanism to
806 add custom certificates without rebuilding the entire package using
807 <literal>symlinkJoin</literal>:
808<programlisting>
809<![CDATA[with import <nixpkgs> { config.allowUnfree = true; };
810let extraCerts = [ ./custom-cert-1.pem ./custom-cert-2.pem /* ... */ ]; in
811citrix_receiver.override {
812 inherit extraCerts;
813}]]>
814</programlisting>
815 </para>
816 </section>
817 </section>
818 <section xml:id="sec-ibus-typing-booster">
819 <title>ibus-engines.typing-booster</title>
820
821 <para>
822 This package is an ibus-based completion method to speed up typing.
823 </para>
824
825 <section xml:id="sec-ibus-typing-booster-activate">
826 <title>Activating the engine</title>
827
828 <para>
829 IBus needs to be configured accordingly to activate
830 <literal>typing-booster</literal>. The configuration depends on the desktop
831 manager in use. For detailed instructions, please refer to the
832 <link xlink:href="https://mike-fabian.github.io/ibus-typing-booster/documentation.html">upstream
833 docs</link>.
834 </para>
835
836 <para>
837 On NixOS you need to explicitly enable <literal>ibus</literal> with given
838 engines before customizing your desktop to use
839 <literal>typing-booster</literal>. This can be achieved using the
840 <literal>ibus</literal> module:
841<programlisting>{ pkgs, ... }: {
842 i18n.inputMethod = {
843 enabled = "ibus";
844 ibus.engines = with pkgs.ibus-engines; [ typing-booster ];
845 };
846}</programlisting>
847 </para>
848 </section>
849
850 <section xml:id="sec-ibus-typing-booster-customize-hunspell">
851 <title>Using custom hunspell dictionaries</title>
852
853 <para>
854 The IBus engine is based on <literal>hunspell</literal> to support
855 completion in many languages. By default the dictionaries
856 <literal>de-de</literal>, <literal>en-us</literal>,
857 <literal>es-es</literal>, <literal>it-it</literal>,
858 <literal>sv-se</literal> and <literal>sv-fi</literal> are in use. To add
859 another dictionary, the package can be overridden like this:
860<programlisting>ibus-engines.typing-booster.override {
861 langs = [ "de-at" "en-gb" ];
862}</programlisting>
863 </para>
864
865 <para>
866 <emphasis>Note: each language passed to <literal>langs</literal> must be an
867 attribute name in <literal>pkgs.hunspellDicts</literal>.</emphasis>
868 </para>
869 </section>
870
871 <section xml:id="sec-ibus-typing-booster-emoji-picker">
872 <title>Built-in emoji picker</title>
873
874 <para>
875 The <literal>ibus-engines.typing-booster</literal> package contains a
876 program named <literal>emoji-picker</literal>. To display all emojis
877 correctly, a special font such as <literal>noto-fonts-emoji</literal> is
878 needed:
879 </para>
880
881 <para>
882 On NixOS it can be installed using the following expression:
883<programlisting>{ pkgs, ... }: {
884 fonts.fonts = with pkgs; [ noto-fonts-emoji ];
885}</programlisting>
886 </para>
887 </section>
888 </section>
889 <section xml:id="dlib">
890 <title>DLib</title>
891
892 <para>
893 <link xlink:href="http://dlib.net/">DLib</link> is a modern, C++-based toolkit which
894 provides several machine learning algorithms.
895 </para>
896
897 <section xml:id="compiling-without-avx-support">
898 <title>Compiling without AVX support</title>
899
900 <para>
901 Especially older CPUs don't support
902 <link xlink:href="https://en.wikipedia.org/wiki/Advanced_Vector_Extensions">AVX</link>
903 (<abbrev>Advanced Vector Extensions</abbrev>) instructions that are used by DLib to
904 optimize their algorithms.
905 </para>
906
907 <para>
908 On the affected hardware errors like <literal>Illegal instruction</literal> will occur.
909 In those cases AVX support needs to be disabled:
910<programlisting>self: super: {
911 dlib = super.dlib.override { avxSupport = false; };
912}</programlisting>
913 </para>
914 </section>
915 </section>
916</chapter>