Passing `-l$NIX_BUILD_CORES` improperly limits the overall system load.
For a build machine which is configured to run `$B` builds where each
build gets `total cores / B` cores (`$C`), passing `-l $C` to make will
improperly limit the load to `$C` instead of `$B * $C`.
This effect becomes quite pronounced on machines with 80 cores, with
40 simultaneous builds and a cores limit of 2. On a machine with this
configuration, Nix will run 40 builds and make will limit the overall
system load to approximately 2. A build machine with this many cores
can happily run with a load approaching 80.
A non-solution is to oversubscribe the machine, by picking a larger
`$C`. However, there is no way to divide the number of cores in a way
which fairly subdivides the available cores when `$B` is greater than
1.
There has been exploration of passing a jobserver in to the sandbox,
or sharing a jobserver between all the builds. This is one option, but
relatively complicated and only supports make. Lots of other software
uses its own implementation of `-j` and doesn't support either `-l` or
the Make jobserver.
For the case of an interactive user machine, the user should limit
overall system load using `$B`, `$C`, and optionally systemd's
cpu/network/io limiting features.
Making this change should significantly improve the utilization of our
build farm, and improve the throughput of Hydra.
Xonotic supports (opt-in) tracking of user statistics. For staistics to
be trackable each player needs a unique identifier that is based on some
cryptographic identity. For that to work we need to build the "blind"
library and provide it do xonotic during runtime.
The official xonotic releases ship with the public key of some sort of
central trust authority and thus we must retain that file within our
data package as well.
Before this commit the crypto_* commands in the ingame console weren't
available. With this commit you should be able to execute "crypto_keys"
commands as show below.
$ crypto_keys
0: public key key_0.d0pk (fingerprint: Xon//KssdlzGkFKdnnN4sgg8H+koTbBn5JTi37BAW1Q=)
private ID key_0.d0si (public key fingerprint: 9piqrk8ajAPRc3BnSbkac5GA+yL3dOwh53BhyrfmVlI=)
Once the above command works you have to configure your player profile
to allow tracking (if you want) via the Multiplayer -> Profile dialog.
In the top right-hand corner there will be checkboxes to control the
level of tracking that you are opting in to.
The desktop item was referring to "$out/bin/xonotic" as executable, but
since it's built in its own derivation now, "$out" did not contain the
xonotic wrapper.
Since it seems to be common practise to use a relative path, I changed
it to do that here as well.
This has many advantages:
- Each variant can be installed without pulling in the dependencies of the
other variants, which makes it possible to build an SDL variant
without X11 dependencies
- Hydra can now build binaries without downloading 1GB of data, so users
do not have to build them on their own machines
- Users do not have to redownload 1GB of data after each dependency
update
Includes the following fixes:
- Add dependency on libGL for GLX variant as it will fail in some
environments otherwise
- Pass -j and -l to make to enable parallel building
- Quote homepage URI and use https
- Add a .desktop file and icons
* treewide: http -> https sources
This updates the source urls of all top-level packages from http to
https where possible.
* buildtorrent: fix url and tab -> spaces
The most complex problems were from dealing with switches reverted in
the meantime (gcc5, gmp6, ncurses6).
It's likely that darwin is (still) broken nontrivially.
