While I agree it’s not cool - I don’t think an application should be removed from Flathub because it doesn’t behave the way you expected.
Did you contact the author / maintainer? Maybe try reporting the problems upstream first?
There are other non desktop applications on Flathub - they’re not listed though so that could be an option.
For example https://github.com/flathub/org.mosh.mosh
Flathub is primarily focused on graphical desktop applications and not CLI/TUI applications. The following requirements ensure effective desktop integration.
1 Like
There are various CLI applications, they are just not exposed through the Flathub website because we don’t support that yet.
When that support is in place, this tool might indeed have a place. But the issue I am flagging here is that, as it is now packaged, it is intentionally masquerading as a desktop application in order to subvert that rule.
1 Like
We already mentioned there are multiple CLI applications on Flathub.
Do note that CLI applications do not require a
.desktopfile but TUI applications should have a.desktopfile withTerminal=true.
There is no rule that says only desktop applications are welcome on Flathub or that CLI applications cannot have a desktop file.
it is intentionally masquerading as a desktop application in order to subvert that rule.
Source? I have respect for what you do but I don’t understand how you can accuse upstream publicly like this.
Your original complain is valid but it’s a grudge with upstream and it has nothing to do with the app being a desktop or cli program.
Reported upstream
Source? I mean, look at it?
It’s not a grudge. It’s alarm. I found it on Flathub, thought it might be interesting and useful, but it appeared to do nothing when I ran it. It’s only because I decided to deeper investigation that I found out that it does do something: it instantly and without any indication, let alone permission, sends a profile of your system to a website where it is posted publicly.
And I’m mentioning it here because, as I said, this one has actual malicious intent, it’s easy to see that something else could. So it’s a systematic problem that Flathub should address.
I don’t understand how you can insist when we’ve already established there is no such rule to subvert in the first place. I am not discussing further on the topic of upstream’s intention to deceive if you don’t come forward with evidence other than “look at it”.
The problem with the app doing nothing when launched from GNOME Software is documented here.
Regarding the problem of uploading without user consent - someone reported the issue already https://github.com/linuxhw/hw-probe/issues/100 and while upstream didn’t fix it yet - they’ve admitted it’s a bug, expressed intention to fix and requested for help.
Hello!
Developer is here. Thanks for reporting this!
This is due to bug https://gitlab.gnome.org/GNOME/gnome-software/issues/552
Running from the AppCenter just don’t show anything where we can say “Yes, I confirm uploading of anonymized hardware info to the public database”.
Can we just change the description of the app somehow to let people understand clearly how the app works while waiting for the bugfix?
I will try to rebuild it right now with updated description.
BTW: Do you want to remove all your probes from the database?
1 Like
Started a new build: Flathub builds
I’ve described clearly how the app works. It will be updated in the AppCenter and on the Flathub site soon.
Working on adding interactive question to the app. Need to understand how it will work if not answering the question after hitting the Launch button multiple times. Can we disable the Launch button somehow and add a Tip? Can we launch the desktop app instead when hitting on the Launch button?
1 Like
Thanks @linuxhw, I appreciate it.
Updating the description is a good start. Have you considered shipping a rudimentary GUI tool? Maybe with wxPython?
But I think this really is a larger issue. Many users installing Flatpaks are not experts, and the command line esoteric and intimidating. If Flathub is going to allow command-line tools, they need to be clearly separated in some way, or else they’re going to have a bad experience. This may not be a Flathub policy, but it definitely is a GNOME Software design decision.
1 Like
We have a PyQt5 app for FreeBSD: https://github.com/bsdhw/helloSystem-Utilities/tree/master/Utilities/Hardware%20Probe.app
Need to add it to the Flatpak to execute by hitting the Launch button.
1 Like
I’ve prepared the graphical app instead of the terminal one: https://github.com/linuxhw/org.linux_hardware.hw-probe/blob/master/org.linux_hardware.hw-probe.yaml
It uses org.kde.Platform instead of org.freedesktop.Platform.
Should I just push it to flathub to replace the old one? No further actions required?
@linuxhw as long as it asks the user for consent before uploading - I guess that solves it.
Heads up - the desktop file still has Terminal=True
If you submit a PR to https://github.com/flathub/org.linux_hardware.hw-probe I’m happy to test and report
1 Like
Created PR 77 for flathub/org.linux_hardware.hw-probe
Please look.
BTW:
For some reason it downloads org.freedesktop.Platform.GL.default 20.08. Why it’s needed?
If running as root, the app can’t call xdg-open on url with the error:
Failed to connect to session bus: Failed to execute child process ?dbus-launch? (No such file or directory)
Is it a known bug?
Created PR 77 for flathub/org.linux_hardware.hw-probe
Thanks - I commented there
For some reason it downloads org.freedesktop.Platform.GL.default 20.08. Why it’s needed?
org.kde.Platform depends on it I guess
If running as root, the app can’t call
xdg-openon url with the error
I don’t know - please create an issue on your repo and mention me if you need help.
1 Like