Provide flatpak for pyfda
chipmuenk opened 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/
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!