When performing OCR, some of the Tesseract settings perform better than
others on a variety of different workloads, but they mostly take
~negligible incremental time to run compared to the overhead of running
the ImageMagick filters.
After this commit, we try using all three of the current Tesseract
models (classic, LSTM, and classic+LSTM) to generate output text. This
fixes chromium-90's tests at release-20.09, and should make cases where
you're looking for *specific* text better, with the tradeoff of running
Tesseract multiple times.
To make it sensible to cherrypick this into release-20.09, this doesn't
change the existing API surface for the test driver. In particular,
get_screen_text continues to have the existing behaviour.
This commit patches one of the llvm-exegesis tests to swap out whatever
CPU model happens to be on the build host for bdver2 (AMD Family
15h/Piledriver), which was picked because it looks like that was the
intent of the test author. This provides a more predictable compilation
behaviour when running on older (or possibly even newer!) machines.
One of the machines that is currently part of the NixOS Hydra build
farm, wendy, is using an old AMD Opteron CPU for which LLVM has no
scheduling machine model. This causes one of the tests for llvm-exegesis
to fail, because it segfaults trying to use the machine model to produce
useful analysis results.
Note that this particular test only runs on x86-64 build hosts anyway;
aarch64 isn't affected.
This deliberately only patches LLVM 12 to limit the rebuilds; other
LLVM versions are going through staging.
At the moment, it's not possible to override the libvirtd package used
without supplying a nixpkgs overlay. Adding a package option makes
libvirtd more consistent and allows enabling e.g. ceph and iSCSI support
more easily.
The current Ceph tests use the old method for OSDs to store data on
disks, known as Filestore. This means there are no tests for the
Bluestore functionality that run on install, which means that things
like RocksDB being broken can slip through and break the Bluestore
functionality in a subtle and difficult to debug manner.
Add a test to check that Bluestore works, at least on a single node.
The NixOS 21.03 release has been delayed to 21.05. See NixOS/rfcs#80.
There are two instances of 21.03 which have been left as is, since they
are in stateVersion comparisons. This will ensure that existing user
configurations which refer to 21.03 will continue to work.
This was broken by the Tensorflow version bump, and is non-trivial to
correct - it now depends on dm-tree, which requires some work to build
due to a C++ extension which appears to require Bazel to compile.
This contains the base infrastructure (including a basic update script)
for maintaining Grafana plugins inside Nix, which, in a subsequent
commit, will be used for allowing the NixOS Grafana module to
automatically install plugins.
This is a workaround for NixOS/nix#4295, which caused single-user Linux
Nix installations using sandboxed builds to start failing to build
fetchzip derivations after 4a5c49363a.
In short: removing write permissions for the entire directory is great,
except we then can't rename(2) it to the final Nix store path out of the
sandbox, because we don't have write permission on the directory and
thus cannot update the ".." directory entry.
Since #104094 (d22b3ed4bc), NixOS is
using the unified cgroup hierarchy by default (aka cgroupv2).
This means the blkio controller isn't there, so we should test for
something else (e.g. the presence of the io controller).
Fixes#105581.
This doesn't do anything. Building with includeEmail = true produces
the same set as includeEmail = false, and the substitute rule removes
a random dictionary index operation.
The updateScript knows how to automatically fetch and update the version
data from the Factorio versions API (and update the hashes
appropriately), which makes it easier to update whenever experimental
does.
This fixes issues with building LibreSSL, which is required for the
NixOS tests: https://cmake.org/cmake/help/latest/release/3.19.html#id1
> CMake 3.19.0 compiles source files with the `LANGUAGE` property by
> passing an explicit language flag such as -x c. This is consistent
> with the property’s documented meaning that the source file is written
> in the specified language. However, it can break projects that were
> using the property only to cause the specified language’s compiler to
> be used. This has been reverted to restore behavior from CMake 3.18
> and below.
Building LLVM pieces is a huge contributor to build times, and probably
bloats binary size as well. Fortunately, there's a knob for this
specific thing (-DUNBUNDLED=ON seems broken and requires some libraries
which aren't packaged for Nix at the moment).
Hopefully this will make clickhouse able to build on OfBorg.
This allows capping the total amount of memory that will be used for
zram-swap, in addition to the percentage-based calculation, which is
useful when blanket-applying a configuration to many machines.
This is based off the strategy used by Fedora for their rollout of
zram-swap-by-default in Fedora 33
(https://fedoraproject.org/wiki/Changes/SwapOnZRAM), which caps the
maximum amount of memory used for zram at 4GiB.
In future it might be good to port this to the systemd zram-generator,
instead of using this separate infrastructure.
The download URL will redirect to the login page if credentials are not
present, but will return an error if the credentials are wrong.
Since we know we always expect credentials, we can fail the fetch in
the preHook if they're not provided.
We can't use e.g. builtins.throw because we want the fetchurl derivation
to be evaluated in all cases - because that's the mechanism which allows
you to just manually add the tarball to the Nix store.
Not only are these not used, but they also have super generic names,
which is confusing when they appear on the path, and possibly leads
to conflicts with other binaries.
"bazel fetch" will, by default, fetch everything that _might_ be used,
including things that will later be discarded due to the way the build
is configured.
Concretely, this means that for some builds of Java packages, this will
avoid failures where the builder tries to retrieve the JDK from /usr/share/java
(or equivalent).
This also means that for most packages we can fetch _fewer_ dependencies,
since the standard tree pruning for artifacts to fetch will take effect.
fetchConfigured is disabled by default since it changes the fetch hashes
of tensorflow/tensorflow2 (since it ends up fetching less).
At the moment, runing `deluge` with the deluge package installed returns
"No GSettings schemas are installed on the system".
After this patch, XDG_DATA_DIRS includes the gsettings-desktop-schemas,
which means the program actually manages to launch.
At the moment, using .withExtensions on a PHP derivation will
produce something which can't be used inside an
environment.systemPackages array, because outputsToInstall refers
to an output which doesn't exist on the final derivation.
Instead, override it back to just containing the single output
"out".
Luke Granger-Brown