- Aug 06, 2021
-
-
Simon McVittie authored
We need to do this as highest-priority, since it invalidates the cleverer reasoning that we should be applying to LIB and PLATFORM. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
This doesn't make any practical difference yet, but it sets us up to be able to carry out finer-grained processing based on the loadable_flags. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
FlatpakExports isn't going to export relative paths anyway. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
In reality, we have a FlatpakExports if and only if we are not creating a Flatpak subsandbox. If a caller somehow passes in a FlatpakExports while creating a subsandbox, it's harmless to tell it what to export. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Most of this code can be shared between the Flatpak and non-Flatpak code paths, avoiding internal duplication. In future, we will also want to call into append_preload_internal() when we split up something like /usr/$LIB/mangohud/libMangoHud.so or /opt/plat-$PLATFORM/mypreload.so into a separate path per supported architecture: in such cases, we will still have to rewrite /usr into /run/host/usr, and add /opt/plat-*/mypreload.so to the FlatpakExports. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
An entry in LD_PRELOAD may be a bare SONAME like "libMangoHud.so", or a path containing special tokens like "/usr/$LIB/libMangoHud.so", or a literal path. Only literal paths are going to physically exist on disk. For a path containing special tokens, we can still try to remap it, for example /usr/$LIB/libMangoHud.so to /run/host/usr/$LIB/libMangoHud.so. This is imperfect (if the host and container glibc disagree on the meaning of $LIB, then we won't load it correctly), but it's better than nothing. A subsequent commit will improve the handling of paths that contain special tokens. For a bare SONAME, we just pass it through as-is for now, as though it was a relative path. This is also imperfect, but better than nothing. Another reason to want to make this change is that it allows us to unit-test this function: it's difficult to make assertions about the behaviour of a function that touches areas of the filesystem that are not under the control of the unit tests. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
This allows mock environment variables to be used during unit testing. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
This reduces the size of wrap.c, which is something we should be careful to keep under control. It also allows us to unit-test this code. Code changes made while factoring this out: * `flatpak_subsandbox` and `opt_remove_game_overlay` go via flags * `adverb_preload_argv` becomes `argv` * `return` instead of `continue` since pv_wrap_append_preload() is only one loop iteration Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Jul 20, 2021
-
-
Simon McVittie authored
This neatly separates the processes for the game (which can be numerous, for example for Proton games that need to run wineserver and winedevice.exe) from the processes for Steam. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
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>
-
- May 17, 2021
-
-
Simon McVittie authored
This gives us direct access to Pipewire using its native protocol, similar to the direct access we already have to PulseAudio, X11 and Wayland. In a Flatpak subsandbox, applications will have to go via xdg-desktop-portal instead, as they do for any other Flatpak app. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Mar 11, 2021
-
-
Simon McVittie authored
If we're not using a runtime, then all of /run/systemd is shared between host and container anyway. Mounting a socket over the top of an existing socket fails with "No such device or address" due to a bubblewrap bug (fixed in <https://github.com/containers/bubblewrap/pull/409 >). Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Mar 03, 2021
-
-
Ludovico de Nittis authored
nss-resolve uses systemd-resolved to resolve hostnames and, since systemd 247, it utilize the varlink API. To make it run inside the container we need to expose the varlink socket. Check the upstream commit for more info https://github.com/flatpak/flatpak/commit/e5da98ff4b12a080044d58b4cd2fb4edb4491132 Fixes: #61 Signed-off-by:
Ludovico de Nittis <ludovico.denittis@collabora.com>
-
- Feb 25, 2021
-
-
Simon McVittie authored
wrap.c is generally too big, and so is main() specifically. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
wrap.c is generally too big, and so is main() specifically. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-