Provide a --token-type command line option and a token-type manifest
property that allows passing the token type to build-export. The
manifest property takes precendence over the CLI option. In either case,
the value will be passed to build-export if it's >= 0. This requires
flatpak >= 1.6 to use the --token-type option in build-export.
If two modules happen to have the same name we uniquify them by
appending "-$n". While you shouldn't normally rely on this it is
sometimes hard to avoid when you're including some json snippet you
don't have control over.
Closes: #308
Approved by: alexlarsson
We want to use this in flathub to avoid all the problems we've having
parsing json manifests via the python parser, which isn't *quite* compatible
with json-glib (differs in comment and multiline string support for instance).
Closes: #307
Approved by: alexlarsson
This means when flatpak-builder runs a flatpak command in a subprocess,
we can see the arguments passed to flatpak in the flatpak-builder
output, if -v was used.
Closes: #291
Approved by: alexlarsson
This splits the platform creation into 3 parts:
* base - create the initial directory based on the parent platform
* prepare - run prepare commands and apply all changes
* cleanup - apply cleanups and cleanup commands
This has cacheing advantages in that prepare_commands and cleanup changes
only cause the minimal amount of rebuilds.
Additionally, it ensures that the mtimes are zeroed out (from the
previous checkout) both when the prepare and cleanup commands are run.
This is actually important, since these often generate caches (for
example fontconfig ones) which rely on zeroed mtimes so they match
what will be deployed.
Closes: #277
Approved by: alexlarsson
It turns out that newer flatpaks changed the output of flatpak info
and we relied on parsing that due to the lack of --show-location option
to flatpak info. However, that has been added since flatpak 0.11.8, so
just use that instead of parsing it.
Closes: #270
Approved by: alexlarsson
We were printing argv[3] which is wrong (and typically null).
Instead set the error message where it happens and we know
what we were trying to do.
Closes: #269
Approved by: alexlarsson
This is similar to branch and used if branch is not set. However, this
key (as opposed to branch) is overridden by the --default-branch option.
The idea is that most apps in flathub would use default-branch=stable, so
that a standart flatpak-builder command will build a "stable" release.
However, when building a test build we can use --default-branch=test to
override that. Then special cases like theme extensions and other things
that require a specific branch value to work at all can use branch="1.0".
Closes: #264
Approved by: alexlarsson
This add custom (de)serialization code for the source, module and manifest
objects so that properties starting with "x-" are kep and then put back
in the manifest.
We also add a checksum of the manifest to the "finish" phase so that
if you change them the manifest is re-generated.
Closes: #203
Approved by: TingPing
This also changes the <id> rewriting to use the non-desktop suffixed version of
the application ID as this has been deprecated now the launchable tag exists.
Applications shipping an appdata file without a launchable set will have one
auto-added at runtime based on the appstream <id>.
This copies FlatpakXml from the flatpak project.
Fixes https://github.com/flatpak/flatpak-builder/issues/155Closes: #164
Approved by: alexlarsson
When downloading only we will not be building, so we can skip all the checks for dependencies
and for the state-dir properties.
Closes: #145
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 adds a section to the main metadata like:
```
[Build]
built-extension=org.the.App.Locale;
```
This can be used to figure out what refs where built that are
related to the app, for example if you want to bundle them all.
Closes: #128
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 allows you to run --install-from-deps=foo -y to always install all
dependencies. Useful for auto-builders like flathub.
Closes: #107
Approved by: mwleeds
This allows us to be run from inside of a flatpak application and
successfully build by proxying the flatpak commands to the host.
Closes: #100
Approved by: alexlarsson
This allows us to pass it through in the case we're running in the same
pid namespace as the flatpak-builder process.
Closes: #100
Approved by: alexlarsson
In this case we will exec rather than fork + exec, so we don't
want to use prctl, as that can cause the app to die if any
*thread* in the parent dies (rather then the whole process).
In particular, this caused issues for gnome-builder starting
a newly built flatpak:ed app.
Closes: #51
Approved by: alexlarsson
We find these either in the appdata or the metainfo directory.
However, we always move it to the appdata dir with the appdata
extension, because that means older versions of appstream-compose
will always pick it up.
Closes: #44
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
Dan Nicholson