I find myself sending a few faxes a year and my distribution (Fedora) doesn't include efax-gtk by default. I figured I'd get it running from flathub (as opposed to trying to get it included in Fedora).
Part of the submission process is to offer ownership of the app repository to the efax-gtk author. Chris, would you like access to submit updates to the version on flathub?
Another portion of the process is to send any patches upstream.
Attached is the appdata file that I created that provides metadata for the app. The spec for this is here:
That sounds like a great idea. I don't know how flatpak works so I am content for you to have ownership of the app repository on flatpak. All I would ask is that the latest version of efax-gtk is used (which is what you propose). I see there is a build failure on the part of the flatpak bot, which appears to be because efax-gtk requires a dbus session message bus to be running for the user and it appears that that is not the case. See the README under the heading "DBUS". Since many other programs require this also, I presume there is some way of setting this up in the flatpak environment. GNOME and KDE provide such a session bus automatically.
Chris
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
On the appdata file, note that efax-gtk is GPL-2.0 or higher, not LGPL (the c++-gtk-utils library used by efax is LGPL-2.1 or higher, and of course GTK is LGPL-2 or higher).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hubert (flathub reviewer) helped me with the dbus permissions and I also fixed the license in the appdata file.
One remaining question: do you have any higher resolution icons? It looks like flathub is preferring 128x128 icons. I guess if necessary, I can scale the .png in the source accordingly, but wanted to check. I'm also using a larger icon from the obsolete "gfax" program in the meantime.
Once the package goes through review it's pretty easy to do updates: make a pull request updating the urls and shas of the new source version. You are welcome to submit those, and I am happy to do it as well.
Thanks again,
Wade
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I can't help with the icons I am afraid. The ones supplied are based on what was needed to get GTK working some 10 or so years ago when efax-gtk was first written.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
On a postscript viewer, you can use evince (which is what I use - ' evince --preview'), and KDE has something equivalent. Any PS-capable viewer will do.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I ended up using "xdg-open" as the default viewer. That works inside the app sandbox to launch an already installed app on the host system based on mime-type and extension.
Thanks!
Wade
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
One more issue that I'm running into with this is that by default lock files are created in "/var/lock", but that directory doesn't exist inside the flatpak container filesystem.
I've also noticed that directory isn't writeable on my distribution (fedora 34 and centos 7).
Is that locking mechanism to have exclusive access to the serial port needed any longer?
Providing a lock file is I think desirable where different users may wish to access a single hardware resource, and /var/lock is the traditional directory for that. As the standard directory for this, it is the preferred choice because it will not only prevent more than one efax-gtk user accessing the modem device concurrently, it will also prevent a user of a different program doing so concurrently with a efax-gtk user provided that other program also respects lockfiles. /var/lock should preferably be world readable or writable, or if not it should be writable by groups 'lock', 'uucp' or 'dialout' (depending on the distribution's convention) and users of efax-gtk should be put in that group.
As an alternative I guess you could use '/tmp' as the lock file directory, which I imagine would work OK with flatpak, as the lock file directory is configurable in efax-gtk's settings, but it would not prevent a user of a different program having concurrent access. Lastly you should be able to patch the source so as not to pass efax the -x option, which as I read it would stop efax using a lock file entirely. To do that your could just patch out lines 660-662 in main.cpp.
Last edit: Chris Vine 2021-07-08
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello,
I'm in the middle of submitting efax-gtk to flathub:
https://github.com/flathub/flathub/pull/2385
I find myself sending a few faxes a year and my distribution (Fedora) doesn't include efax-gtk by default. I figured I'd get it running from flathub (as opposed to trying to get it included in Fedora).
Part of the submission process is to offer ownership of the app repository to the efax-gtk author. Chris, would you like access to submit updates to the version on flathub?
Another portion of the process is to send any patches upstream.
Attached is the appdata file that I created that provides metadata for the app. The spec for this is here:
https://freedesktop.org/software/appstream/docs/chap-Quickstart.html
I still need to sort out some remaining issues.
Wade
Hi,
That sounds like a great idea. I don't know how flatpak works so I am content for you to have ownership of the app repository on flatpak. All I would ask is that the latest version of efax-gtk is used (which is what you propose). I see there is a build failure on the part of the flatpak bot, which appears to be because efax-gtk requires a dbus session message bus to be running for the user and it appears that that is not the case. See the README under the heading "DBUS". Since many other programs require this also, I presume there is some way of setting this up in the flatpak environment. GNOME and KDE provide such a session bus automatically.
Chris
On the appdata file, note that efax-gtk is GPL-2.0 or higher, not LGPL (the c++-gtk-utils library used by efax is LGPL-2.1 or higher, and of course GTK is LGPL-2 or higher).
Hi Chris,
Thanks for the blessing and feedback.
Hubert (flathub reviewer) helped me with the dbus permissions and I also fixed the license in the appdata file.
One remaining question: do you have any higher resolution icons? It looks like flathub is preferring 128x128 icons. I guess if necessary, I can scale the .png in the source accordingly, but wanted to check. I'm also using a larger icon from the obsolete "gfax" program in the meantime.
Once the package goes through review it's pretty easy to do updates: make a pull request updating the urls and shas of the new source version. You are welcome to submit those, and I am happy to do it as well.
Thanks again,
Wade
I can't help with the icons I am afraid. The ones supplied are based on what was needed to get GTK working some 10 or so years ago when efax-gtk was first written.
On a postscript viewer, you can use evince (which is what I use - ' evince --preview'), and KDE has something equivalent. Any PS-capable viewer will do.
Ok, this is now available on flathub.org: https://flathub.org/apps/details/net.sourceforge.efaxgtk
I ended up using "xdg-open" as the default viewer. That works inside the app sandbox to launch an already installed app on the host system based on mime-type and extension.
Thanks!
Wade
One more issue that I'm running into with this is that by default lock files are created in "/var/lock", but that directory doesn't exist inside the flatpak container filesystem.
I've also noticed that directory isn't writeable on my distribution (fedora 34 and centos 7).
Is that locking mechanism to have exclusive access to the serial port needed any longer?
See: https://github.com/flathub/net.sourceforge.efaxgtk/issues/1
Thoughts?
Wade
Providing a lock file is I think desirable where different users may wish to access a single hardware resource, and /var/lock is the traditional directory for that. As the standard directory for this, it is the preferred choice because it will not only prevent more than one efax-gtk user accessing the modem device concurrently, it will also prevent a user of a different program doing so concurrently with a efax-gtk user provided that other program also respects lockfiles. /var/lock should preferably be world readable or writable, or if not it should be writable by groups 'lock', 'uucp' or 'dialout' (depending on the distribution's convention) and users of efax-gtk should be put in that group.
As an alternative I guess you could use '/tmp' as the lock file directory, which I imagine would work OK with flatpak, as the lock file directory is configurable in efax-gtk's settings, but it would not prevent a user of a different program having concurrent access. Lastly you should be able to patch the source so as not to pass efax the -x option, which as I read it would stop efax using a lock file entirely. To do that your could just patch out lines 660-662 in main.cpp.
Last edit: Chris Vine 2021-07-08