This is a more generic way than sdk-default-override to change how the various
flag fields are overridden. Now you can override both the sdk default as well as
in-file options.
Closes: #150
Approved by: alexlarsson
This adds a source type that copies an entire directory, optionally skipping
some files. Additionally it also skips the .flatpak-directory dir and
the build dir to avoid weird recursion.
Since we can't really checksum an entire directory a dir source is always
rebuilt.
Closes: #136
Approved by: alexlarsson
This adds add-build-extensions which is similar to add-extensions
except the extension is added at build-init time, so can be
used during the build. It can also optionally be removed after
the build is done.
This depends on the flatpak work in:
https://github.com/flatpak/flatpak/pull/1598
With this I was able to build the following app which runs 32bit binaries
in a 64bit build:
```
{
"app-id": "org.example.Multilib",
"runtime": "org.freedesktop.Platform",
"sdk": "org.freedesktop.Sdk",
"runtime-version": "1.6",
"command": "/usr/bin/true",
"add-build-extensions": {
"org.freedesktop.Platform.Compat32": {
"directory": "lib/32bit",
"add-ld-path": "lib",
"version": "1.6"
}
},
"modules": [
{
"name": "test 32bit",
"buildsystem": "simple",
"build-commands": [
"ln -s /app/lib/32bit/lib/ld-linux.so.2 /app/lib/ld-linux.so.2",
"/app/lib/32bit/bin/echo echoing from 32bit world"
]
}
]
}
```
Closes: #129
Approved by: alexlarsson
This passes an --extension-tag to flatpak build-init which will
set the "tag" option on the ExtensionOf section in the metadata.
Closes: #126
Approved by: alexlarsson
This is similar to inherit-extensions, but the extensions
are not also inherited into the platform when it is created.
Closes: #121
Approved by: alexlarsson
This is useful for example if you're using a sdk-extension that
is supposed to override some binaries from /usr/bin.
Closes: #119
Approved by: alexlarsson
This allows you to build and install the result in a single operation.
If a --repo is given the app is installed from there, otherwise we
build-export it to the flatpak-builder cache repo, which already has
all the objects that are needed in it, so this will not increase
disk-use.
Closes: #81
Approved by: alexlarsson
This allows inclusion of sources from an external json source similar
to how we do it for modules.
For example, you can use:
"sources": [
{
"type": "shell",
"commands": [ "echo BEFORE include" ]
},
"include.json",
{
"type": "shell",
"commands": [ "echo AFTER include" ]
}
]
with include.json containing:
[
{
"type": "shell",
"commands": [ "echo Shell 1" ]
},
{
"type": "shell",
"commands": [ "echo Shell 2" ]
}
]
This is very useful in the case where the included file is
auto-generated from some other source, such as an npm lockfile.
Closes: #77
Approved by: alexlarsson
* Add more checksum types for files and archives
Many upstreams don't use sha256, some use even stronger checksums like
sha512, and its nice to be able to use these. Some system uses
weaker checksums, which you can work around by recomputing your own,
but sometimes that is a bit painful, for example when you're
auto-generating flatpak-builder manifests based on some other format
such as npm lock files.
This adds all the checksum types that GChecksum supports in the
glib version we currently use: md5, sha1, sha256, sha512
Modules that say "run-tests": true, will run tests after installation,
unless disabled by --disable-tests.
The tests run by default are make check or ninja test, however you
can control the make/ninja target with test-rule, or supply a list
of commands with test-commands. There is also a test-args argument
in build-options, which you can use to give e.g. network access.
The tests are run with readonly access to the install directory, so
they cannot affect the build results.
Closes: #65
Approved by: alexlarsson
This uses eu-elfcompress to compress the debuginfo. We use the older
zlib-gnu compression format which is older and has more widespread
support.
Closes: #43
Approved by: alexlarsson
All this does is construct a finish arg, but it makes it a lot nicer
to create extra-data using manifest. Additionally, it allows you to
create per-arch extra data if you set only-arches on the source.
Closes: #40
Approved by: alexlarsson
This lets you modify the project_license field in the appdata file.
This is useful because appdata files from upstream generally only
contain license information for the app itself, whereas the
bundled app may contain other code with additional licenses.
Closes: #41
Approved by: alexlarsson
This takes a list of properties and generate finish arguments.
Additionally you can specify "bundle": true, which causes f-b to emit
an actual extension implementation, similar to e.g. the locale
and debuginfo extension.
This makes sure we always delete build dirs, even if there
was a build failure. This is useful for automatic build systems
like flathub or continuous integration.
This fixes https://github.com/flatpak/flatpak/issues/646
In order to provide a transition path for repositories to add collection
IDs to themselves and propagate those collection IDs to clients’ remote
configurations, add another repo config key which controls whether the
repository’s collection ID is published. If xa.collection-id is set in
the repo’s published metadata, the client will update its configuration
to the given ID — but only if no ID is set already. This is a one-time
transition to prevent malicious repositories from remotely changing the
user’s configuration to associate their remote with a well-known
collection ID they don’t own.
Add a test for this.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Add support for collection IDs to the code which finds and pulls
related refs and other extensions.
Currently, related refs must have the same collection ID as the parent
ref — this is the most likely scenario anyway. In future, it should be
possible to extend the code to support pulling related refs from other
collections.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
In order to eliminate some race conditions around updating the
summary{,.sig} file on the server, and to decouple signing the summary
from signing commits, and to support peer to peer mirrors of content
from multiple upstream collections: add support for unsigned summary
files.
This relaxes the requirement for gpg-verify-summary=true iff
collection-id is set in a remote’s local configuration. It depends on
some pending libostree changes to verify the ref for each commit using
the commit’s signed metadata. See
https://github.com/ostreedev/ostree/issues/983.
Metadata storage has moved from the summary file to a new
ostree-metadata well-known branch on each repository, since this can be
signed for each update and for each collection separately. If the
collection-id is set in a remote’s local configuration, flatpak will
retrieve all repository metadata from this branch rather than from the
summary file. If collection-id is unset, it will ignore this branch and
continue to use the summary file, which will continue to be updated (and
externally signed as summary.sig) for backwards compatibility.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Pass a --collection-id argument through to `flatpak build-export`.
Also add a ‘collection-id’ property to manifest files, which can be used
to set the collection ID on an exported repo (when using --repo) without
having to provide a command line option.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
This allows you to automatically install/update dependencies required
by the manifest. The dependencies include:
Runtime, Sdk, Base, Sdk Extensions and Platform Extensions
There is also a --install-deps-only switch to make the build
stop after the dependencies are installed.
Fixes https://github.com/flatpak/flatpak/issues/955
Denis Ollier