Since we now only look at changed files we need to handle
the case where a .py file changed and the .pyc didn't, and
remove the now stale .pyc files.
Previously we looked at all files, so we detected this via
the stale .pyc file.
The CLI is pretty similare to the `git bisect` one and works as follow:
$ flatpak-bisect org.app.App start # Update application and get the history
$ flatpak-bisect org.app.App bad # Sets current commit as first bad commit
$ flatpak-bisect org.app.App checkout GoodHash # Checkout the first known good commit
$ flatpak-bisect org.app.App good # Sets GoodHash as first good commit
... Here it starts bisection and checkouts a commit on the way, the user should launch the
app to check if the commit is good or bad and run:
$ flatpak-bisect org.app.App good # if commit is good
$ flatpak-bisect org.app.App bad # if commit is bad
flatpak-bisect will tell when the first bad commit is found.
Fixes https://github.com/flatpak/flatpak/issues/530
We're getting "fuse: copy from pipe: short read" from
libfuse and a broken filesystem with this. See
https://github.com/flatpak/flatpak/issues/570
I've tried to look into if this is fixable, but I can't
really find any way we could do things differently that
may help, so the fix is to disable spice_read.
In case you happen to have a reference A with a related reference
B (say a runtime and a GL extension), and they come from different
remotes, then updating A should not cause B to update from the same
remote as A, but rather the current remote.
When we update an app and add updates for all the related
operations, such as locates, and it is already installed,
make sure we inherit the current subpaths rather than
use the default ones.
Fixes https://github.com/flatpak/flatpak/issues/587
This lets you skip rebuilds unless the actual json changes.
This is useful for continuos builds that only run if the json
changes, not on any commit to any git source.
At the moment, flatpak applications are only given FamilyLocal family
xauth cookies from the Xauthority file. This is so, the sandboxed
application doesn't inadvertently get access to displays on other
computers.
But FamilyLocal isn't the only xauth family that's local. FamilyWild
entries can be local as well.
Furthermore, FamilyWild entries are preferable to FamilyLocal entries
when found, because they don't break if the system hostname is changed.
This commit makes FamilyWild xauth entries get propagated in the same
way as their FamilyLocal counterparts.
We always put the state in the .flatpak-builder subdirectory of where
you ran flatpak-builder, independent on the location of the json
manifest. This makes sense in general, but is also extra important
when we want to check out the json from git inside the .flatpak-buidler
directory.
This changes what files we look at to only those in this module,
which is generally right, but to handle the base-layer sdk
case we also have to run the python fixup in the initial layer.
If the target is the rofiles-fuse and a file is hardlinked, then
copy will fall back to truncation, which will fail with READONLY.
We work around this sometimes by deleting the destination first
and sometimes by using g_file_set_contents instead.
Instead of building directly into the app directory we build into a
rofiles-fuse mount of it, which allows us to safely check out the
cache into the app directory using hardlinks (because rofiles-fuse
will not let you modify hardlinked files).
Additionally, every time we commit to the cache we check out all
the new and modified files into the appdir so that we get hardlinks
to the repo for the new files too.
The advantage of having hardlinks to the repo is that we can commit
much more efficient since we don't have to do a full checksum of
the hardlinked files.
There are some issues here:
eu-strip fails due to doing in-place editin
rofiles-fuse is using lots of CPU, unclear if this is faster, needs
measurements
needs testing of how well the fallback works (ie. if fuse is not
working).
rofuse: use kernel caches
rofiles: check out after commit
Use devino cache
Only check out new files from cache after commit
So far, the installation of external apps can only be cancelled
before flatpak starts downloading the extra data, as there's no
cancellable being passed to g_input_stream_read_async().
This fixes that problem, making it possible to cancel installs
from GNOME Software regardless of the installation stage.
Otherwise, clients such as GNOME Software won't be able to report
any progress once the flatpak application has been downloaded and
we enter the stage to download the extra data.
Otherwise, all the progress reporting for the extra data being downloaded
won't work, as the main context used by OstreeAsyncProgress will not be
the same than the one from the nested main loop used to download this.
It turns out that it is impossible for to get ptrace capabilities
for child user namespaces in the current kernel if the user
namespace is created as root, which is what happens when bwrap
is setuid root (see https://github.com/flatpak/flatpak/issues/557
for details).
This is very problematic, as ptrace rights controls access to
/proc/$pid/root which is what we base the detection of peer
app id and rights on for portals.
For now, we disable user namespaces (except for the case of
unprivileged user namespaces, where it is necessary and works).
