rl-2211.section.xml

<section xmlns="http://docbook.org/ns/docbook" xmlns:xlink="http://www.w3.org/1999/xlink" xml:id="sec-release-22.11">
  <title>Release 22.11 (“Raccoon”, 2022.11/??)</title>
  <para>
    Support is planned until the end of June 2023, handing over to
    23.05.
  </para>
  <section xml:id="sec-release-22.11-highlights">
    <title>Highlights</title>
    <para>
      In addition to numerous new and upgraded packages, this release
      has the following highlights:
    </para>
    <itemizedlist>
      <listitem>
        <para>
          During cross-compilation, tests are now executed if the test
          suite can be executed by the build platform. This is the case
          when doing “native” cross-compilation where the build and host
          platforms are largely the same, but the nixpkgs’ cross
          compilation infrastructure is used, e.g.
          <literal>pkgsStatic</literal> and <literal>pkgsLLVM</literal>.
          Another possibility is that the build platform is a superset
          of the host platform, e.g. when cross-compiling from
          <literal>x86_64-unknown-linux</literal> to
          <literal>i686-unknown-linux</literal>. The predicate gating
          test suite execution is the newly added
          <literal>canExecute</literal> predicate: You can e.g. check if
          <literal>stdenv.buildPlatform</literal> can execute binaries
          built for <literal>stdenv.hostPlatform</literal> (i.e.
          produced by <literal>stdenv.cc</literal>) by evaluating
          <literal>stdenv.buildPlatform.canExecute stdenv.hostPlatform</literal>.
        </para>
      </listitem>
      <listitem>
        <para>
          PHP now defaults to PHP 8.1, updated from 8.0.
        </para>
      </listitem>
      <listitem>
        <para>
          The NixOS module system now has a type
          <literal>secretFile</literal> for options which contain the
          path to a file that should remain secret. This is to avoid
          mistakes where one writes
          <literal>services.miniflux.adminCredentialsFile = /etc/secret</literal>
          instead of
          <literal>services.miniflux.adminCredentialsFile = &quot;/etc/secret&quot;;</literal>
          which makes nix copy <literal>/etc/secret</literal> to the
          store where everyone could read it. A number of modules have
          been converted to use it. This is a breaking change visible by
          an error message like this:
        </para>
        <programlisting>
error: A definition for option `services.miniflux.adminCredentialsFile' is not of type `quoted path to a secret file'. Definition values:
     - In `nixos/lib/build-vms.nix': /etc/secret
</programlisting>
        <para>
          To fix the issue you must assess whether leaking
          <literal>/etc/secret</literal> to the store and thus all local
          users is a problem. If it is the case, then add quotes:
          <literal>services.miniflux.adminCredentialsFile = &quot;/etc/secrets&quot;</literal>.
          If you notice this during upgrade, your secret probably has
          already leaked and it may be a good time to change it. If
          leaking this file is acceptable (for example in a NixOS test),
          you can keep the old behavior like this:
          <literal>services.miniflux.adminCredentialsFile = lib.types.secretFile.makeWorldReadable /etc/secret</literal>.
        </para>
      </listitem>
    </itemizedlist>
  </section>
  <section xml:id="sec-release-22.11-new-services">
    <title>New Services</title>
    <itemizedlist spacing="compact">
      <listitem>
        <para>
          <link xlink:href="https://github.com/jollheef/appvm">appvm</link>,
          Nix based app VMs. Available as
          <link xlink:href="options.html#opt-virtualisation.appvm.enable">virtualisation.appvm</link>.
        </para>
      </listitem>
    </itemizedlist>
  </section>
  <section xml:id="sec-release-22.11-incompatibilities">
    <title>Backward Incompatibilities</title>
    <itemizedlist>
      <listitem>
        <para>
          The <literal>isCompatible</literal> predicate checking CPU
          compatibility is no longer exposed by the platform sets
          generated using <literal>lib.systems.elaborate</literal>. In
          most cases you will want to use the new
          <literal>canExecute</literal> predicate instead which also
          considers the kernel / syscall interface. It is briefly
          described in the release’s
          <link linkend="sec-release-22.11-highlights">highlights
          section</link>.
          <literal>lib.systems.parse.isCompatible</literal> still
          exists, but has changed semantically: Architectures with
          differing endianness modes are <emphasis>no longer considered
          compatible</emphasis>.
        </para>
      </listitem>
      <listitem>
        <para>
          The <literal>isPowerPC</literal> predicate, found on
          <literal>platform</literal> attrsets
          (<literal>hostPlatform</literal>,
          <literal>buildPlatform</literal>,
          <literal>targetPlatform</literal>, etc) has been removed in
          order to reduce confusion. The predicate was was defined such
          that it matches only the 32-bit big-endian members of the
          POWER/PowerPC family, despite having a name which would imply
          a broader set of systems. If you were using this predicate,
          you can replace <literal>foo.isPowerPC</literal> with
          <literal>(with foo; isPower &amp;&amp; is32bit &amp;&amp; isBigEndian)</literal>.
        </para>
      </listitem>
    </itemizedlist>
  </section>
  <section xml:id="sec-release-22.11-notable-changes">
    <title>Other Notable Changes</title>
    <itemizedlist spacing="compact">
      <listitem>
        <para>
          Please remove this line when you add the first item since
          docbook requires the section to be non-empty
        </para>
      </listitem>
    </itemizedlist>
  </section>
</section>