Roadmap to Fontra Flatpak

[mitradranirban]

Thanks for deciding to support Linux officially in Fontra.

Before proceeding, we must know how current flatpak works

Currently Flatpak is not generated from source. Rather it just creates a wrapper around the Pyinstaller binary created in this workflow and sandboxes it in Flatpak way with addition of an icon, a desktop launcher, and a metainfo file for use for Software centers.

To be truly cross Platform in all architectures supported in Linux, the app must be generated from source in Docker environment, with or even without pyinstaller overhead (which is unnecessary in Linux an Python is present in all Desktop Linux) we have to go there later when cffsbr is compilable in all Platforms.

✅Step 1: To generate the Linux Binary in GH Fontra org itself. I have generated a pull request for that again .

✅Step 2: The link to the archive is to be updated in the manifest file to link to the latest upstream release and a workflow is to be created to update the link and sha256 value everytime a new relase occurs in fontra-pak repo.

✅Step 3: The gitlab-ci file is to be replaced by equivalent Github worlkflow file

✅Step 4: The .flatpakref file is to be updated for the new address namely fontra.github.io/fontra-flatpak

✅Step 5: Create a branch to experiment with 'create from source' workflow

[mitradranirban]

Most of the steps are completed as planned. But to test the workflow the necessary gpg signatures are to be added to the repository secrets.
GitHub Secrets to add:

GPG_PASSPHRASE
GPG_KEY_GREP
GPG_PRIVATE_KEY
GPG_KEY_ID
and a base64 version of ginature file is to be appended to .flatpakref file. Currently it contains my signature for gitlab repo

[justvanrossum]

I have made you admin for this repo. I hope this allows you to add those secrets yourself?

[mitradranirban]

I have added all the secrets and allowed all workflow to run, also linted the syntax of yaml but the workflow is refusing to run. I will try to make a personal fork and try there to know whether any org specific restrictions are there

[justvanrossum]

Would this action be helpful? https://github.com/flatpak/flatpak-github-actions

Your yaml file looks very complex and scary. Also: there is a section "pages": what is that for? Do we need to configure GH Pages for this repo?

[mitradranirban]

I have converted it from the example gitlab-ci file provided for repository using LLM, and LLM are known to write convoluted code. There may be a simpler way, like the GitHub actions you mentioned I was using for creating the fontrapak.flatpak file in my repo .
The additional logic is for updating the yaml manifest and metainfo file every time a new release is made.
The deploy page stage saves the files to a html repository as incremental binary blobs, helping in quick and secure update. GPG signing is required to maintain the integrity of the flatpak
The end user only need the .flatpakrepo file once to add the repository to his system. Thereafter they can install or update at will
Unlike snap where all app must be distributed from Canonical's centralized store, flatpak is decentralised, where each developer can maintain their software store

[justvanrossum]

This stuff is way too dangerous to use an LLM for. If you don't understand yourself what is being done here in every detail, I am not sure I am willing to support this. Please either figure it out, or try to find outside support. I don't mean to sound ungrateful (I am very grateful for your contributions!) but there are risks involved in this kind of use of LLMs that I am not willing to take responsibility for.

[mitradranirban]

Ok I will check out Flatpak forum for help and update accordingly. Currently the gitlab repo I set up as per instructions given in their documentation is working fine. Unfortunately they have not provided sample workflow for GitHub so interpolation is required

[mitradranirban]

I have corrected some syntax errors in manifest and workflow and the flatpak repository is building and deploying . I will test it later from Ubuntu and Fedora and inform whether it is functioning as expected

[mitradranirban]

Corrected some errors in deployment steps and Flatpak repository is now fully functional.

Now the xyz.fontra.FontraPak.flatpakref file can be uploaded as a permanent link in fontra.xyz for the Flatpak with instruction to download the file to install the Flatpak

In some supported Linux Distros (like Fedora Gnome or Linux Mint) this can be done by double clicking file or right clicking and select Open with -> Software Install
In all Linux distros which has Flatpak installed the installation can be done with a single command

flatpak install --from path/to/xyz.fontra.FontraPak.flatpakref

or directly from repository as shown above. Now even if we upgrade the app the .flatpakref file need not be changed. User can simple upgrade by typing
flatpak upgrade

[mitradranirban]

Updated the installation instructions in README.md

Compilation from source currently fails, so Multi-arch support not enabled now. Will work on that in my fork and deploy here if successful

[mitradranirban]

Some user submitted screenshots available in this thread
mitradranirban/fontrapak-flatpak#9

[mitradranirban]

I have ultimately been able to create multi-arch flatpak repogenerated in the recommended way from sources.
https://github.com/mitradranirban/fontra-flatpak/actions/runs/20024551407
However the process could not be fully automated and requires manual generation of pypi-dependancies.json file and update of commit hash of the modules as the corresponding script didn't work in GitHub runner.
I will test my repo and check whether the app works before bringing the change to this official repository.

[mitradranirban]

What we can do is to keep the current workflow for edge channel which can automatically generate flatpak through remote push. The new workflow which requires manual dependency generation could be reserved for a stable channel. Flatpak allows distribution of multiple channels and multiple architecture from the same repository so the user gets a choice to upgrade to either.

Would like to know the opinion of Fontra developers in this regard.

[justvanrossum]

I'm not sure I like the two-channel approach.

Btw. regarding this workflow file:

• The EndBug/add-and-commit may make it more convenient to commit from a workflow
• The workflow file should be kept relatively small. If a section is more than a few lines, perhaps it should be its own (shell) script. It is easier to maintain if important bits of logic can be separated out into their own script.

[mitradranirban]

So we decide not to support aarch64 in flatpak till the automation issue is solved in the new workflow?
The issue is flatpak-pip-generator does not accept git+ and pyqt dependencies, so they had to be added as separate modules and base app in the flatpak manifest, requiring the need to modify multiple sites in the manifest.
In the current workflow using pre-built FontraPakUbuntu binary, we only have to change the url and the sha256sum of the new release in flatpak manifest