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
This pulls in the renameat2() fix that's required for building with
latest glibc (e.g. Fedora rawhide).
Closes: #182Closes: #185
Approved by: alexlarsson
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
Using g_load_contents () for the checksum computation uses a lot of memory
(for large files) and actually fails for files larger than 4 GiB. Instead,
this implementation uses GInputStream to read the file in small buffers
and feeds the GChecksum manually.
Closes: #165
Approved by: alexlarsson
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 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
In the Fedora 28 base container, `coreutils-single` is used and so
`/usr/bin/ls` is actually a "script":
```
$ file /usr/bin/ls
/usr/bin/ls: a /usr/bin/coreutils --coreutils-prog-shebang=ls script, ASCII text executable
```
We handle this by detecting shebangs in dependencies and recursively adding them.
Closes: #163
Approved by: alexlarsson
A commonly used CI workflow [1] is to chain the following steps:
> flatpak-builder --stop-at=<module>
> flatpak build <commands to build module from local checkout>
> flatpak-builder --finish-only
Unfortunately, the last step always purge all the compilation cache
created by the first one. All build steps are marked unused by default
and since they are skipped due to the option --finish-only, all of them
are always pruned by the gc function.
As a result, flatpak-builder cache becomes useless, a full compilation
is always performed.
Improve this by not cleaning unused stages when no compilation is done
by flatpak-builder (i.e: when flatpak-builder is used with --export-only
or --finish-only option).
[1]: https://gitlab.gnome.org/GNOME/Initiatives/wikis/DevOps-with-Flatpak
As reported in
https://bugzilla.gnome.org/show_bug.cgi?id=796031#c1
we sometimes hang in libsoup downloading stuff. This uses
an early type initialization to avoid that.
We don't use libsoup for the main download anymore, but
its still used for some things, so better safe than sorry.
Closes: #153
Approved by: alexlarsson
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
P. F. Chimento