This creates a dependency cycle when used with boot.tmpOnTmpfs:
basic.target <- tmp.mount <- swap.target <- zram-init-dev0 <- basic.target
This same fix is done already for tmp.mount
Fixes https://github.com/NixOS/nixpkgs/issues/47474
This also covers "androidStudioPackages.preview".
I believe that the name is confusing (is it from the beta or dev/canary
channel?) and with this error message it should be obvious how to update
ones configuration.
The old name "android-studio-preview" was a bit misleading while
"android-studio-beta" should clearly reflect that this is from the beta
channel. I hope that this does not break any workflows but since
"android-studio-preview" was most likely not called from any scripts the
risk should be low (also: most people probably use the stable version
anyway).
- add `zramSwap.algorithm` option, which allows to change compressor
declaratively. zstd as default
- add `zramSwap.swapDevices` option, which allows to define how many zram
devices will be used as swap. Rest devices can be managed freely
- simpler floating calculations
- fix udev race condition
- some documentation changes
- replaced `/sys/block/zram*` handling with `zramctl`, because I had occasional
"Device is busy" error (looks like zram has to be configured in predefined order)
- added `memoryPercent` and `algorithm` as restart triggers. I think, it was
a bug that changing `memoryPercent` in configuration wasn't applied immediately.
- removed a bind to .swap device. While it looks natural (when swap device goes
off, so should zram device), it wasn't implemented properly. This caused problems
with swapon/swapoff:
```
$ cat /proc/swaps
Filename Type Size Used Priority
/dev/zram0 partition 8166024 0 -2
/var/swapfile file 5119996 5120 1
$ sudo swapoff -a
$ sudo swapon -a
swapon: /dev/zram0: read swap header failed
$ cat /proc/swaps
Filename Type Size Used Priority
/var/swapfile file 5119996 0 1
```
A simple update from 6.3.0 to 6.7.1 fixes a breaking bug - something about requested version 30 being less than version 80 during startup?
Either way, 6.7.1 seems to solve the issue.
Two reasons for this:
- more fine-grained space/functionality tradeoff
- preparation for the sage 8.6 update, which finally doesn't need a
downgraded gap anymore but does break when unexpected (non-standard)
packages are installed. Details: https://trac.sagemath.org/ticket/26983
The proper way to deal with gap packages would be to create a package
set, package each one individually and have something like gap
equivalent of `python.withPackages`. I am not willing to do that
however.
There are some starts of a `make install`, but nothing complete yet.
Upstream now ships a `libgap` as a replacement of the custom one used by
sagemath.
