chipmuenk/pyfda

Provide flatpak for pyfda

Closed this issue · 22 comments

@Murmele has started this quite some time ago, however, I have been unsuccessful in creating a flatpak for the last releases. Details can be found in INSTALLATION.md.

More info on flatpaks:

https://www.loganasherjones.com/2018/05/using-flatpak-with-python/

https://www.heise.de/select/ct/2016/17/1471178736497222

If you are interested in using Flatpaks, please support me - I've spent several hours trying to work around errors related to matplotlib and pyQt5, I'm giving up here.

Hi @chipmuenk I will have a look I got more knowledge in this topic and be hopefully able to be able to get it work

move the flatpak manifest to flathub so it will be published in their repository

I created a pullrequest at flathub: flathub/flathub#2967

@Murmele Thanks a lot for your work, I noticed that you've closed your PR which hasn't been merged yet. Does this mean that the recipe is working and only needs to be accepted / merged by the flathub admins or have you also met larger problems? If it is possible to generate a flatpak locally, I could distribute it via github.

@chipmuenk sorry I was not able yet to get it work. But i still trying to get it work. At flathib they are quite fast, so whenever I am finish, they will merge. If you want we can setup then a continuous integration for it so it can be build for every new commit and released on the github page.

@chipmuenk is it possible to add more icons to the repository, 100x100 is not a common size

16x16, 32x32, 48x48, 64x64, 128x128, 256x256

So I can just copy it in the flatpak manifest without doing any hacks

Pushed icons in the required resolutions to master (path: pyfda/images/icons/pyfda_icon_*.png)

thank you!

@chipmuenk
Can you try out this flatpak package created by flathub if it works as expected?

flatpak install --user https://dl.flathub.org/build-repo/83468/com.github.chipmuenk.pyfda.flatpakref

@Murmele Works like a charm - thanks a lot! I've collected output messages during installation and start below.

Except for a Gtk-Message during the start of pyfda (due to prohibited network access? this would be ok, pyfda doesn't need network access) everything seems to be stable and "normal". The only things I'm wondering about are:

  • Where does the pyfda version string "2018.03.23" in flatpak list come from?
  • Is it ok that pyfda has file system access with user rights? Shouldn't the software be more "sandboxed"? Of course, this makes it easier to import / export filters and work with configuration files, but still ... what is the preferred policy for Flatpak applications in this respect?
  • My development version of pyfda and the Flatpak version are installed independently (as it should be) but they are using the same configuration file ~/.pyfda/pyfda.conf. This is not a specific problem of the Flatpak installation, maybe I need to come up with individual configuration directories.
  • What are the next steps? Should I leave it like that and just include the link to the build-repo on my Github repo before trying to publish it on Flathub.org?
  • Could you help me to write down the basic steps for preparing and generating a new flatpak? You have created a Github action which should take care of triggering the build process (thanks!) but what do I need to do if I add another module to my requirements etc.? I've started to collect some information in INSTALLATION.md in the Github repo. This file also contains stuff about building the various distribution formats which I'll move to a separate file.

Installation:

$ flatpak install --user https://dl.flathub.org/build-repo/83468/com.github.chipmuenk.pyfda.flatpakref

com.github.chipmuenk.pyfda permissions:
    ipc       fallback-x11          wayland               x11
        KENNUNG                                 Zweig         Op    Remote          Download
 1. [✓] org.freedesktop.Platform.GL.default     21.08         i     flathub         131,0 MB / 131,3 MB
 2. [✓] org.freedesktop.Platform.VAAPI.Intel    21.08         i     flathub          11,7 MB / 11,8 MB
 3. [✓] org.freedesktop.Platform.openh264       2.0           i     flathub           1,5 MB / 1,5 MB
 4. [✓] org.kde.KStyle.Adwaita                  5.15-21.08    i     flathub           6,6 MB / 6,6 MB
 5. [✓] org.kde.Platform.Locale                 5.15-21.08    i     flathub          24,0 MB / 345,2 MB
 6. [✓] org.kde.Platform                        5.15-21.08    i     flathub         242,4 MB / 305,5 MB
 7. [✓] com.github.chipmuenk.pyfda              test          i     pyfda-origin     74,5 MB / 74,3 MB

Warning: Not exporting file com.github.chipmuenk.pyfda.appdata.xml of unsupported type.
Installation complete.

Check:

~$ flatpak list
Name                    Application ID                    Version    Zweig      Ursprung     Installation
pyfda                   com.github.chipmuenk.pyfda        2018.03.23 test       pyfda-origin user
default                 ….freedesktop.Platform.GL.default            20.08      flathub      system
Mesa                    ….freedesktop.Platform.GL.default 21.3.8     21.08      flathub      user
Intel                   …freedesktop.Platform.VAAPI.Intel            20.08      flathub      system
Intel                   …freedesktop.Platform.VAAPI.Intel            21.08      flathub      user
openh264                org.freedesktop.Platform.openh264 2.1.0      2.0        flathub      system
openh264                org.freedesktop.Platform.openh264 2.1.0      2.0        flathub      user
Adwaita theme           org.kde.KStyle.Adwaita                       5.15       flathub      system
Adwaita theme           org.kde.KStyle.Adwaita                       5.15-21.08 flathub      user
KDE Application Platfo… org.kde.Platform                             5.15       flathub      system
KDE Application Platfo… org.kde.Platform                             5.15-21.08 flathub      user
KDE Software Developme… org.kde.Sdk                                  5.15       flathub      system

Running pyfda:

$ flatpak run com.github.chipmuenk.pyfda
...
Gtk-Message: 14:00:58.751: Failed to load module "xapp-gtk3-module"
Qt: Session management error: Could not open network socket
...

Here is the output of the "About" button in pyfda:

*pyfda Version 0.6.1 (c) 2013 - 2021 Christian Münker*
Design, analyze and synthesize digital filters. Docs @ pyfda.rtfd.org (pdf)
*OS:* Linux 5.13.0-37-generic
*User Name:* cmuenker
*Directories*
--------------------
*Function*	*Path*
====================
*Install Dir*	/app/lib/python3.9/site-packages/pyfda	
*User Module Dir *	None	
*Home Dir*	/home/cmuenker	
*Temp Dir*	/tmp	
*Config Dir*	/home/cmuenker/.pyfda	
- - - - - - -	- - - - - - - - -	
*pyFDA Config*	/home/cmuenker/.pyfda/pyfda.conf	
*Log. Config*	/home/cmuenker/.pyfda/pyfda_log.conf	
*Logfile*	/tmp/.pyfda/pyfda.log	


*External modules and libraries*
--------------------
Module	Version	Licence	Purpose
====================
Python	3.9.9 (64 Bit) 	PSF		
numpy	1.22.3	BSD	Fast array numerics	
scipy	1.8.0 (mkl)	BSD	Library for scientific computing	
numexpr	2.8.1	MIT	Fast numerical array expression	
matplotlib	3.5.1	PSF-based 	Plotting library	
Qt5	5.15.3	LPGLv3	Widget library (UI etc.)	
PyQt	5.15.4	GPLv3	Python bindings for Qt5	
Markdown	3.3.4	BSD	Markdown implementation	
docutils	0.18.1	GPLv3 a.o.	Plain text -> markup formats	
mplcursors 	0.5.1	MIT	Interactive cursors (needs Matplotlib >= 3.1)	
YOSYS	not found	ISC	Framework for Verilog RTL synthesis	

@chipmuenk thanks for the feedback.

  • I have seen that this version comes from the appdata.xml you can adapt the version there and adding new data
  • My development version of pyfda and the Flatpak version are installed independently (as it should be) but they are using the same configuration file ~/.pyfda/pyfda.conf. This is not a specific problem of the Flatpak installation, maybe I need to come up with individual configuration directories.

Yes maybe you can also choose a folder directly in the flatpak package folder, but there I don't know how to specify it. Then you can have both versions installed and the config file is different

  • What are the next steps? Should I leave it like that and just include the link to the build-repo on my Github repo before trying to publish it on Flathub.org?

I think we can publish it once on flathub, then we can setup the CI so you don't have to worry about creating a flatpak package.

  • Could you help me to write down the basic steps for preparing and generating a new flatpak? You have created a Github action which should take care of triggering the build process (thanks!) but what do I need to do if I add another module to my requirements etc.? I've started to collect some information in INSTALLATION.md in the Github repo. This file also contains stuff about building the various distribution formats which I'll move to a separate file.

If you would like to have a new version, just update the commit id (maybe later we can change it to a tag id which makes it more readable and trackable) in the flathub repository (I will give you access once created) and then flathub will create a new version for it. If you add new dependencies, the easiest way is to search on flathub if someone else already added this module to his manifest and then copy everything from there (the flatpak-pip-generator did not work properly for me)
If you look into the flathub pr you see there is a Readme with some information where I got all dependencies in the manifest. So if you would like to change some version numbers you can also have a look into those reference projects I used.

I will setup the CI for you. The CI fetches then the manifest from flathub (to have it only at one place) changes the commit id to the current commit id and it builds automatically a new version for you. This version will then published on Github in the release section.

  • Is it ok that pyfda has file system access with user rights? Shouldn't the software be more "sandboxed"? Of course, this makes it easier to import / export filters and work with configuration files, but still ... what is the preferred policy for Flatpak applications in this respect?

If possible we should add as less permissions as needed, but if we remove access to the home folder you are not able to access any file there and so you cannot import anything except the stuff in the flatpak package folder itself

If possible we should add as less permissions as needed, but if we remove access to the home folder you are not able to access any file there and so you cannot import anything except the stuff in the flatpak package folder itself

Then I think we should leave it as it is. But what happens if you install the flatpak system-wide (as sudoer)? Will the app be installed with elevated rights? I'll have to test that.

I think it would be ok to publish the app on FlatHub. But in my opinion it would be better to only trigger a build when pushing to master, what do you think?

In Gittyup we are creating for every pull request a flatpak package and store them as artifact. This is quite usefull so you can test a build quite fast. Publishing in the release section of Github is done whenever something is pushed to master

I see, that makes sense. Do you know whether there is something like a monthly limit on build jobs for free plans?

There I don't know anything, but we have four build for every pullrequest (win, 2*linux, flatpak) and we didn't have any problems yet.

@chipmuenk can you rerun the latest build? It failed, because I applied some patches to the manifest because it was for 0.7.1, I updated the version and now the manifest should run again.

Do you mean the flatpak build? Is a manual trigger of the workflow sufficient for you?

yes manual trigger is sufficient thank you! :)

@chipmuenk I think this can be closed now. Just ping me before you are creating a new release then I can update the appdata file and the version on flathub.

Yes, you're right. Thanks for the reminder and your efforts!