Souffle has seen some significant upgrades in the past few years and now
has trimmed and replaced several of its more expensive dependencies,
such as boost, openjdk, etc.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
ttyd hasn't seen a release in a while, but has a few useful bugfixes and
features (such as IPv6) that are good to have. It also seems to fix a
few crashes I encountered (likely due to newer openssl/libwebsockets).
So in an untraditional fashion, we'll adopt this with a _pre tag to
ensure it gets bumped correctly later on.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
bcf54ce5bb introduced a treewide change to
use ${stdenv.shell} where-ever possible. However, this broke a script
used by dockerTools, store-path-to-layer.sh, as it did not preserve the
+x mode bit. This meant the file got put into the store as mode 0444,
resulting in a build-time error later on that looked like:
xargs: /nix/store/jixivxhh3c8sncp9xlkc4ls3y5f2mmxh-store-path-to-layer.sh: Permission denied
However, in a twist of fate, bcf54ce5bb
not only introduced this regression but, in this particular instance,
didn't even fix the original bug: the store-path-to-layer.sh script
*still* uses /bin/sh as its shebang line, rather than an absolute path
to stdenv. (Fixing this can be done in a separate commit.)
Signed-off-by: Austin Seipp <aseipp@pobox.com>
SAPIC is bundled with Tamarin and doesn't have separate releases
anymore; add an appropriate 'throw' clause to the alias so people know
where to find it.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
With this, we can drop the old 1.4.0 patches for 8.4 support, since
those are now upstream.
Furthermore, SAPIC Is now bundled inside Tamarin, so we can drop the
external dependency. (This includes a patch that compiles SAPIC to
native code, much like the original, to reduce closure size.)
Signed-off-by: Austin Seipp <aseipp@pobox.com>
This is a backwards compatible change; it mostly puts all the extensions
for postgresql in a common directory to keep them isolated.
It also moves a few things that /were not/ extensions out into other parts of
the filesystem namespace; namely the postgresql_jdbc and psqlodbc libraries
were moved under development/java-modules and development/libraries,
respectively. Because these libraries use the libpq postgresql client drivers,
they're less sensitive to underlying version changes anyway (since the protocol
is relatively stable).
No attributes were renamed or harmed in the creation of this patch.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
This has two main advantages:
- By setting hasSharedObjects = true, buildOcaml will automatically
include a setup-hook.sh that sets CAML_LD_LIBRARY_PATH in dependent
expressions. This is needed to pick up dllzarith.so properly which is
shipped as part of the library.
- We can kill the ugly assert in the expression and instead change it
to use minimumSupportedOcamlVersion.
(Note: this was reverted in b44d5136e8, but the change is
exactly equivalent -- I wasn't sure what impact zarith might actually
have without checking OfBorg, which I wanted to do first.)
Signed-off-by: Austin Seipp <aseipp@pobox.com>
This has two main advantages:
- By setting hasSharedObjects = true, buildOcaml will automatically
include a setup-hook.sh that sets CAML_LD_LIBRARY_PATH in dependent
expressions. This is needed to pick up dllzarith.so properly which is
shipped as party of the library.
- We can kill the ugly assert in the expression and instead change it
to use minimumSupportedOcamlVersion.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
This fixes a bizarre regression in the NextPNR GUI that causes the
background of the OpenGL floorplanning window to become 'transparent' on
certain platforms, greatly limiting its utility. However, QT 5.11 seems
to work just fine here.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
- Require Coq 8.6.1+
- Split substituteInPlace call into patchPhase
- Constrain platforms correctly to x86_64 Linux/Darwin, which was all
it supported anyway (there was no way to properly configure i686 builds,
nor cross builds. In the future there might be)
- Minor stylistic cleanups
- Add new 'man' and 'doc' outputs (the previous attempt to move the
build artifact outputs into $lib no longer worked correctly and they
were installed into 'out' instead, this fixes it completely).
- Clean up weird binary artifacts left in $out (that were already
in $lib)
- Wrap ccomp to undefine _FORTIFY_SOURCE; otherwise it causes
annoying warnings on every invocation
Signed-off-by: Austin Seipp <aseipp@pobox.com>
This is to help QT find all the necessary plugin libraries at startup
time, otherwise it freaks out when run out of 'nix-env' environment or
run directly, e.g. `./result/bin/nextpnr-ice40 --gui`. The reason for
this is that none of the traditional paths it looks for are available.
The workarounds for this are to otherwise:
- Install e.g. into environment.systemPackages (presumably it will
then pick up QT libraries in /run/current-system/sw/lib/qt-*)
- Install 'qtbase' into your user environment (qt will also try to
load dependent libraries out of ~/.nix-profile/lib/qt-*)
However, this QT_PLUGIN_PATH wrapping hack is used elsewhere in the
tree, presumably to mitigate these (poor) workarounds, especially for
non-NixOS users. There seems to be no downside to this.
With this, I have been able to run NextPNR's GUI on an Ubuntu 16.04
system using the 'nixGL' hack by simply running the resulting binary
from anywhere (though there seems to be some glitching artifacts in the
floorplan UI, I suspect this is due to a buggy OpenGL stack rather than
any direct problem with NextPNR or the QT libraries themselves).
This does not mark the GUI build as non-broken yet, though. That will
happen in the future after a bit more testing and splitting nextpnr into
separate minimal/GUI attributes.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
With the previous PyPy3 change, this reduces the compile time from
~1m30s to roughly 36s (compared to the original, serial, Python 3 build
time of 2:30s).
Signed-off-by: Austin Seipp <aseipp@pobox.com>
PyPy3 offers tremendous speedups for IceStorm tools written in Python,
including tools used at compile-time to generate the chip databases, and
runtime tools distributed to users, such as icebox_vlog.
For example, on my ThreadRipper 1950X, build times for IceStorm
consistently go from 2m30s -> 1m30s with this change, a 40% improvement,
simply due to improvements in raw CPU efficiency. (This is also worsened
by the fact the build is currently serial, but that can easily be fixed
anyway.)
On top of that, tools distributed to users are also now run using PyPy.
Utilities such as icebox_vlog are useful for post-bitstream testing, for
instance, and also are improved due to improved CPU efficiency as well.
For example, when "decompiling" an ICE40 bitstream for HX8K devices,
containing a synthesized copy of PicoRV32 (from the NextPNR demos), the
runtime of icebox_vlog is cut from 25 seconds to 9 seconds consistently
with this change alone.
Normally, picking a Python interpreter outright for Python-based code is
a "bad idea", but in the case of IceStorm it should be perfectly safe,
and an excellent improvement for users. There are a few reasons for
this:
- IceStorm uses pure Python 3 and nothing else. There are no
requirements for any 3rd party packages, which might cause annoying
incompatibilities, and PyPy has historically shown very strong core
Python compatibility.
- IceStorm is NOT a set of Python libraries, it is a set of tools,
some of which, coincidentally, are written in Python. It is (normally)
bad form to fix libraries to certain interpreters versions if the reason
strictly isn't "it doesn't work/isn't compatible". That is not the case
here. These tools may later be used by other programs, such as NextPNR,
but the Python interpreter is ultimately not that important in quesion
for the user. In this sense, there is almost no downside to picking
PyPy explicitly if it offers far better performance.
(Point 2 is not actually strictly true; there are some distributed .py
files that you can import from but they are basically just static
classes that are imported by tools like nextpnr; this is expected.)
Because of this, users should see very little change except better
performance for IceStorm tools on their machines.
Note that PyPy is not supported on aarch64 -- this only applies to
x86_64 machines.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
This requires an absurd, disgustingly gross hack in order to share the
build artifacts necessary for nextpnr to use trellis.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
This didn't work remotely (on a server with Nvidia drivers) _or_ on a
local Intel machine with integrated graphics. I presumably messed
something up (a missing dependency), but I'm not sure where. We can fix
it later.
In the mean time, just disable this by hiding it behind a minimal flag.
As a bonus this reduces the closure size by about half, although it's
still surprisingly large (~300MB or so). Part of that is probably
Python, though.
When the GUI is reintroduced in a working manner, we can expose two
nextpnr attributes for the minimal non-GUI build, and the GUI build.
(Note that I have no plans of making Python optional, since it's
extremely valuable in general and much more lightweight than qtbase.)
Signed-off-by: Austin Seipp <aseipp@pobox.com>
Otherwise, the wheel gets built with invalid metadata -- causing
'torch >= 1.0.0' to be unsatisfiable in other python packages, for
instance.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
This currently uses a binary-only package, since building
jailer/firecracker all on their own is somewhat complex from my
attempts.
This will later be changed into a source-only build, ideally.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
This puts MetaOCaml on more equal footing with the normal OCaml
packages, which have a few passthru's and expect to have more 'meta'
information available (such as 'platforms').
With these changes, you can use the ber_metaocaml package along with
ocaml-ng.mkOcamlPackages in order to create a full package set with
Native MetaOCaml support, though this currently isn't implemented (you
have to do this yourself).
There are also other light cleanups, for example this also removes the
old MIPS support and restricts the platforms to x86 Linux/Darwin, for
now. Other platforms can be added on a case-by-case basis.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
This cleans up the CockroachDB expression, with a few suggestions from
@aszlig.
However, it brought up the note of using systemd's StateDirectory=
directive, which is a nice feature for managing long-term data files,
especially for UID/GID assigned services. However, it can only manage
directories under /var/lib (for global services), so it has to introduce
a special path to make use of it at all in the case someone wants a path
at a different root.
While the dataDir directive at the NixOS level is _occasionally_ useful,
I've gone ahead and removed it for now, as this expression is so new,
and it makes the expression cleaner, while other kinks can be worked out
and people can test drive it.
CockroachDB's dataDir directive, instead, has been replaced with
systemd's StateDirectory management to place the data under
/var/lib/cockroachdb for all uses.
There's an included RequiresMountsFor= clause like usual though, so if
people want dependencies for any kind of mounted device at boot
time/before database startup, it's easy to specify using their own
mount/filesystems clause.
This can also be reverted if necessary, but, we can see if anyone ever
actually wants that later on before doing it -- it's a backwards
compatible change, anyway.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
As the comment notes, restarts/exits of dhcpcd generally require
restarting the NTP service since, if name resolution fails for a pool of
servers, the service might break itself. To be on the safe side, try
restarting Chrony in these instances, too.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
Setting the server list to be empty is useful e.g. for hardware-only
or virtualized reference clocks that are passed through to the system
directly. In this case, initstepslew has no effect, so don't emit it.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
This also splits the .bin output to have a separate .man attribute:
previously it contained both.
This also adds provisional support for aarch64-linux, which seems to
build easily. (Full testing will ideally come via NixOS tests later)
Signed-off-by: Austin Seipp <aseipp@pobox.com>
This ensures the proper version is reported in the server status
information; otherwise it has a '-PRERELEASE' suffix.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
FoundationDB uses Python at build time for some code generation.
However, it also has the official python bindings inside the source code
too, and the code for the Python bindings has some of it auto-generated
at compile time.
This made building python packages unattractive: we want to use the
source code generated from the FoundationDB build, but we don't want to
rebuild it. Previously we would override the 'python' input to the
FoundationDB module, but this meant we would do a complete rebuild, as
it was a necessary build time dependency, even though the resulting
generated code itself would not change. Furthermore, FoundationDB
versions < 6.0 don't properly support Python 3 *for the build system*,
though the bindings supported it, so that caused build failures. But the
first effect is the worst: it meant building separate python2 and
python3 packages implied two complete rebuilds of a single FoundationDB
version. This meant rather than 3 FDB builds, we'd do 3*N where N = the
number of major Python versions we support.
Finally, because we did not use pip to generate a wheel that we install
with metadata recorded for the installation, the FoundationDB python
package couldn't be used as an input to other setup.py-based packages:
there would be no recorded metadata in the dist-info folder which would
say this is the foundationdb package. This greatly limits its utility.
To fix all this, we do a few things:
- Apply some patches to fix the build system with Python 3.x for
older FoundationDB versions. (This is nice if end-users have
overridden the global Python version for some reason.)
- Move python directly into nativeBuildInputs, so it is only a
build time dependency.
- Take the python source code from the ./bindings directory and
tar it up use later after the build is done, so we get to keep
the generated code. This is the new 'pythonsrc' output from the
build. This code doesn't change based on whether or not the input
or resulting package is using Python 2 or 3, it's totally
deterministic.
- The build system also patches up the python source code a little,
so it can be installed directly with setup.py (it needs a little
stuff that it normally expects the build system to do.)
- Rework the python package to a separate file that uses
buildPythonPackage directly. Because the source code is already
prepared, it needs almost nothing else. Furthermore, this kills
the override itself for the foundationdb package, meaning rebuilds
are no longer needed.
- This package is very simple and just uses foundationdb.pythonsrc
as its source input. It also ensures a link to libfdb_c.so can
be found by ctypes (using substituteInPlace)
- python-packages.nix now just uses callPackage directly.
The net effect of this is, most importantly, that python packages do not
imply a full rebuild of the server source code: building python2 and
python3 packages from a version of FoundationDB now does not need to
override the foundationdb python input, reducing the number of needless
builds. They instead just run setup.py with the given version as input.
The second biggest effect is that wheel metadata is recorded correctly,
meaning dependent-python-packages that want to use the FoundationDB
bindings e.g. from PyPi should now work fine with buildPythonPackage.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
The Z Garbage Collector is a concurrent, scalable, low latency garbage
collector designed to meet extremely-low-pause-time requirements for
small-to-multi-TB heap sizes.
ZGC can be enabled with the magical incantation:
$ java -XX:+UnlockExperimentalVMOptions -XX:+UseZGC ...
Currently, ZGC is only available for x86_64-linux (though a port for
aarch64-linux may become available at a future time.) There are also a
number of other features that currently aren't present, such as JVMCI
integration (meaning compiler tools like Graal which require JVMCI will
not work with ZGC enabled.)
Signed-off-by: Austin Seipp <aseipp@pobox.com>
This also adds me as the maintainer (as it lacked one previously),
and simplifies the expression quite a bit.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
ee58a5b30d broke the plv8 build because it
upgraded the v8_6_x expression everywhere to the 6.9 branch, which came
with API changes. Notably, it seems plv8 only supports up-to v8 6.4.x at
this time.
This keeps a copy of the plv8_6_x expression inside the same directory
as the other v8 versions (so patches, etc are easy to apply), but it is
not exposed to the top-level of all-packages.nix.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
This makes pgjwt take a dummy 'postgresql' argument, which it does not *need*
in the buildInputs (it is purely a SQL extension with no C code). However, this
argument will be necessary for an upcoming change that will parameterize the
extensions over a particular PostgreSQL version.
It also does some tiny cleanup, setting a null build phase.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
Since the development of #38698, I have been radically overhauling the
PostgreSQL support and plan on maintaining it in the long run, taking
over from @ocharles, who authored most of it initially.
However, while #38698 has not been merged (yet), I'm taking the time to
go ahead and add myself as the owner of all the related code, so that I
can be marked as a reviewer for things people submit in the mean time.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
Setting this variable in the environment of systemd-timedated allows
'timedatectl' to tell if an NTP service is running.
Closes#48917.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
'cloudflared' is a multi-purpose client-side tool for CloudFlare Argo
Tunnel, CloudFlare Access, as well as including a simple DNS-over-HTTP
(DoH) proxy tool as well.
However, 'cloudflared' is NOT available under an open source license.
Furthermore, the exact terms of redistribution (namely, if we are able
to redistribute binaries at all) are not entirely clear to me. As a
result, I have filed the following bug report concerning the terms of
redistribution for the source code and binaries:
https://github.com/cloudflare/cloudflared/issues/53
'cloudflared' does have source code available, however, and it
encourages users to use 'go install' in order to set it up, in fact (or
download their prebuilt, compiled binaries). So using the source seems
to be encouraged. Even then, I'm still not sure if Hydra can serve these
binaries.
In lieu of a more pointed answer regarding source/binary licensing, and
to avoid keeping this expression in my private tree, I've marked it as
'unfree' (to avoid Hydra serving it in any way) as well as compiled from
source (to avoid any 'redistribution allowed while unmodified' terms
that may crop up).
The dependencies for this build were generated using 'dep2nix'.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
Most importantly, this sets PrivateTmp, ProtectHome, and ProtectSystem
so that Chrony flaws are mitigated, should they occur.
Moving to ProtectSystem=full however, requires moving the chrony key
files under /var/lib/chrony -- which should be fine, anyway.
This also ensures ConditionCapability=CAP_SYS_TIME is set, ensuring
that chronyd will only be launched in an environment where such a
capability can be granted.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
Austin Seipp