- Jul 20, 2021
-
-
Simon McVittie authored
This was only necessary because we were reusing a single container across multiple entry-point invocations, and expecting "most" arbitrary environment variables from each new invocation to be taken into account for commands running in the container, which meant that we needed to keep track of which environment variables had to be exceptions to that rule for technical reasons. Now that we're no longer injecting multiple commands into the same container like that, we don't need this complexity. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Jul 05, 2021
-
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Jan 05, 2021
-
-
Ludovico de Nittis authored
This is especially useful when we are logging to a file to keep track of when a specific operation happened. Signed-off-by:
Ludovico de Nittis <ludovico.denittis@collabora.com>
-
Ludovico de Nittis authored
This is the middle ground between the base logging and the verbose option. Currently we are not logging any messages at the info level, but we might start to do that. And this option gives us more granularity about how much logging we want to print. Signed-off-by:
Ludovico de Nittis <ludovico.denittis@collabora.com>
-
- Oct 01, 2020
-
-
Simon McVittie authored
pressure-vessel-wrap unsets PWD, but we don't want the command to inherit a value of PWD from the launcher. In particular, when running in session mode, the launcher's $PWD is the Steam installation, typically ~/.local/share/Steam, and the setup commands are also run with that working directory, but the actual game is run with the current working directory set to its own game directory (which we didn't necessarily even know at the time that the launcher was started). Consumers of $PWD should really check that it is equivalent to the actual current working directory and ignore it if it does not, like GNU get_current_dir_name(3) and our pv_get_current_dirs() do, but blindly believing $PWD is a common shell-scripting mistake, and I wouldn't be surprised if there are some games whose launcher scripts will believe $PWD even when it doesn't coincide with the real working directory. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Ludovico de Nittis authored
If we want to pass all the possible variables that a user might have set in its environment, we need a mechanism to lock the variables that pressure-vessel is editing (e.g. LIBGL_DRIVERS_PATH), variables that we want to keep unset because will be wrong in the new container (e.g. FLATPAK_ID) and variables that should inherit their value from the host system (e.g. DISPLAY). Signed-off-by:
Ludovico de Nittis <ludovico.denittis@collabora.com>
-
- Sep 09, 2020
-
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Sep 08, 2020
-
-
Simon McVittie authored
bwrap(1) holds stdin, stdout and stderr open, so we need to do this on a different fd. Resolves: pressure-vessel#6 Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Aug 04, 2020
-
-
Simon McVittie authored
This allows a controlling process to terminate the launcher, even if it is wrapped in an "adverb" command like pressure-vessel-wrap that makes it non-straightforward to send signals to the launcher. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
See the new pressure-vessel-launcher(1) man page for details. We need this for Proton games, where running a game takes several steps. At the moment each step is its own container, which means they can't share locks, IPC sockets and other state. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-