When sandbox-fallback = true (the default), the Nix builder will fall
back to disabled sandbox mode when the kernel doesn’t allow users to
set it up. This prevents hard errors from occuring in tricky places,
especially the initial installer. To restore the previous behavior,
users can set:
sandbox-fallback = false
in their /etc/nix/nix.conf configuration.
Some kernels disable "unpriveleged user namespaces". This is
unfortunate, but we can still use mount namespaces. Anyway, since each
builder has its own nixbld user, we already have most of the benefits
of user namespaces.
Instead of using whatever the current system default is, import a Nix
channel when building an image.
This will use Nix' internal caching behaviour for tarballs fetched
without a SHA-hash.
For now the downloaded channel is pinned to nixos-19.03.
When running Nix inside of a container image, there are several
environment-specific details that need to be configured appropriately.
Most importantly, since one of the recent Nix 2.x releases, sandboxing
during builds is enabled by default. This, however, requires kernel
privileges which commonly aren't available to containers.
Nixery's demo instance (for instance, hehe) is deployed on AppEngine
where this type of container configuration is difficult, hence this
change.
Specifically the following were changed:
* additional tools (such as tar/gzip) were introduced into the image
because the builtins-toolset in Nix does not reference these tools
via their store paths, which leads to them not being included
automatically
* Nix sandboxing was disabled in the container image
* the users/groups required by Nix were added to the container setup.
Note that these are being configured manually instead of via the
tools from the 'shadow'-package, because the latter requires some
user information (such as root) to be present already, which is not
the case inside of the container
--
1f44f8f487aa3afe8248132e4081519e85671965 by CJ Johnson <johnsoncj@google.com>:
Updates ScopedAllocatorWorks test for InlinedVector to not depend on specific byte counts of standard library vectors. It's too brittle in the face of capacity-changing changes to InlinedVector and does not provide signal in those breakages.
PiperOrigin-RevId: 259590332
--
fef7589547e9cdd04a254f6ae06e2bd9ec2b35f0 by CJ Johnson <johnsoncj@google.com>:
Updates the implementation of InlinedVector::insert(...) to be exception safe and adds an exception safety tests for insert(...)
PiperOrigin-RevId: 259542968
GitOrigin-RevId: 1f44f8f487aa3afe8248132e4081519e85671965
Change-Id: I514beff56159c9c717f8d29197728011af1fecd7
Introduces a wrapper script which automatically sets the paths to the
required runtime data dependencies.
Additionally configures a container image derivation which will output
a derivation with Nixery, Nix and other dependencies.
Previously the code had hardcoded paths to runtime data (the Nix
builder & web files), which have now been moved into configuration
options.
Additionally configuration for the application is now centralised in a
single config struct, an instance of which is passed around the
application.
This makes it possible to implement a wrapper in Nix that will
configure the runtime data locations automatically.
Rather than migrating to Bazel, it seems more appropriate to use Nix
for this project.
The project is split into several different components (for data
dependencies and binaries). A derivation for building an image for
Nixery itself will be added.
Add a new Item raw type and entity type, with preliminary, basic support
for food. There's a really frustrating toml-rs bug that prevents writing
these nicely as toml right now, so I also added support for mixing JSON
and TOML in a single config dir
--
dcff7cc4eb3837d39d1e083cbf1d4f082054cbf6 by Laramie Leavitt <lar@google.com>:
Add default and fallback modes for SaltedSeedSeq::generate().
SeedSeq::generate will often be called with contiguous ranges of uint32_t.
Detect this case and use the currently direct code paths to handle it.
Otherwise use a fallback mechanism which does an additional copy.
PiperOrigin-RevId: 258853656
--
59ec88845ac2ee6567c493021b54385940d66762 by Gennadiy Rozental <rogeeff@google.com>:
Internal change
PiperOrigin-RevId: 258822137
--
eb2d1ab21f6f94c24c51c1cd3719846be259e8e7 by Abseil Team <absl-team@google.com>:
Add iOS version 11 to the mix of Apple OS versions that have various C++17 header files
but do not support them.
PiperOrigin-RevId: 258820405
--
452cea3e13b29797b2c385d7c6da7613d36bdc45 by Gennadiy Rozental <rogeeff@google.com>:
Internal change
PiperOrigin-RevId: 258802436
GitOrigin-RevId: dcff7cc4eb3837d39d1e083cbf1d4f082054cbf6
Change-Id: I2261cb58e142eb15017ef646a56710dd64f06496
--
b0015627610a311997ab21b8b295a8168b5915ec by Derek Mauro <dmauro@google.com>:
Add an empty log_severity library. The log_severity sources will
eventually migrate here once users are updated to depend on the new
target.
Note that no opensource user should be depending on log_severity.h
today since it has no purpose in opensource.
PiperOrigin-RevId: 258781702
--
c4d8d03f731d1de648ef2d17a55c3a16029ba331 by Derek Mauro <dmauro@google.com>:
Move atomic_hook.h to its own internal target.
PiperOrigin-RevId: 258765527
GitOrigin-RevId: b0015627610a311997ab21b8b295a8168b5915ec
Change-Id: I0ec9b8b3cb6a27dc32a5f6c318d07e02548f193d
* Add first install test
* Fix style
* Split the test into spanner and bigtable
* Correct indentation
* Add other distros, shared lib test, and kokoro configs
* Fix style
Add a system for statically-included entity raws (which necessitated
making a deserializable existential Color struct) and test it out by
initializing the game (for now) with a single on-screen gormlak.
