Currently flatpak-builder downloads the sources for all modules, even if
the --stop-at option prevents them from being built. This commit changes
the behavior so that we don't bother to download the ignored modules.
This commit checks if <revision>:.gitmodules exists in the repo before
calling git-show on it, so an error message doesn't show up in the
program's output.
An app id like org.domain.App-name is now allowed (dashes in the
last element), but blindly appending e.g. ".Locale" to these
for the locale extension will cause an invalid id.
In order to handle this we replace "-" with "_" in this case, which
should be fine as both are under the org.domain control which can
make sure there are no conflicts, and there is no requirement for
the id prefixes to exactly match.
This fixes https://github.com/flatpak/flatpak/issues/370
It can happen, like in https://github.com/flatpak/flatpak/issues/353
that there are references in the source to the absolute source path.
We need to ensure that is visible in the build. We mostly do this,
but for technical reasons it didn't get the same pathname when
the source was inside a symlinked directory. We fix this with an
extra bind-mount to the symlinked directory name too.
This fixes https://github.com/flatpak/flatpak/issues/353
When initializing a build you can initialize the application directory
with the files from another directory, and optionally a set of its
extensions. This allows one to create a "base" application that
can be derived from in multiple forms. A typical example is an application
framework like Electron. The base electron app has all the dependencies
needed to write Electron app, and then your manifest can add the specific
files needed for your application.
An example snipped could look something like:
"base": "org.base.App",
"base-version": "stable",
"base-extensions": ["org.base.app.Locale", "org.base.app.Debug" ],
The --allow-missing-runtimes options will allow flatpak builder to
not abort immediately if the sdk or runtime for the app being built
are missing.
This option will be useless when building anything in the modules
section of the app manifest. The calls to flatpak-build will fail
because of the missing sdk.
However, it may be useful when an application does not require
building anything inside the sandbox, and the application files
will be installed via other means.
It is allowed to make a self-executable zip, it will then be an ELF file
on Linux. The problem is that the current stripping code somehow breaks
that file (i.e. ./file.zip doesn't work anymore after stripping).
Signed-off-by: Niv Sardi <xaiki@endlessm.com>
Instead of expecting the second word to be "commit", we should do like
git does and check for the file mode, which is 160000 for gitlink trees.
cda1bbd474/cache.h (L96)
This way you can e.g. do network i/o in them.
Thats not a recommended way to do it though, as you work around
a lot of the feature in flatpak-builder like the caching and
verification.
Some projects declare their Git submodules with URLs relative to their
own.
For example, gedit is hosted at git://git.gnome.org/gedit, and has its
libgd submodule declared with the ../libgd URL. We should treat the
latter as git://git.gnome.org/libgd.
This was in fact properly done in the past, but I broke it in commit
1171e1d202.
This fixes it again.
This disables build-args support, which is nice when building things
on e.g. a shared build-machine, where we don't want the build to
be able to break out of the sandbox (by specifying e.g. --share=network).
This replaces all current callers of gs_file_ensure_directory with
equivalent code.
Actually, two instances were calling gs_file_ensure_directory with
FALSE, i.e. error out on EEXIST, but those cases seem fine with the
do-nothing-if-exists semantics.
Stop building at a specified module from the json file.
This is useful during development. For instance, you can do --stop-at=main-app
to build all the dependencies into the appdir, then you can do a build of an
already checked out git repo (possibly with changes).
We were not doing what the comments said we should, and we also
want to change what happens in the case of an old py file from
a previous layer (such as a base layer in a runtime) has a non-rewritten
.pyc file. In that case we want to assume its correct and fix it up.
If a .py file changes multiple times we can end up in a situation
where there is an .py file with corresponding .pyc file that we
rewrote, so both are now mtime==1. Then a new version of the .py file
is added, but the corresponding .pyc file is not updated. This means
that the .pyc file is stale, and python would not normally use it.
However, we will later change the mtime on the .py file to 1, causing
the old .pyo file to look up-to-date even though its stale.
We fix this by detecting the case where the is a new mtime on a .py file
where the .pyc file doesn't match, and remove the stale .pyc file.
Alexander Larsson