Help packaging up a Flutter app

#1

I’m trying to make a Flatpak of this Flutter app: https://github.com/hamaluik/timecop . I’m using FluffyChat as my inspiration.

There’s one place where I’m getting stuck: I can’t figure out how to include SQLite 3, which the app depends on. FluffyChat seems to accomplish this by including two cmake dependencies: olm and libjsoncpp. Both seem to yield a /usr/lib/x86_64-linux-gnu/libsqlite3.so.0 file, even though neither are directly related to SQLite.

I don’t have a need for any of these libraries, but I do need SQLite 3. How do I do that?

For reference, this is my current Flatpak YAML draft:

app-id: ca.hamaluik.Timecop
runtime: org.freedesktop.Platform
runtime-version: '21.08'
sdk: org.freedesktop.Sdk
command: timecop
separate-locales: false
finish-args:
  - --share=ipc
  - --socket=fallback-x11
  - --socket=wayland
  - --socket=pulseaudio
  - --share=network
  - --device=dri
  - --talk-name=org.freedesktop.Notifications
modules:
  - name: timecop
    buildsystem: simple
    build-commands:
      - cp -R /usr/bin/ /app/timecop
      - mkdir /app/bin/
      - ln -s /app/timecop/timecop /app/bin/timecop
      - ln -s /usr/lib/x86_64-linux-gnu/libsqlite3.so.0 /app/lib/libsqlite3.so
      - install -Dm644 usr/share/ca.hamaluik.Timecop.svg /app/share/icons/hicolor/scalable/apps/ca.hamaluik.Timecop.svg,
      - install -Dm644 usr/share/ca.hamaluik.Timecop.desktop /app/share/applications/ca.hamaluik.Timecop.desktop,
      - install -Dm644 usr/share/ca.hamaluik.Timecop.appdata.xml /app/share/appdata/ca.hamaluik.Timecop.appdata.xml
    sources:
      - type: archive
        only-arches:
          - x86_64
        path: "timecop-linux-x86_64.tar.xz"
        dest: "timecop"

And this is the error I get:

ln -s /usr/lib/x86_64-linux-gnu/libsqlite3.so.0 /app/lib/libsqlite3.so
ln: failed to create symbolic link '/app/lib/libsqlite3.so': No such file or directory
#2

@nedrichards You were offering help with Flutter over at Ideas on growing the Flathub Community in 2022 - #7 by ChrisOfBristol . Could you give me a tip regarding this problem?

#3

You can try to debug your module with flatpak-builder --build-shell=timecop BUILDDIRECTORY MANIFEST. This prepares your build environment for the given module & starts a build shell. There you can manually execute your build-commands & inspect your source directory as well as the /app destination.

You should replace cp -R /usr/bin/ /app/timecop with cp -R timecop /app/timecop to copy your application into the /app-prefix (you’re currently copying the binaries of the SDK into your app).

1 Like
#4

You have example sqlite3 builds here , here and here

#5

SQLite 3.36 is already part of the Platform (freedesktop-sdk). It shouldn’t be necessary and probably avoided to build it unless a specific or newer version is required.

That’s not why the symbolic link fails, since the library exists (this works: flatpak run --command=ls org.freedesktop.Platform//21.08 /usr/lib/x86_64-linux-gnu/libsqlite3.so.0).

2 Likes
#6

Thanks a ton! Your tip helped me debug he problem. Beside the cp bug that you noted, I also needed to mkdir and then it worked. :slight_smile:

Now I’m dealing with a filesystem permission issue. It seems that both getDatabases() in SQFlite as well as getApplicationDocumentsDirectory() in path_provider point to somewhere outside the sandbox in the home directory. I’ll look into it when I get the time and if I can’t figure it out, I’ll create a new thread.

For now, I’ll be setting the --filesystem=home permission.

#7

I can’t say anything about SQFlite, but getApplicationDocumentsDirectory() resolves into the user visible documents folder (usually $HOME/Documents) and therefore requires --filesystem=xdg-documents.

If you want to hide your files inside $XDG_DATA_HOME, you have to use getApplicationSupportDirectory (this doesn’t require any filesystem-permissions).

References:
path_provider on desktop stores app files in the user’s documents directory
When getApplicationDocumentsPath() is used, call getApplicationSupportPath()

#8

Thanks!

I ended up using XDG_DATA_HOME from xdg_directories. It probably does the same thing, but it was easier to discover for me, and it also seems more future-proof to me.

I also ended up duplicating a file opened from a file picker to a temporary location, though I’m not sure that’s necessary.

I discovered quite late that despite using --force-clean, my binary was not being updated during installation. --disable-cache did the trick.

(My Linux set-up is painful in that my Linux computer has a tendency to randomly freeze up and become unresponsive for hours due to a hardware issue. Other than that, I have a Mac with basically no hard disk space, so VM is out of the question. Testing different builds is quite burdensome, which is why I haven’t tested not copying an imported file to a temp location.)

Anyway, seems like I’m at the finish line. Now just need to make sure that my changes aren’t causing regressions on Android or iOS.