A brief guide to backward-incompatible changes
that are likely to break configurations or workflows

2023-07-13

* a significant re-arrangement of modules and services, which will
probably break any configuration written before this time. For a
detailed explanation, see
https://www.liminix.org/doc/configuration.html#modules

2023-12-10

* configurations (usually) need no longer import modules from
modules/outputs because devices are expected to do this instead. This
change is because the outputs that make sense in any given context are
usually a property of the device being installed onto.

2023-12-11

* rename outputs.flashimage to outputs.mtdimage (and also diskimage to
mbrimage). This change is made in the expectation that "fooimage" is
the name of an outputs that gloms together other filesystem-like
outputs with some kind of partition table - so we might in future have
gptimage or lvmimage or ubimage.

2024-01-03

Liminix is now targeted to Nixpkgs 23.11 (not 23.05 as previously).
Upstream changes that have led to incompatible Liminix changes are:

* newer U-Boot version
* util-linux can now be built (previously depended on systemd)

2024-01-30

New port! Thanks to Arnout Engelen <arnout@bzzt.net>, Liminix
now runs on the TP-Link Archer AX23.

2024-02-12

* We now build wifi drivers (mac80211) from the same kernel source as
the running kernel, instead of using drivers from the linux-backports
project.  This may be a regression on some devices that depend on
OpenWrt patches for wireless functionality: if you have a device that
used to work and now doesn't, refer to OpenWrt
package/kernel/mac80211/patches/ to see if there's something in there
that needs to be applied.

* in general, we build kernel modules (e.g. for nftables) at the same
time as the kernel itself instead of expecting to be able to build
them afterwards as though they were "out of tree". Refer to commit
b9c0d93670275e69df24902b05bf4aa4f0fcbe96 for a fuller explanation
of how this simplifies things.

2024-02-13

So that we can be more consistent about services that would like their
state to be preserved across boots (assuming a writable filesystem)
these changes have been made

* /run/service-state has been moved to /run/services/outputs
 to better reflect what it's used for
* /run/services/state is either a symlink to /persist/services/state
 (if there's a writeable fs on /persist) or a directory (if there
 isn't)

The change will lose your ssh host key(s) unless you copy them from
the old location to the new one before rebooting into the new system

   mkdir -m 02751 -p /run/services/state/dropbear
   cp /persist/secrets/dropbear/* /run/services/state/dropbear

The `output`, `mkoutputs` functions defined by ${serviceFns}
have been updated for the new location.

2024-02-16

New (or at least, previously unreported) port! Liminix now runs on the
Turris Omnia and has been serving my family's internet needs for most
of this week.  Thanks to NGI0 Entrust and the NLnet Foundation for
sponsoring this development (and funding the hardware)

2024-02-21

New port! Thanks to Raito Bezarius, Liminix now runs on the Zyxel NWA50AX,
an MT7621 (MIPS EL) dual radio WiFi AP.

2024-04-29

The setup for using `levitate` has changed: now it accepts an entire
config fragment, not just a list of services.  Hopefully this makes it
a bit more useful :-)

  defaultProfile.packages = with pkgs; [
    ... 
    (levitate.override {
      config  = {
        services = {
          inherit (config.services) dhcpc sshd watchdog;
        };
        defaultProfile.packages = [ mtdutils ];
        users.root.openssh.authorizedKeys.keys = secrets.root.keys;
      };
    })
  ];

2024-07-16

* structured parameters are available for the pppoe service

* The "wan" configuration in modules/profiles/gateway.nix has changed:
instead of passing options that are used to create a pppoe interface,
callers should create a (pppoe or other) interface and pass that as
the value of profile.gateway.wan. For the pppoe case this is now only
very slightly more verbose, and it allows using the gateway profile
with other kinds of upstream.

2024-8-16

As part of implementing log shipping, the default directory for system
logs has beenchanged from /run/uncaught-logs to /run/log

2024-10-09

liminix-rebuild is being deprecated. From hereon in, the preferred way
to do an incremental update on an installed device with a writable
filesystem is to build the systemConfiguration output

    nix-build  -I liminix-config=hosts/myhost.nix --argstr deviceName turris-omnia -A outputs.systemConfiguration 

and then run the generated `install.sh` script

    result/install.sh root@192.168.8.1

2024-12-16

Config options changed: if you had set config.hardware.dts.includes
(maybe in an out-of-tree device port) to specify the search paths
in which dtc finds include files, you will need to change this to 
hardware.dts.includePaths.

The "new" hardware.dts.includes option is now for dtsi files which
should be merged into the device tree.

2024-12-19

Incremental updates changed again (but not massively). From hereon in,
the preferred way to do an incremental update on an installed device
with a writable filesystem is to build the updater output

    nix-build  -I liminix-config=hosts/myhost.nix --argstr deviceName turris-omnia -A outputs.updater

and then run the generated `update.sh` script. See 
https://www.liminix.org/doc/admin.html#updating-an-installed-system

2024-12-22

outputs.zimage is now outputs.kernel.zImage. This is unlikely to
affect many people at all but I mention it anyway.

2024-03-11

The fennel function (svc.open ...) now expects to be given the store
directory of a service derivation, not a direct path to the .outputs
directory. Thus

(svc.open "/nix/store/eeeeeeeeeeeeee-hellod")
not
(svc.open "/nix/store/eeeeeeeeeeeeee-hellod/.outputs")

This simplifies most extant uses of it