| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
For example the store path of libGL-1.0.0 is a symlink pointing to
libglvnd-1.0.0 right now on my machine.
If we have such a symlink the sandbox would just silently skip it and
only mount the *resolved* path instead of creating the symlink leading
to the target.
Now whenever bind_mount() with the resolve argument being true is used,
we create all the symlinks leading to the target path determined by
realpath().
Signed-off-by: aszlig <aszlig@nix.build>
|
|
|
|
|
|
|
|
|
|
| |
This was an error I made in 7b7f782c93fafe2c42f882b933cf49ba99e3e3bc.
Basically the change was to replace "import ../../nixpkgs-path.nix" by
thu "nixpkgsPath" argument, but I forgot to remove the ".nix" and it
became "nixpkgsPath.nix".
Signed-off-by: aszlig <aszlig@nix.build>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Since the introduction and move of a few packages to use the sandbox, we
no longer have XDG desktop entries, because the sandbox only creates
wrappers for all programs in $drv/bin.
This now also copies the XDG desktop files and replaces absolute paths
to binaries to refer to the sandboxed binaries.
I also modified the test to go through the XDG desktop file by default
so we can ensure that this works properly.
Signed-off-by: aszlig <aszlig@nix.build>
|
|
|
|
|
|
|
| |
Yet another occasion where we import nixpkgs-path.nix unconditionally,
so let's actually pass a nixpkgsPath to every test function.
Signed-off-by: aszlig <aszlig@nix.build>
|
|
|
|
|
|
|
|
|
| |
Another point where we rely on nixpkgs-path.nix from within release.nix,
where we already have the correct path to nixpkgs passed as an argument.
So let's simply pass that argument along to the actual test.
Signed-off-by: aszlig <aszlig@nix.build>
|
|
|
|
|
|
|
|
|
|
|
|
| |
We only handle XDG_DATA_HOME and XDG_CONFIG_HOME, but we've missed
XDG_CACHE_HOME. While the latter is used very rarely as it doesn't
matter a lot if it ends up within a tmpfs anyway. However if the cache
directory gets pretty large we might run out of space.
Not only do we now have proper fallbacks but this also adds tests for
all of the XDG environment variables we're using.
Signed-off-by: aszlig <aszlig@nix.build>
|
|
|
|
|
|
|
|
| |
In 38d3fe573f4d0ad2115eaca71a0b8f67fd01a580 we have moved the sandbox
builder to the top-level vuizvui namespace so we no longer need to do
weird workarounds by providing an empty game configuration.
Signed-off-by: aszlig <aszlig@nix.build>
|
|
|
|
|
|
|
|
|
|
|
| |
We have excluded all tests within the games directory from being built
by Hydra, rightfully so because they're proprietary. However our sandbox
is *not* proprietary so we want to have it tested.
Besides, we might want to use that sandbox for other things rather than
just games in the future, which saves us that rename later ;-)
Signed-off-by: aszlig <aszlig@nix.build>
|
|
|
|
|
|
|
|
| |
This is only a very rudimentary test of the sandbox implementation, but
it already serves as a series of regression test for a few problems I
ran into so far.
Signed-off-by: aszlig <aszlig@nix.build>
|
|
|
|
|
|
|
|
|
| |
Using the virtio disk interface isn't very suitable for real-world
simulation, so let's use the SCSI interface, because SATA is exposed to
userland as a SCSI device.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Cc: @devhell
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is in reaction to upstream commit
NixOS/nixpkgs@e34ce9d1c551fb43742aada6bb43ccb1a52e64a1.
One of the changes in GnuPG 2.1.23 is that the main binary is now called
gpg instead of gpg2. See the full release announcement here:
https://lists.gnupg.org/pipermail/gnupg-announce/2017q3/000412.html
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
|
|
|
|
|
|
|
| |
IMHO it makes more sense to use the latest rc kernel instead of the
latest stable kernel to run this test, because what we're actually
testing here is whether our bfq-by-default.patch is working.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
|
|
|
|
|
|
|
|
|
| |
The service and test has been broken for a long time now and nobody
really has any interest in using it or even fixing it, so I'm removing
it to decrease the amount of crap we have in there.
If somebody still wants to use this someday we can still bring it back.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
|
|
|
|
|
|
|
|
| |
Not everybody likes to have the latest release canidate kernel, so we
now have an option called vuizvui.system.kernel.bfq.enable, which *only*
enables the BFQ scheduler per default.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Cc: @devhell
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Major upstream changes are:
* Navigation Overhaul: The cockpit navigation interface has been
completely overhauled. Planets, moons and ships are all visible and
orbit each other in real time. Systems will now contain NPC stations,
friendly and hostile NPC ships, and strange space anomalies to visit!
* Customizable Mechs: Explore these new space locations in customizable
spacefaring mechs! Traverse hostile space in zero gravity, fight
powerful new space monsters, and collect unique rewards as you
upgrade your mech to progress through more difficult hazards. Mechs
can also be deployed to planets, to crush your enemies with
overwhelming firepower!
* Modular Space Stations: Make a permanent home among the stars with
player-owned stations! Use a station transponder to place your
station into orbit, then expand it with modular rooms to suit your
needs.
The full changes can be found at the announcement blog post at:
http://playstarbound.com/spacefarer-update/
One of the changes not listed there is that the archive now consists of
a server_linux and client_linux directory, where the latter is
structured the same as in previous versions. However, both contain the
server binary and both of these binaries match in content.
So I'm assuming that the server_linux directory is only a trimmed-down
version in terms of assets but otherwise pretty much the same.
I've also fixed the VM test, which didn't recognize the font of
"Species" anymore, so we're now matching on "randomise".
In addition to that I've added a sleep of 30 seconds before the final
screenshot, so we get a picture of the fully rendered intro scenario.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Since version 1.0, the coordinates for the menu labels no longer apply
and need to be fixed. Also we no longer land on our ship but in the
protectorate building, so there won't be a quest dialog to close.
This also simplifies the test because we can now detect whether we're
in-game using OCR matching parts of the quest marker for "Attend your
graduation ceremony".
I've also increased the available memory for the server, because it
seems that for this simple test the base memory required for running a
Starbound server seems to have increased.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
|
|
|
|
|
|
| |
The Steam version is old anyway and since we've reached 1.0 there is no
point in extracting it from Steam anymore.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When using systemctl restart or systemctl stop on any of the GnuPG
services, the sockets were closed and removed.
However we are using socket activation, so a simple restart of for
example the agent would cause the socket to be closed and removed and
afterwards the gpg-agent service is unable to pick up the socket again,
thus failing to start.
This in turn has led to GnuPG starting the agent by its own, entirely
bypassing socket activation and our shiny service module.
In order to cope with this, we need to provide LD_PRELOAD wrappers also
for remove() and close(), so that we can prevent GnuPG from closing the
systemd file descriptors.
I've also added a small subtest to ensure this won't happen again in the
future.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
|
|
|
|
|
|
|
|
| |
The shell script embedded into the expect script had "set -x" enabled.
While this doesn't really hurt it doesn't really aid in debugging
either (expect -d works much better), so let's remove it.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
|
|
|
|
|
| |
Forgot to do that in ea85dd3eaf0cbd19ddf22f41391d092a21147063.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
|
|
|
|
|
|
|
|
|
|
|
| |
We already have an "i3wm" test in upstream <nixpkgs> which is much more
thorough than the unfinished test I've made here.
The intention of this test however was to specifically test the Vuizvui
service module. Nevertheless, it's still just a dummy test and the
"i3wm" test works much better, so let's remove it until we have a more
complete implementation.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
|
|
|
|
|
|
| |
We're not testing this thoroughly though, but this makes sure that we
don't accidentally break module support for scdaemon.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
|
|
|
|
|
|
|
|
| |
We do things such as placing gnupg into environment.systemPackages, so
calling this just "programs.gpg-agent" doesn't fit that. Especially if
we really want to have a way to specify configuration values in case I'm
getting masochistic someday ;-)
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Since NixOS/nixpkgs@5391882 there no longer is the option to start the
agent during X session startup, which prompted me to write this module.
I was unhappy how GnuPG is handled in NixOS since a long time and wanted
to OCD all the configuration files directly into the module.
Unfortunately, this is something I eventually gave up because GnuPG's
design makes it very hard to preseed configuration. My first attempt was
to provide default configuration files in /etc/gnupg, but that wasn't
properly picked up by GnuPG.
Another way would have been to change the default configuration files,
but that would have the downside that we could only override those
configurations using command line options for each individual GnuPG
component.
The approach I tried to go for was to patch GnuPG so that all the
defaults are directly set in the source code using a giant sed
expression. It turned out that this approach doesn't work very well,
because every component has implemented its own ways how to handle
commandline arguments versus (default) configuration files.
In the end I gave up trying to OCD anything related to GnuPG
configuration and concentrated just on the agent.
And that's another beast, which unfortunately doesn't work very well
with systemd.
While searching the net for existing patches I stumbled upon one done by
@shlevy:
https://lists.gnupg.org/pipermail/gnupg-devel/2014-November/029092.html
Unfortunately, the upstream author seems to be quite anti-systemd and
didn't want to accept that into the upstream project.
Because of this I went for using LD_PRELOAD to pick up the file
descriptors provided by the systemd sockets, because in the end I don't
want to constantly catch up with upstream and rebase the patch on every
new release.
Apart from just wrapping the agent to be socket activated, we also wrap
the pinentry program, so that we can inject a _CLIENT_PID environment
variable from the LD_PRELOAD wrapper that is picked up by the pinentry
wrapper to determine the TTY and/or display of the client communicating
with the agent.
The wrapper uses the proc filesystem to get all the relevant information
and passes it to the real pinentry.
The advantage of this is that we don't need to do things such as
"gpg-connect-agent updatestartuptty /bye" or any other workarounds and
even if we connect via SSH the agent should be able to correctly pick up
the TTY and/or display.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Very preliminary and doesn't have all the option descriptions right, nor
does it have convenience features such as setting allowAdminCommands
based on whether any users are defined with admin privileges.
Of course the latter needs to undergo the decision on how to handle RCON
connections, because the latter *might* need that option.
But apart from that single option, there are a lot more options we need
to flesh out.
Also, the test currently is very limited and only spins up a client,
connects to the server and does a movement (just walk to the right).
Needless to say, it's even quite fragile and relies on OCR to properly
detect the custom pixel fonts from Starbound. Which unfortunately fails
most of the time.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
|
|
|
|
|
|
|
|
| |
This was a very old effort to NixOSify "heinrich" which unfortunately
didn't happen and I'm not sure whether "heinrich" even exists anymore.
The tests were broken anyway, so I doubt anyone would grief over it.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
|
|
|
|
|
|
| |
The test is broken since it was introduced for the first time in
080933b2f158e7a3f0dfc4e7f499c0e3752cd3fc.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
|
|
|
|
|
|
| |
Namespacing the options with "vuizvui." now leads to failing tests,
which I probably should have checked in the previous commit, my bad!
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
|
|
|
|
|
|
|
|
| |
This file is just defaulting to <nixpkgs>, but we're going to substitue
it by the channel generator. We also need to make sure that we don't
have any other references to <nixpkgs>, but the latter can best be done
on Hydra's side if we don't make <nixpkgs> available to vuizvui builds.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
|
|
|
|
|
|
|
| |
It's mainly to test whether the workspace assignment is done correctly
and if not, the screenshot on the test will be showing one of the
default workspaces instead.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
|
|
|
|
|
| |
Regression is from 903106efb392dc6235dd02523c29b3fbfed37462.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
|
|
|
|
|
|
|
| |
This is where I previously left off and I'm currently not enough "in
zone" to remember the details. But even though the tests are failing,
I'm adding it here for reference and for picking it up later.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
|
|
|
|
|
|
|
|
| |
Similar to callMachine, we now have callTest. The latter uses
make-test.nix, so we don't need to import the file explicitly anymore
and can just write our VM test by using either an attrset or a lambda
function which also gets our own packages in a vuizvui namespace.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
|
|
|
|
|
|
| |
We're going to write much more tests and don't want to clutter up the
tests/ directory.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
|
|
|
|
|
|
|
| |
Using "import ../machines" is a bit ugly here, so we might want to
integrate this into make-test.nix, but other than that it should work
nevertheless.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
|
|
|
|
|
|
| |
We already have abstracted the injection of the module list in labernix,
so we can reuse this with only minor changes.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|
|
Currently just sleeps for 20 seconds and takes a screenshot. Nothing too
fancy yet.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
|