Self-hosted install from flatpakref fails with error: Invalid compressed data

1

I’m building our own program with flatpak, with the goal of putting it on our own server and enable installation via a .flatpakref file. With previous versions, this used to work. Yesterday I tried to build a new version of our program, and do the same procedure; building the app and running it locally works just fine. After moving the repo to our server, I noticed however that any installation via .flatpakref just leads to an error outupt:

$ sudo flatpak install --verbose https://flatpak.3dct.at/openia.flatpakref
F: No installations directory in /etc/flatpak/installations.d. Skipping
F: Opening system flatpak installation at path /var/lib/flatpak
F: Opening user flatpak installation at path /root/.local/share/flatpak
F: Loading https://flatpak.3dct.at/openia.flatpakref using curl
F: Received 3186 bytes
F: Loading https://flathub.org/repo/flathub.flatpakrepo using curl
F: Received 4040 bytes
F: Fetching summary index file for remote ‘openia-origin’
F: Loading https://flatpak.3dct.at/summary.idx using curl
F: Received 334 bytes
F: Fetching indexed summary file ac86708263c25ca318b4ca8e999c455dfc88790ec01b4284862e2ead894e5070.gz for remote ‘openia-origin’
F: Loading https://flatpak.3dct.at/summaries/ac86708263c25ca318b4ca8e999c455dfc88790ec01b4284862e2ead894e5070.gz using curl
F: Received 810 bytes
error: Invalid compressed data

Searching for this error didn’t give me any results that seemed to apply for my case - the only thing that stuck out as possibly remotely relevant is some bug in ostree a while back, which should be fixed by now.

Later, I noticed that I even got the same error when I host the “old” repository which I had backed up (a repository only containing the old version of our program, where installation previously used to work).

I have tested both building and installing on Fedora 40 and Ubuntu 24.04; in both cases, building, local installation and running works fine, but installing from .flatpakref fails with above error.

How can I get more information on what is actually failing here? The verbose output suggests there is something wrong with the content of summaries/ac86708263c25ca318b4ca8e999c455dfc88790ec01b4284862e2ead894e5070.gz but I have no idea what. When extracting the .gz, the resulting file does look strange (mixing text with binary data), but from what I can gather this has always looked that way?

build-update-repo, which as far as I can tell produces these summary files, ran through successfully; I have tried the build/sign/upload procedure multiple times, and as I said, installation fails even with a repo that I’m pretty sure was working before.

So I have no clue how to figure out what’s wrong with the files or how I can produce “correct” ones?

I guess there could also be something wrong with my hosting environment that leads to this error?

In order to keep this post reasonably short I have skipped the commands I use in my build/sign procedure, but If required I can of course provide them.

2

Checking the extracted summaries/ac86708263c25ca318b4ca8e999c455dfc88790ec01b4284862e2ead894e5070.gz (which has the 810 bytes reported by flatpak), this is what the content looks like:

app/at.zfp.openia/x86_64/stable^@d^C^@^@^@^@^@^@Ñ<88>´®ªc7ÄZZ¼^O¦¡<9f>^O^NwI<92>³<88>^?Çü0ÙÔóãHÈxa.data^@^@^@^@^@^PB<8e>^@^@^@^@^@^D®oØ[Application]
name=at.zfp.openia
runtime=org.kde.Platform/x86_64/6.4
sdk=org.kde.Sdk/x86_64/6.4
command=open_iA

[Context]
shared=network;ipc;
sockets=x11;wayland;
devices=dri;
filesystems=home;xdg-run/dconf;~/.config/dconf:ro;xdg-config/kdeglobals:ro;host;

[Session Bus Policy]
com.canonical.AppMenu.Registrar=talk
ca.desrt.dconf=talk

[Environment]
DCONF_USER_CONFIG_DIR=.config/dconf
^@^@(tts)^H^@^@^@^@ot.ts^@^@^@^@^@^@^@d-f^A^@t^F¥^A»^A(^@ ^@^@^@^@^@^@appstream/x86_64^@^@^@^@^@^@^@^@Î^@^@^@^@^@^@^@<90>½t<84>±±O<80><8d>ûº^M^T«ÑøÎ^E<81>f%S¸Û|òêª<9d>H÷¿xa.data^@^@^@^@^@^@^@
^@^@^@^@^@^@^@  h^@^@(tts)^Hot.ts^@^@^@^@^@^@^@f<8f>^@ ^@t^F 3(^Q^@appstream2/x86_64^@^@^@^@^@^@^@Ö^@^@^@^@^@^@^@F¬<8a>^A_<92>õ:¨æx£¾jà^^B<8c>øc^@,_<91>^BRa¿'ÏØjxa.data^@^@^@^@^@^@^@^R^@^@^@^@^@^@^@  U^@^@(tts)^Hot.ts^@^@^@^@^@^@^@d-l¡^@t^F 3(^R^K^B<87>^Bÿ^B^@^@^@xa.summary-version^@^@^@^@^@^@^A^@^@^@^@u^S^_^E^C

Are these binary chunks within the file (in the first and last two lines) normal?

The compression actually doesn’t seem to be the problem - gzip can decompress the file just fine, and re-compression with gzip produces a file of a bit larger size (probably different compression level), which however produces the same error.

3

Sorry to push this, but I really want to solve this issue as soon as possible. Some small hint where I possibly could look for more information would be enough! I just am very stuck at this point and have no more idea what to check…

By the way, I hope I am asking the question in the right place (got here from the forum link on flatpak.org) - or if it’s not, maybe someone can point me to a more suitable one?

4

can you try another host system, as far as I know, those can be pretty simlpe and only need to offer tha data (github/gitlab pages work for this for e.g.)

wondering, how you move the files around, but usually that shouldn’t cause this.

1 Like
5

Thanks for the suggestion. Shame on me, I did suspect it was a host issue but didn’t follow up on that. And indeed it somehow seems specific to the host! I switched to another, there it works.

Now I “only” need to find out what’s wrong on the original host…

First time, I transferred via FTP, then realized this could cause issues; back when I reported the issue I already was transmitting a .tar.gz’ed or .zip’ed repo folder.

1 Like
6

There is something weird going on - I tried downloading the same summaries file from both the affected host and the non-affected host via curl and wget (the file mentioned in the verbose output of flatpak, right before the “error: Invalid compressed data” output).

The resulting files are always IDENTICAL.

I noticed that curl wasn’t installed on the machine where I did this (where I also tried the flatpak install from the .flatpakref) - so apparently flatpak uses its own internal version of curl (library probably). It seems that the curl included in flatpak seems to have some problems with the one host (which neither standalone wget nor curl have).

So it probably has something to do with server configuration.

This seems however like a flatpak bug to me - if both wget and curl can download the files properly, but flatpak just reports a somewhat cryptic error…

EDIT: On a quick glance I didn’t see any major differences (both use HTTP/2, compression), and I don’t have more time for this at the moment. If somebody cares to look into it, here are the two base URLs:

The summaries file is called /summaries/0770ef8de810232dc14247c5a08c89b9f296c81559195d61c140b0d37251216d.gz
I have changed to the “full” repository again with all previous versions included, that’s why the file has a different name than in my original error message.