From @moosingin3space on February 6, 2017 17:38

When I read the documentation for flatpak-builder, I see that it wants a project to support the Build API. Rust applications that build with Cargo don't fit as nicely into this mold. I'm curious what the expectation is for a non-standard build system. Should the build system be extended to produce Flatpaks itself, or should flatpak-builder be extended to support arbitrary build systems, in a similar manner to Arch Linux PKGBUILDs?

Copied from original issue: flatpak/flatpak#536

I wanted to install an application before which I needed to install FlatPak. Installation went normally without any issue but I needed to run this command:

flatpak remote-add --if-not-exists --from gnome https://sdk.gnome.org/gnome.flatpakrepo

which gave me this error:

error: While opening repository /var/lib/flatpak/repo: Invalid UTF-8

I couldn't find anything on the web regarding this error. May you please help me to understand what the problem is?
Thanks in advance.

Running Kubuntu 17.04 64-bit

From @Jehan on February 13, 2017 1:40

Trying to work around another bug of flatpak, I tried to add a "script" source and I put it before the "git" source in the list. When it came to building the module, I got:

========================================================================
Building module gimp in /home/jehan/gimp/build/flatpak/.flatpak-builder/build/gimp-8
========================================================================
fatal: destination path '/home/jehan/gimp/build/flatpak/.flatpak-builder/build/gimp-8' already exists and is not an empty directory.
Error: module gimp: Child process exited with code 128

I understand the issue: flatpak tries to clone the git directory which requires no directory or an empty one. I would propose to either make it possible (clone in a temporary directory and move all files after for instance), or at least write down in the documentation that if a module has multiple source, and among them there is a git source, it has to be first in the list.

Copied from original issue: flatpak/flatpak#555

In order to not rebuild my dependencies all the time, I let CI cache the .flatpak-builder directory. This results in the following crash though:

Starting build of org.wxformbuilder.wxFormBuilder
Cache hit for wxWidgets, skipping build
�]2;flatpak-builder: Updating wxWidgets�Cache miss, checking out last cache hit

(flatpak-builder:266): flatpak-builder-ERROR **: Failed to check out cache: fgetxattr: No data available
./flatpak.sh: line 8:   266 Trace/breakpoint trap   (core dumped) flatpak-builder --repo=repo ./build org.wxformbuilder.wxFormBuilder.json

See https://travis-ci.org/wxFormBuilder/wxFormBuilder/jobs/296809091

Would be great if flatpak-builder could handle that situation.

When running applications from Builder, we are using flatpak-builder --run --allow=devel $builddir manifest.json. I'm seeing two strange cases that I'd love some insight on which may be more obvious to you.

The first time we run the application, it exits immediately. If we run the application again, it starts up fine but after about 20 seconds it exits. It is very easily reproducible.

if I run the developed application in jhbuild instead of using the flatpak runtime, everything is fine.

This happens for any Gtk application.

From @Jehan on February 13, 2017 2:47

To temporarily bypass another bug of flatpak, I made a temporary script inside the source directory of a module and in "build-options" > "env", I tried to update $PATH this way:

"PATH": "$PWD/tmp-bin:$PATH"

But it failed immediately and autogen.sh was just unable to find any command.
Fortunately that was quite easy to bypass since we are in a very static environment and we know that PATH is "/app/bin:/usr/bin" by default, so I could set instead (module being named "gimp"):

"PATH": "/run/build/gimp/tmp-bin:/app/bin:/usr/bin"

Yet we would definitely expect environment variables to get expanded as they normally would in a shell script. For setting many environment variables, it's quite a common trick to extend it from its previous value that you'd want to reuse in the new value (like lists of directory, i.e. in $PATH).

Copied from original issue: flatpak/flatpak#556

From @matze on February 15, 2017 9:33

I'm building a flatpak for Inkscape which has several dependencies and build times are getting out of hand partly due to flatpak-builder's inability to specify proper dependencies and tendency to invalidate its cache entries for no particular reasons. For example, I just added another post-install command to the last module, yet, almost all other modules are rebuilt.

Copied from original issue: flatpak/flatpak#568

From @mildred on October 18, 2016 8:9

I have the same setup on two different computers, and one is not working as expected. I'm trying to package an electron-based app and I am inspiring myself from https://github.com/vrutkovs/flatpak-electron (I made almost no modifications to the json file and the Makefile patch)

The build command I have is : flatpak-builder --repo=repo --subject="Patchwork Electron" --verbose app com.github.electron.json

At the moment the make command is called from flatpak-builder, I have the repositories that are incorrectly configured. There is a recursive submodule that points to a git repository outside of /run. Running git commands in this repository gives mixed results. For example I have:

+ cd /run/build/electron-gtk3/electron/vendor/brightray/vendor/libchromiumcontent
+ python script/bootstrap -v
fatal: /usr/lib/git/git-core/git-submodule cannot be used without a working tree.

I debugged this, and could find that in that directory, git rev-parse --is-inside-work-tree results in false instead of true.

I could trace it back to the fact that in this directory, the .git says the repository is outside /run:

$ cat /run/build/electron-gtk3/electron/vendor/brightray/vendor/libchromiumcontent/.git
gitdir: /home/mildred/Projects/patchwork-electron/.flatpak-builder/build/electron-gtk3-2/.git/modules/electron/modules/vendor/brightray/modules/vendor/libchromiumcontent

And the repository config contains a relative directory to its worktree (because it's a submodule, this is normal) which resolves outside /run when joined with the repository real path:

$ cd /run/build/electron-gtk3/electron/vendor/brightray/vendor/libchromiumcontent
$ git config core.worktree
../../../../../../../../../electron/vendor/brightray/vendor/libchromiumcontent
$ git rev-parse --git-path $(git config core.worktree)
/home/mildred/Projects/patchwork-electron/.flatpak-builder/build/electron-gtk3-2/.git/modules/electron/modules/vendor/brightray/modules/vendor/libchromiumcontent/../../../../../../../../../electron/vendor/brightray/vendor/libchromiumcontent

I tried to remove the flatpak repository and the hidden .flatpak-builder directory, but it is always the same. On another computer with the same setup, I have no problem.

I have flatpak version 0.6.11 on both on Arch and Fedora

edit : Removing the submodule working directories and running git submodule update in the Makefile is a workaround. No network access should be required for that (the git repository is already there) but the worktree is recreated anew and correctly.

Copied from original issue: flatpak/flatpak#353

I would like to checkout a git repository, execute a Maven build and use the openjdk extension from Flathub to run the built application. Is this somehow possible?
I've tried

{
    "type": "shell",
    "commands": [
    "mvn clean package"
    ]
}

However, this only gives me /bin/sh: mvn: command not found (which is not really surprising as mvn is not part of the freedesktop runtime/sdk).

From @cmacq2 on December 19, 2015 23:10

Judging by a cursory overview of the docs there is no support for verifying integrity of downloaded sources beyond a simple SHA256 checksum in xdg-app-builder.

It would arguably be better (more robust) if the integrity of the sources could be verified by checking a PGP signature against a known key. As it stands, essentially the builder has zero protection against a compromised repository/download server (and this has happened: think vsftpd, kernel.org).

Beyond that, it simplifies things for the user of xdg-app-builder because as long as a PGP key remains valid they can trivially upgrade without having to check & update to the new SHA256 sums manually -- since an equivalent up-to-date checksum would, of course, be embedded in the PGP signature itself. So only the trusted keys of upstream need to be known, and the machinery takes care of all the rest.

Event better, still: modern GIT allows you to sign commits with PGP signatures as well, so for the smoothest experience the builder would ideally be able to verify the signature of a GIT commit also. This can help guard you better against a compromised repository because it authenticates the GIT history itself. Essentially a signed GIT commit is a statement from upstream that they trust their current GIT history/state up until and including the particular commit to be 'verified', otherwise the only guarantee is that the GIT history is internally consistent which is not necessarily equivalent to 'tamper free'.

That way the consumer (builder) could declare the a GIT tag as their dependency (i.e. a particular release) and the builder could give fairly strong guarantees that the the sources being used in the project actually match with what was intended.

By adopting support for checking sources against PGP signatures, xdg-app-builder can offer a stronger protection against compromised sources to its users.

By adopting support for checking authenticity of signed GIT commits, xdg-app-builder can offer some gentle encouragement and reward for upstreams to make their release process/source control practices the best they can be, which will ultimately benefit the consumers of their code (i.e. users of xdg-app-builder).

Copied from original issue: alexlarsson/xdg-app#95

From @alexlarsson on May 19, 2016 15:32

From @hbons on February 27, 2016 21:39

Git repos can be huge, and when building you may not be interested in the full history.
Maybe a property in the json file (or even changing the default) to allow shallow cloning would save a lot of time and bandwidth.

Copied from original issue: alexlarsson/xdg-app#112

Copied from original issue: flatpak/flatpak#15

When creating a new json manifest for my webcam app, I needed to add "--device=all" (other apps like Steam also do that).

In this case, should flatpak have more targets from --device, like --device=media (for webcams on /dev/videoX and radio devices for /dev/radioX) ?

Currently, only kvm, dri and all exists (https://github.com/flatpak/flatpak/blob/2a661fd448a153992e07904b666ef4fb748810a3/common/flatpak-run.c#L112)

If you guys agree, I can work on that.

flatpak-builder doesn't like to build my manifest, because

"Failed to download sources: module setuptools: Can't find file at pip-Makefile"

I have the file right next to from where I execute flatpak-builder and I expected it to find the file.
Now it seems to expect the file relative to the manifest. That's fair enough, but I would appreciate if it told me something about where it tried to locate the file. Maybe printing out the full path or the directory relative to the manifest or something would have helped me to debug this quicker.

From @orbisvicis on April 6, 2017 14:36

The zip format allows extraneous data between chunks, which is how self-extracting archives are built. Unfortunately this is a warning for the unzip tool, which process the archive successfully but returns with an exit code of 1, which breaks the build process. However that exit code is also reserved for similar but legitimate warnings. If flatpak-builder ignores that code, important errors might be missed. Furthermore self-extracting archives have non-standard file extensions and can't be identified by magic numbers. So...

1. Provide and default to an extraction tool that doesn't have this problem - bsdtar works fine and is more flexible.
2. Allow specifying the archive's format explicitly.

Copied from original issue: flatpak/flatpak#687

From @bochecha on March 23, 2017 11:47

Today @csoriano89 tried building the Nautilus master bundle, which builds tracker from master.

At some point, tracker master added a new dependency on libseccomp.

I added libseccomp to the fdo Sdk back in December 2016, to fix the build of Nautilus and other apps using tracker.

So this morning, @csoriano89 tried building Nautilus master locally, but he had an old version of the Sdk installed, one which didn't contain libseccomp, and his build failed.

Maybe flatpak-builder could have quickly checked that an updated Sdk was available, and warned about it?

Alternatively, maybe flatpak-builder could automatically update the Sdk?

Copied from original issue: flatpak/flatpak#655

From @pulb on July 13, 2016 17:6

Currently Snappy has a tremendous advantage over Flatpak: it supports creating .snap bundles with included dependencies pulled from .deb packages. Look at the endless dependency list of the VLC snappy build file for example. A developer can create a .snap bundle with many dependencies like this in a...snap, whereas he has to collect all dependency source tarballs and automake build settings in order to build an equivalent Flatpak bundle. Honestly, if I were an unbiased developer, I'd rather setup an Ubuntu VM and quickly build a bundle for my project with Snappy (snapcraft) before going through the hell of finding dependency sources, propper build settings and fixing compilation errors.

So I'd propose to incorporate a generic package plugin interface which can be implemented distro specific (i.e. with backends for apt, dnf, pacman and so on).

Copied from original issue: flatpak/flatpak#183

From @Jehan on February 13, 2017 1:40

Trying to work around another bug of flatpak, I tried to add a "script" source and I put it before the "git" source in the list. When it came to building the module, I got:

========================================================================
Building module gimp in /home/jehan/gimp/build/flatpak/.flatpak-builder/build/gimp-8

fatal: destination path '/home/jehan/gimp/build/flatpak/.flatpak-builder/build/gimp-8' already exists and is not an empty directory.
Error: module gimp: Child process exited with code 128

I understand the issue: flatpak tries to clone the git directory which requires no directory or an empty one. I would propose to either make it possible (clone in a temporary directory and move all files after for instance), or at least write down in the documentation that if a module has multiple source, and among them there is a git source, it has to be first in the list.

Copied from original issue: flatpak/flatpak#555

From @Ace13 on May 3, 2017 12:38

Currently, flatpak-builder seems to assume - in most cases rightfully so - that any build of an extension is for a runtime.

Was hoping to use this to split out an optional extension - DFHack - for the game Dwarf Fortress, since they don't follow anything like the same release schedules.
The documentation here seems sorely lacking, if it's even possible to do what I want at the moment, can't find anything saying either way. And just the specification of how to expose extension points wasn't very well documented either.

Snippets from manifests;

{
    "name": "com.bay12games.DwarfFortress",
    "branch": "0.43.05",

    "runtime": "org.gnome.Platform",
    "runtime-version": "3.24",
    "sdk": "org.gnome.Sdk",
    // ...
    "finish-args": [
        // ...
        "--extension=com.bay12games.DwarfFortress.dfhack=directory=/app/dfhack",
        "--extension=com.bay12games.DwarfFortress.dfhack=no-autodownload=true",
        "--extension=com.bay12games.DwarfFortress.dfhack=version=0.43.05",
    ]
    // ...
}

{
    "app-id": "com.bay12games.DwarfFortress.dfhack",
    "branch": "0.43.05",

    // What goes in here to make it build as an application extension?
    "runtime": "org.gnome.Platform",
    "runtime-version": "3.24",
    "sdk": "org.gnome.Sdk",

    "build-extension": true,
    "build-options": {
        "prefix": "/app/dfhack"
    },
    "modules": [
        // ...
    ]
}

Getting complaints to the tune of;

Error: No extension point matching com.bay12games.DwarfFortress.dfhack in runtime/org.gnome.Platform/x86_64/3.24

Copied from original issue: flatpak/flatpak#762

From @matthiasclasen on June 3, 2016 12:28

this would make it easier to create runtimes that are populated by rpm content.

Copied from original issue: flatpak/flatpak#87

From @chergert on March 11, 2017 10:58

For Builder, it would be really nice if we could share git checkouts for different projects. Things like gnome-todo and gnome-calendar both having 300 mb dependencies (e-d-s) makes things tough for people that work on both of those.

It would be interesting if git work-trees could help here and somehow share repositories with jhbuild.

Copied from original issue: flatpak/flatpak#620

I am now experimenting a BaseApp for GIMP.
Maybe I am missing something, but since the GIMP build requires various headers, and also tools (some *-config used during configuration step, pygobject-codegen-2.0, etc.), I don't clean them out anymore in the BaseApp manifest.

But then I still want to delete them in the end since there are useless during runtime and only make the download size bigger. So I added them in the toplevel "cleanup".
But then running:

flatpak run --devel --command=bash org.gimp.GIMP

I discover there is a /app/include/ full of headers, and /app/bin/ is full of all these BaseApp binary which I wanted to get rid of. Cannot the main manifest delete files from the BaseApp? If so, what is the way to delete them (while still keeping them temporary during the software build)?

As a workaround for #70 I was thinking to just remove those directories after clone & before build, but that doesn't seem to be possible.

First of all thanks a lot for developing such a useful tool.
I was trying to build vlc from https://github.com/flathub/org.videolan.VLC.git , I cloned the repo and issued the below command

 flatpak-builder --repo=VLC org.videolan.VLC org.videolan.VLC.json

while building computer froze and I had to have a reboot after hours of compilation process.

When I rerun the above command I got

     App dir 'org.videolan.VLC' is not empty. Please delete the existing contents or use --force-clean.

Is there a command switch that I can force to continue building process?

Basically flatpak-builder fails to clone https://git.ffmpeg.org/ffmpeg.git because "fatal: protocol error: bad pack header", even though it can clone fine other repositories, and I can clone the ffmpeg repository separately just fine.

[...]
flatpak-builder 0.10.1
Creating the prefix with: cd /home/aleb/dev/ptv-stable/pitivi/build/flatpak; ['flatpak-builder', '--force-clean', '--ccache', '/home/aleb/dev/ptv-stable/pitivi-prefix', '/home/aleb/dev/ptv-stable/pitivi/build/flatpak/Pitivi.T7633.json', '--build-only']
Downloading sources
Fetching git repo https://anongit.freedesktop.org/git/sound-theme-freedesktop.git, ref refs/tags/0.8
remote: Counting objects: 1, done.
remote: Total 1 (delta 0), reused 1 (delta 0)
Unpacking objects: 100% (1/1), done.
Fetching git repo https://git.gnome.org/browse/gsound, ref refs/tags/1.0.2
remote: Counting objects: 1, done.
remote: Total 1 (delta 0), reused 0 (delta 0)
Unpacking objects: 100% (1/1), done.
Fetching git repo https://git.ffmpeg.org/ffmpeg.git, ref refs/tags/n3.3.2
fatal: The remote end hung up unexpectedly
fatal: protocol error: bad pack header
Failed to download sources: module ffmpeg: Child process exited with code 128

The ffmpeg module in Pitivi.T7633.zip is:

            "sources": [
                {
                    "type": "git",
                    "url": "https://git.ffmpeg.org/ffmpeg.git",
                    "branch": "6d7192bcb7bbab17dc194e8dbb56c208bced0a92"
                }
            ]

If I clone it separately it works fine:

$ git clone https://git.ffmpeg.org/ffmpeg.git

From @futuretim on April 5, 2017 12:8

When trying to build and install an extension from a build shell, write access is not granted to the sdk filesystem area. for instance with the rust extension after a proper build-init, using:

flatpak build --share=network ../rust-build

I can easily clone rust's git, have it do its build but upon install it fails with this error:

mkdir: cannot create directory ‘/usr/lib/sdk/rust’: Read-only file system
install: error: can't write to destination. consider sudo.

Copied from original issue: flatpak/flatpak#684

From @dbnicholson on January 10, 2017 15:35

When running flatpak-builder --finish-only, the cleanup command is run, but none of the files in the cleanup list are removed. It looks like this is because there are no changes in the BuilderCache since the build wasn't run. I looked at how to rebuild the cache without building, but I couldn't figure it out.

Without this, we're just running flatpak-builder normally so the cleanup actions are respected, doing our metadata modifications, wiping the exports directory, then running flatpak build-finish again. It would be great if we could use --build-only and --finish-only normally.

Copied from original issue: flatpak/flatpak#480

I'm trying to flatpak a windows application using wine. I can get it to mostly work, but I need to install a few windows dependencies, and while they have a silent install option, they still want to start an x11 window and then immediately close it. I can't really fix that, nor could I fix a windows installer that requires clicking through an installer, but packaging windows applications as flatpaks would be really useful.

From @Alexander-Wilms on March 28, 2017 2:41

I'm trying to build TeX Live, but the official archive is only available via FTP: ftp://tug.org/texlive/historic/2016/texlive-20160523b-source.tar.xz

Adding the url as a source results in the following error message: "Failed to download sources: module texlive: Not supported address schema"

Copied from original issue: flatpak/flatpak#666

Why is there a restrictions on the app ID "Only last name segment can contain -"? I tried to package https://github.com/parnold-x/nasc/ which uses the app ID com.github.parnold-x.nasc.

I don't really see the point here, as it is advised to use the reverse of an existing domain name, and that very well might contain - symbols.

From @TingPing on March 13, 2017 4:40

It would be useful for Gnome Builder if it could parse the manifest for warnings or errors without building the project.

Copied from original issue: flatpak/flatpak#623

I am getting this error when trying to unpack zip archive using flatpak-builder:

Error: module tremulous-data: Error moving file /home/asciiwolf/Code/com.grangerhub.Tremulous/.flatpak-builder/build/tremulous-data-3/.uncompressLT904Y/gpp_11/vm: File exists

For more information see this PR.

From @alexlarsson on May 25, 2016 15:4

This will force us to rebuild if some extension runtime that will be used was updated on installed.

Copied from original issue: flatpak/flatpak#38

I am packaging some app which has some submodules for libraries I don't need. Which makes it to use bundled copies instead ones I built in manifest.

From @muelli on August 19, 2016 12:10

I've installed flatpak from git, because I am expecting to get an error related to my exported desktop file which the current 0.6.7 does not check for.

Anyway, I'm trying to use the new flatpak and flatpak-builder, so I call it from my prefix:

$ strace -f -eexecve /var/tmp/flatpak/bin/flatpak-builder  --force-clean -v  --repo=/tmp/fb.repo  /tmp/fpbuilder org.gnome.Foo.json
...
Exporting org.gnome.Foo.Debug to repo
strace: Process 21629 attached
[pid 21629] execve("/home/muelli/.local/bin//flatpak", ["flatpak", "build-export", "--arch=x86_64", "--runtime", "--metadata=metadata.debuginfo", "--files=files/lib/debug", "/tmp/fb.repo", "/tmp/fpbuilder", "master"], [/* 66 vars */]) = -1 ENOENT (No such file or directory)
[pid 21629] execve("~/.local/bin/flatpak", ["flatpak", "build-export", "--arch=x86_64", "--runtime", "--metadata=metadata.debuginfo", "--files=files/lib/debug", "/tmp/fb.repo", "/tmp/fpbuilder", "master"], [/* 66 vars */]) = -1 ENOENT (No such file or directory)
[pid 21629] execve("$HOME/.local/bin/flatpak", ["flatpak", "build-export", "--arch=x86_64", "--runtime", "--metadata=metadata.debuginfo", "--files=files/lib/debug", "/tmp/fb.repo", "/tmp/fpbuilder", "master"], [/* 66 vars */]) = -1 ENOENT (No such file or directory)
[pid 21629] execve("/usr/local/sbin/flatpak", ["flatpak", "build-export", "--arch=x86_64", "--runtime", "--metadata=metadata.debuginfo", "--files=files/lib/debug", "/tmp/fb.repo", "/tmp/fpbuilder", "master"], [/* 66 vars */]) = -1 ENOENT (No such file or directory)
[pid 21629] execve("/usr/local/bin/flatpak", ["flatpak", "build-export", "--arch=x86_64", "--runtime", "--metadata=metadata.debuginfo", "--files=files/lib/debug", "/tmp/fb.repo", "/tmp/fpbuilder", "master"], [/* 66 vars */]) = -1 ENOENT (No such file or directory)
[pid 21629] execve("/usr/sbin/flatpak", ["flatpak", "build-export", "--arch=x86_64", "--runtime", "--metadata=metadata.debuginfo", "--files=files/lib/debug", "/tmp/fb.repo", "/tmp/fpbuilder", "master"], [/* 66 vars */]) = -1 ENOENT (No such file or directory)
[pid 21629] execve("/usr/bin/flatpak", ["flatpak", "build-export", "--arch=x86_64", "--runtime", "--metadata=metadata.debuginfo", "--files=files/lib/debug", "/tmp/fb.repo", "/tmp/fpbuilder", "master"], [/* 66 vars */]) = 0
...

I somehow expected it to call the newly installed flatpak binary. However, I see it trying to execute flatpak from various locations, e.g. ~/.local/bin, but not relative to itself.

Now it might be a weird for the flatpak-builder binary to look for the "flatpak" binary relative to itself and I don't think I know anything that behaves similarly. But I somehow expected the new flatpak to be called. It would make my life a tiny bit easier if it did, because I wouldn't need to manipulate the PATH (which seems to be a little awkward to do in my shell, fish).

If calling the relative binary itself it too weird but looking for it is not, then a warning might be fruitful. Otherwise, feel free to close.

Copied from original issue: flatpak/flatpak#258

Do you have plans for Mercurial support?

From @adityashah1212 on June 25, 2017 16:38

Add a link to backup or fallback url, in case the first one is not working for sources in json

Copied from original issue: flatpak/flatpak#868

The project I wish to package as a flatpak app supplies only sha512 sums for their source downloads and in the flatpak-builder json file, I can only supply sha256 sums.

It would be neat if flatpak-builder could consume other kinds of checksums.

The thing is if an appdata file is missing, one has to add it as a source and then either modify build-commands or post-install and add something like "mkdir -p /app/share/appdata", "install -Dm644 appdata.xml /app/share/appdata/appname.appdata.xml" and add a "rename-appdata-file": "appname.appdata.xml", but with this approach a simple appdata change requires a rebuild, and, frankly, the approach is a bit tedious.

It would be cool if there was something like:

      "sources": [
        {
          "type": "appdata",
          "path": "appdata.xml"
        }
      ]

which would perform all the above, automatically, without needing a rebuild.

From @chergert on June 3, 2017 21:19

I'm seeing some tofu blocks in Builder when running flatpak-builder on our nightly branch.

|�Cloning git repo https://git.gnome.org/browse/libgsystem.git

http://www.fileformat.info/info/unicode/char/fffd/index.htm

I don't see this anywhere else in our subprocess logging in Builder, so I'm pretty sure it's something in the subprocess encoding negotiation with flatpak-builder (maybe improper environment variables on our part) or something expecting a PTY that isn't.

I'm using flatpak-builder 0.9.4 on rawhide.

Copied from original issue: flatpak/flatpak#830

From @mdeguzis on July 31, 2017 0:46

I don't like so much that you can't really avoid having to manually compile dependencies as part of your build. For something like Kodi, that is a huge amount of "modules" you'd have to write in and get all correct vs. just adding a line to debian/control for an existing ffmpeg package.

JSON gets messy, and keeping which bracket/brace goes to which gets out of hand with long files. Contrast this to A Makefile or debian/rules, where things are structure with labels, and allow scenarios where "this depends on that", just as you have modules here. I see the JSON manifest as a barrier for acceptance, I know it is for me, even if I write JSON payloads frequently for my day job as a devop for Hadoop.

Having packaged for Debian/Fedora/Arch Linux for several years, it just seems there is a better way. Any plans for an alternative? JSON generator?

Copied from original issue: flatpak/flatpak#941

From @alexlarsson on May 25, 2016 15:14

Some apps let you build and install the tests. It would make a lot of sense to do this, and then package that as an extension similar to the debug info one (maybe even in that runtime).

Copied from original issue: flatpak/flatpak#41

From @alexlarsson on May 25, 2016 15:17

If you're checking in a builder manifest into the git repo of your app and using flatpak to build it, it doesn't necessarily make a lot of sense to download the git repo again. We should have some way to support using the existing repo, maybe even the current outstanding changes to it.

Not sure exactly how this would work though. Its complicated both how to reference to the current git repo, and how to reuse the current checkout without old builds affecting the new build.

Copied from original issue: flatpak/flatpak#42

From @matthiasclasen on June 28, 2016 14:37

Applications like the gimp or gedit have 3rd party plugins.
We probably need some kind of "gimp sdk" to make that possible ?

Copied from original issue: flatpak/flatpak#159

When I try to build a manifest I always get the following error:
Error: renameat(checkout-union-rGuWia, metadata): Invalid cross-device link

Steps to reproduce

Clone for example Polari
Run flatpak-builder -v --force-clean /tmp/fpbuilder org.gnome.Polari.json

The output will be something like:

Committing stage build-telepathy-glib to cache
Error: renameat(checkout-union-Gpxd1G, account-channel-request.h): Invalid cross-device link`

I'm running Arch Linux and I tried flatpak-builder 0.9.99 and 0.10.1 with the same end result.

EDIT: in case it is useful, this is the output of mount https://ptpb.pw/OI7p

From @TingPing on June 21, 2016 9:0

Quite a lot of Python projects use distutils/setuptools and would be nice to support that. Something like:

"modules": [
  {
    "name": "...",
    "no-autogen": true,
    "distutils": true
  }
]

That seems consistent with cmake. It would check for setup.py, run ./setup.py build --prefix=... and ./setup.py install --prefix=... --optimize=1 --skip-build. Though some projects don't have an exectuable setup.py so there would have to be another variable for python2 vs python3 in that case...

Copied from original issue: flatpak/flatpak#134

flatpak-builder is mostly LGPL-2+ or LGPL-2.1+, but src/builder-utils.c says:

top of file:

 * This file is free software; you can redistribute it and/or modify it
 * under the terms of the GNU Lesser General Public License as
 * published by the Free Software Foundation; either version 2 of the
 * License, or (at your option) any later version.

middle of file:

 * This code is based on debugedit.c from rpm, which has this copyright:
 *
 *
 * Copyright (C) 2001, 2002, 2003, 2005, 2007, 2009, 2010, 2011 Red Hat, Inc.
 * Written by Alexander Larsson <[email protected]>, 2002
 * Based on code by Jakub Jelinek <[email protected]>, 2001.
 *
 * This program is free software; you can redistribute it and/or modify
 * it under the terms of the GNU General Public License as published by
 * the Free Software Foundation; either version 2, or (at your option)
 * any later version.

If Red Hat, Inc. is really the only copyright holder, then Red Hat is free to relicense this code to LGPL-2+ or LGPL-2.1+. If that is what you want to do, please keep the copyright notice, but replace the license grant with an appropriate LGPL license grant, or a note that it has been relicensed with Red Hat's permission.

Alternatively, if you are intentionally leaving this code GPL, that means that flatpak-builder as a whole is effectively GPL-2+. This is the interpretation I've chosen to follow for now in Debian, because it's the most conservative and it doesn't rely on anyone deliberately relicensing anything. However, if this is the case, then the license grant at the top of src/builder-utils.c is misleading, and the top-level directory ought to contain a copy of the GPL as well as the LGPL (perhaps the GPL text in COPYING.GPL, the LGPL text in COPYING.LGPL, and a note/summary about what is going on in COPYING).

There also seems to be some confusion about the LGPL. GNU has published the Library General Public License, version 2, and the Lesser General Public License, versions 2.1 and 3 (with a note that these count as later versions of the Library General Public license for the purposes of the "any later version" license grant). Some flatpak-builder source files declare that they are under the Lesser General Public License version 2 or any later version, but strictly speaking, that license does not exist. The two combinations that make sense are the Library General Public License, version 2 or any later version (LGPL-2+) or the Lesser General Public license, version 2.1 or any later version (LGPL-2.1+).

I have no opinion on whether you should prefer L(ibrary)GPL-2+ or L(esser)GPL-2.1+, but you should probably pick one or the other, and write license grants accordingly. If you tell me which one you were aiming for, I can provide a patch.

When using a git repo as a source, updating the local cached repo can fail:

Fetching full git repo https://github.com/opencv/opencv
From https://github.com/opencv/opencv
[...]
 - [deleted]               (none)     -> refs/pull/9895/merge
remote: Counting objects: 3446, done.
remote: Compressing objects: 100% (124/124), done.
remote: Total 3446 (delta 2294), reused 2214 (delta 2212), pack-reused 1110
Receiving objects: 100% (3446/3446), 1.18 MiB | 8.04 MiB/s, done.
Resolving deltas: 100% (2569/2569), completed with 676 local objects.
   d0f3468477..91fe01beca  2.4                   -> 2.4
   9ae86a922c..11330b9253  master                -> master
 * [new ref]               refs/pull/10001/head  -> refs/pull/10001/head
[...]
 * [new ref]               refs/pull/10060/head  -> refs/pull/10060/head
 * [new ref]               refs/pull/10060/merge -> refs/pull/10060/merge
.... some branch ... REJECTED ... I guess because they pushed -f to their git server ... sorry I don't have the log line anymore

Would it make sense to force fetch/update the local repo?

Using flatpak-builder as part of a C-I process is incredibly convenient. It would be nice if I could force the build to fail when unit tests fail using an option like "run-tests": true, in the module description.

For make, this is generally going to be check, and for ninja this will generally be test.

One caveat though, is that we probably need network and display access if we're going to support things like appstream validation and initializing gtk as part of the test suite.

Currently, built extensions are unable to be exported with build-bundle since their prefix is not app but runtime so the refspec can't be found. This is a problem for apps that want to have easily-downloadable and installable extensions.

AC:

• flatpak build-bundle has a way to export an application extension as a single file

From @jurf on August 13, 2017 14:17

So we can stop doing things like:

"post-install": [
    "mv /app/share/mime/packages/scribus.xml /app/share/mime/packages/net.scribus.Scribus.xml"
]

Copied from original issue: flatpak/flatpak#958