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.
This allows unpacking files that would otherwise not be recognised as of
a particular type, such as self-extracting files supported by zip, 7z or
cabextract.
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
Looking at the implementation of builder_manifest_run(), it seems the
permissions used for flatpak-builder --run are the same as for the final
app, with the exception of filesystem permissions. So add that caveat to
the man page.
Closes: #303
Approved by: alexlarsson
The description for "dest-filename" was copy/pasted from the "file"
source's documentation for the same property. The default filename is
actually autogen.sh
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
In many cases you have a list of patches to apply, with the same
args. This allows you to do that by just listing the patches in
order, thus making the manifest more compact.
Closes: #204
Approved by: alexlarsson
This refers to the flatpak-metadata manpage for more info on the extension
metadata properties, as well as clarifying a key piece of information about
the directory property.
See flatpak#1341.
Closes: #187
Approved by: TingPing
When you're looking at the Flatpak Builder Command Reference on
docs.flatpak.org, it's not clear that it was generated from the
flatpak-builder repo. So add a notice to the docbook that's used to
generate the HTML. This was pointed out by
https://github.com/flatpak/flatpak-docs/pull/134
This will initialise a git repository with the archive's contents, to
allow us to apply git-formatted patches easily, allowing binary files
patching, file renaming, and all the advanced features offered by git
patches over plain patches.
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
Dan Nicholson