Make sure we can only send message calls (not e.g. unicast signals)
to the bus. Also, whitelist the list of allowed interfaces to
org.freedesktop.DBus and org.freedesktop.DBus.Introspectable
See https://github.com/flatpak/flatpak/issues/343 for the origin
discussion of this.
When initializing a build you can initialize the application directory
with the files from another directory, and optionally a set of its
extensions. This allows one to create a "base" application that
can be derived from in multiple forms. A typical example is an application
framework like Electron. The base electron app has all the dependencies
needed to write Electron app, and then your manifest can add the specific
files needed for your application.
An example snipped could look something like:
"base": "org.base.App",
"base-version": "stable",
"base-extensions": ["org.base.app.Locale", "org.base.app.Debug" ],
The --allow-missing-runtimes options will allow flatpak builder to
not abort immediately if the sdk or runtime for the app being built
are missing.
This option will be useless when building anything in the modules
section of the app manifest. The calls to flatpak-build will fail
because of the missing sdk.
However, it may be useful when an application does not require
building anything inside the sandbox, and the application files
will be installed via other means.
Provides access to the functionality offered by the new internal API
flatpak_dir_update_remote_configuration(), in a similar way to what
can be done via the command 'flatpak remote-modify --update-metadata'.
This new command relies on flatpak_dir_update_remote_configuration()
and allows updating the local configuration for the remotes based on
the extra metadata present in the OSTree repo's summary file.
This parameter can still be combined with --title and --default-branch,
which take precedence when combined with --update.
The new function flatpak_dir_update_remote_configuration() can be called
to fetch the contents of the summary file from the remote's source location
and update the local configuration in the installation directory accordingly.
For now, only the xa.title and xa.default-branch configuration parameters
are supported, since those seem to be the only relevant ones at the moment.
If no branch is explicitly stated when installing a flatpak, and several
options (branches) are available for the same ID, we now check the remote's
default branch and use that one, if it's defined and available for the app.
https://github.com/flatpak/flatpak/issues/221
Add support for this flag in build-update-repo, so that we can define
a default branch in the server side, to be picked by the clients.
https://github.com/flatpak/flatpak/issues/221
Just like we do with the title, fetch the default-branch from the
repository's summary file and use that information when adding a
remote reference from the command line.
https://github.com/flatpak/flatpak/issues/221
We can't fetch the extra metadata from a repository's summary file before
having added it locally, since ostree_repo_remote_fetch_summary() will
fetch data by remote's name, and for that it needs to be added first.
Instead of using "NAME [BRANCH]" as the command list we now
support REF..., where each REF can be partial. This is easiest
explained by examples. Here are some valid refs:
org.test.App - only app id
app/org.test.App/x86_64/stable - full ref
org.test.App/x86_64/stable - full ref without prefix
org.test.App - only app id
org.test.App//stable - only branch
org.test.App/x86_64 - only arch
If any parts are left out they are wildcarded. Such parts are filled
first by looking at other command line arguments like --arch and
--app/--runtime. And finally by looking at what is available in the
remote. If there are multiple matches the user is told the options
in an error message.
It is allowed to make a self-executable zip, it will then be an ELF file
on Linux. The problem is that the current stripping code somehow breaks
that file (i.e. ./file.zip doesn't work anymore after stripping).
Signed-off-by: Niv Sardi <xaiki@endlessm.com>
For now this is a purely client side setting which lets you store
the default branch to use for a remote. This is mostly meant to
be used for UI tools, although the CLI could also be made to use this.
You can set this manually in the CLI with --default-branch, or via a
flatpakrepo file (new key DefaultBranch).
It turns out that live apps were exporting files with dashes
other than "-symbolic". For instance "org.libreoffice.LibreOffice" was
exporting "org.libreoffice.LibreOffice-writer.desktop".
Allowing any dashes in the last segment like this is really no diffent
than allowing org.libreoffice.LibreOffice.writer.desktop which we
already do. Any conflicts here are under the control of the owner
of the org.libreoffice prefix.
However, allowing dashes in the earlier segments is more problematic.
For instance, any file exported by "org.my-foo.App" could conflict with
an app called "org.my" if this was allowed.
So, as a middle ground, we're allowing dashes in the last segment of
the App id only.
This adds a new "multiarch" feature which allows bundling e.g. 32-bit
binaries to be run in a x86_64 environment. By default, the seccomp
filter is configured to allow only the native architecture. When the
"multiarch" feature is enabled, the filter will be configured to allow
running binaries of additional architectures supported. For x86_64, this
allows x86 32-bit binaries; and for Aarch64, allows 32-bit ARM binaries.
Application bundles can use the feature e.g. in order to ship 32-bit
binaries alongside with a mostly-64-bit application. This is particularly
interesting when for applications that might launch themselves prebuilt
programs for which 64-bit versions do not exist. For example, the Steam
application is available as a 64-bit executable, but some of the games
available are 32-bit only. A Flatpak bundle for the Steam application
with "multiarch" enabled is able launch the 32-bit games -- without the
feature enabled, the seccomp filter would prevent them from running.
Multiple-architecture support is enabled by adding the "multiarch" value
for the "features" key in the metadata file for a Flatpak:
[Context]
features=multiarch;
The corresponding "--allow=multiarch" command line option is supported
in "flatpak build-finish" as well.
This completely regressed, and it seems complicated to fix it without
requiring extra privileges. So, the new version requires you to sudo
to run it, which is not great, but at least it makes it work for
all cases.
