It uses inline for loop initialisers, which are a C99 feature. Set
-std=gnu99 like ostree.git does for its libglnx submodule.
Based on a patch by Georges Basile Stavracas Neto
<georges.stavracas@gmail.com>.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
For example, add $(AM_CFLAGS) to mumble_CFLAGS. Since $(WARN_CFLAGS) is
only added to $(AM_CFLAGS), this fixes the lack of inclusion of the
compiler warning flags in the compilation of half of flatpak.
Note that $(AM_*) variables are only used by automake if a more specific
(per-target) special variable is not defined instead. So if you define
mumble_CFLAGS, AM_CFLAGS will not be used for that target unless
explicitly included in mumble_CFLAGS.
See
https://www.gnu.org/software/automake/manual/html_node/Flag-Variables-Ordering.html.
Do the same for $(AM_LIBADD), $(AM_LDFLAGS), etc. These are not
currently defined, but it’s good practice to include them in
mumble_LIBADD (etc.) just in case they’re defined in future. Hopefully
their inclusions will be cargo-culted to any new targets which are
added, retaining full coverage of the code base.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
This ensures it’s always included in the build, regardless of whether
someone forgets to #include it from a C file.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
In ostree I maintain what I consider a "baseline" set of compiler
warnings that should *always* be fatal for a modern C project.
I noticed while working on a previous patch that a `-Werror=format`
warning wasn't fatal.
There are a few that are really, really important like
`-Werror=missing-prototypes`. I also take some like `-Werror=misleading-indentation`
which already caught some bugs. See also https://lwn.net/Articles/678019/
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
If EXTERNAL_INSTALL_DIR wasn't defined (which is likely, since nothing
in the build system does), then we would tell the system helper
to search /exports/share, which is not Flatpak's territory
(but is a semi-commonly-used path for site-specific NFS shares,
which might have contents that are inappropriate to search here).
Installations that do define an external installation directory
(Endless OS?) can easily override the Environment to include it
by placing a drop-in in
/etc/systemd/user/flatpak-system-helper.service.d/external.conf
or similar.
Typically Linux distributions employ /etc/profile.d for system wide
environment manipulation prior to multi-user initialisation. Modern
distribution efforts split the vendor configuration from the local
sysadmin configuration and data, by not using the /etc/ directories,
for example.
To enable this stateless pattern, this change adds a new --with-profile-dir
option to use an alternative location, such as within /usr/share/. This
ensures that the data (not configuration) is owned through the update
process, and does not conflict with changes made locally to the system,
enforcing domains of ownership.
To preserve backwards compatible behaviour, the default directory remains
set to /etc/profile.d.
Signed-off-by: Ikey Doherty <ikey@solus-project.com>
flatpak currently installs a gdm env.d and a bash profile.d file to
ensure XDG_DATA_DIRS is set to the right value. Neither is sufficient
when the dbus daemon is activated as a system --user service.
This commit adds a dbus service file snippet to frob its environment
variable for that case.
When the document portal is called from within the sandbox with an
app-private file path, translate the path to a document portal URI in
order to make it available to other applications.
This lets distributors share a system copy of bubblewrap (>= 0.1.0)
between Flatpak and any other projects that benefit from it, if they are
careful to keep new versions in sync. The default is still to use the
bundled submodule, ensuring compatibility and simplifying dependencies.
Enable $PATH search everywhere that runs bwrap, so that $BWRAP doesn't
necessarily need to be a fully-qualified path.
Signed-off-by: Simon McVittie <smcv@debian.org>
We shouldn't install .test metadata for these, and run them as TAP
test scripts. In glib-tap.mk jargon that makes them "extra scripts".
Signed-off-by: Simon McVittie <smcv@debian.org>
As explained in bubblewrap commit f6ca3690, libraries should
always go in LDADD and not LDFLAGS, because the order of arguments
to the linker matters. Many distributions' linkers are tolerant
enough that it doesn't matter in practice, but it matters for
static linking, and it might also matter on Ubuntu.
Signed-off-by: Simon McVittie <smcv@debian.org>
Listing variables whose values are conditional in EXTRA_DIST is
problematic: if Flatpak was configured without installed-tests,
we would not distribute those files. This is a problem during
distcheck, where installed-tests are disabled.
For files not placed in a special subdirectory, glib-tap.mk handles
this for us. For the keyring and the databases, we have to do it
ourselves, by arranging for them to be in a dist_ variable that is
special to Automake - when determining what to distribute, Automake
includes anything that is selected for distribution under any
combination of conditionals.
While I'm here, include test keyring's README in tarballs: its advice
is equally applicable in a tarball release.
Signed-off-by: Simon McVittie <smcv@debian.org>
According to the FHS, applications which place internal libraries in
/usr/libexec should not also use /usr/lib for this purpose:
http://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch04s07.html
As several flatpak helpers are already installed in libexecdir, move
the bwrap helper to /usr/libexec/flatpak-bwrap.
Bubblewrap is a new tool from project atomic. Its similar to the old
xdg-app-helper, but even more minimal, and a bit more generic. Its designed
to be easy to git submodule install, but at some point we will probably
support using the system installed version too.
Using bubblewraps lets us share the load of security mainainance and
allows other people to use bubblewrap to do their own unprivileged
sandboxes.
The FHS specifies a limited number of subdirectories for /var,
which do not include xdg-app. Packaging systems like RPM and dpkg
use a subdirectory of /var/lib, so it seems appropriate for system-wide
xdg-app runtimes and apps too.
Signed-off-by: Simon McVittie <smcv@debian.org>
Alexander Larsson