Bazaar-NG (bzr) relies on Python 2, which has reached end-of-life, and
appears to be essentially unmaintained itself. Try using Breezy (brz),
a "friendly fork" of bzr that has been ported to Python 3 and is
maintained.
Signed-off-by: Simon McVittie <smcv@debian.org>
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.
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
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
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
Shallow clones only contain the ref that was cloned, and so if a
mirror is shallow and the ref is changed in a subsequent invocation of
builder, the new ref is absent and git fails with an error.
This patch avoids bailing out too soon when mirroring a repo if the
requested ref does not exist, to ensure it is fetched.
Fixes#285Closes: #286
Approved by: alexlarsson
If we are spawning applications on the host using the Development service,
then we want those commands to exit when the flatpak-builder process
exits, as can happen from Ctrl^C or kill().
By using a static FlatpakHostCommandFlags we only ever check this a single
time and then each subsequent request will do the right thing.
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
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
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
Matthew Leeds