Bug 401039

Summary:	Wrong flatpak installation instructions, install fails; at least two problems at same time
Product:	[Applications] krita	Reporter:	ocumo <kxk-ocumoatbugskde>
Component:	Documentation	Assignee:	Krita Bugs <krita-bugs-null>
Status:	RESOLVED FIXED
Severity:	normal	CC:	halla
Priority:	NOR
Version First Reported In:	unspecified
Target Milestone:	---
Platform:	Other
OS:	Linux
Latest Commit:		Version Fixed/Implemented In:
Sentry Crash Report:
Attachments:	Snapshot of the bad instructions in krita.org download page

Description ocumo 2018-11-14 16:53:10 UTC

SUMMARY
Instructions in https://krita.org/en/download/krita-desktop/ for installation of Krita via Flatpak are wrong. There are at least to problems:

1. Installation command is truncated/incomplete. Missing location causes error: 'LOCATION must be specified'

2. Even if user manages to discover what the "location" is, the installation command will fail again if the user had done a local flatpak installation: `Unable to load summary from remote flathub: GPG verification enabled, but no summary found (check that the configured URL in remote config is correct)`.

This means the bad instructions in the Krita download page assume (and doesn't say it) that the user necessarily has a global installation (thus missing yet another piece in the command), generating such confusing error message that's very difficult for a non flatpak expert to figure out what's wrong.

STEPS TO REPRODUCE FIRST PROBLEM
1. Paste the "official" Flatpak Krita installation command from https://krita.org/en/download/krita-desktop/ on a Linux/Mac console and press Enter.
flatpak remote-add --if-not-exists flathub

OBSERVED RESULT FIRST PROBLEM
The following error appears immediately:
'LOCATION must be specified'

STEPS TO REPRODUCE SECOND PROBLEM
2. In a system in which the Flapak installation is local (i.e., *not global*), paste the above command but fixed by adding with the missing location:
flatpak remote-add --if-not-exists flathub flathub https://flathub.org/repo/flathub.flatpakrepo

OBSERVED RESULT SECOND PROBLEM
The following error appears immediately:
`Unable to load summary from remote flathub: GPG verification enabled, but no summary found (check that the configured URL in remote config is correct)`.

EXPECTED RESULT
Installation instructions should be correct, they should work and don't generate error messages nor send the user into complicated troubleshooting.

ADDITIONAL INFORMATION
1. There is an additional issue that may affect some users. This is not related with Krita's above instructions, it's a Flatpak issue, but I mention it here because it's important and nowhere in Krita's documentation I could find any mention to it:

Once installed, the flatpak version of krita fails to automatically recognize and/or use any existing Krita resources/configuration folder, and will create its own, brand new one. This means that users installing krita via flatpak after having installed and configured krita with a different method, will get a totally unconfigured installation and big disappointment if the user is not comfortable making symbolic or hard links, or copying/moving around configuration folders, and the downsides and risks of the different options.

2. Last, but even **more important** that all above:
These bad instructions have existed there since long time now and I have notified and provided full details to Krita's team in another report (which is only indirectly related). Reply was that this was some _other_ team's responsibility, not Krita (??..that's odd to me...). Since I didn't get specifics of who, and nothing happened in the mean time, I am opening this report in the hope that someone responsible from the Krita webpages may know who should take ownership for this problem or what to do, if anything.

I very much appreciate if -please- this time this problem is not responded again with a "this is somebody else's problem" type of answer. The time I have invested in all these issues is *very* significant and it's not acceptable that such efforts are put down with a procedural/bureaucratic or semantics excuse without an effort to at least provide a positive acknowledge of this collaboration.

To be clear: we users, don't really have to or even want to know how a team handles their internal affairs. If you expect that, you will loose credibility, loose support, and we all loose: supporters become detractors.

Thanks for kindly understanding this request and taking it positively and professionally, if that's not asking too much. A no answer is better otherwise. I do not want to waste more of my time in this type of argumentations, it's a shame I have been forced to.

Comment 1 ocumo 2018-11-14 17:07:52 UTC

Created attachment 116310 [details]
Snapshot of the bad instructions in krita.org download page

Attached a snapshot of the bad instructions in https://krita.org/en/download/krita-desktop/ download page, as of 2018-11-14T17:06:50.014Z.
It hasn't change since long time.

Comment 2 Halla Rempt 2018-11-15 07:33:43 UTC

We replaced the download instructions with a link to flathub, so we no longer have to keep them up to date. I have not been able to find a previous bug report by you about flatpak. The flatpak is not maintained by the Krita team, so we cannot work on flatpak-specific bugs; we only maintain the appimage and the *buntu ppa, as noted on the download page.

Comment 3 ocumo 2018-11-15 21:44:00 UTC

First of all, thank you very much for taking quick actions.

I absolutely agree that this is probably the best solution, given the risks of overloading your limited resources.

Just for completeness and clarification of your comment: as I wrote above, "I have notified and provided full details to Krita's team in another report (which is only indirectly related)", and here it is: https://bugs.kde.org/show_bug.cgi?id=392251#c20, including attachment with details, and your reply: https://bugs.kde.org/show_bug.cgi?id=392251#c21 .

I didn't say it was a dedicated bug report. The original report in that thread is "only indirectly related" but it *is*, and it is explained there why. I didn't include the above links precisely to avoid entering into a pedantic ping pong of evidences and counter evidences, when the main goal was just to alert the team about an important issue with the documentation.

Once again, I do not appreciate or indulge discussing semantics over the issues. I notified a problem, with a big deal of details, in a justified context; I got a main developer's attention, plus a direct reply to the specific issue and attached information. That's it.

Not enough? Then the reply could have been specific: "Please do such and such to get this moving forward".

No, the reply did not say what else I could/should do. So: The reply wasn't good, but the matter of fact is that the notification went through, to at least one notorious member of the team. So: was my job done? Apparently, not!

I sincerely hope that you are not telling me that since I didn't write those words in another separate document with another layer of bureaucracy, is reason enough for you to have dismissed the alert. It's like somebody would yell at me that my house is on fire and I would ignore it because it didn't came in a certified letter.

I used to work in a very bureaucratic and huge corporation, and yet nobody would ever dismiss a valid, clear complaint just because it was written in the Form A231b instead of the Form A231B. Why even a huge, slow, heavy corporation would get that and a small non-for-profit project wouldn't? I don't get it.
That's probably why I get so cranky about this.

My experience in the Kde bug tracking system proves me that my perception of a modern agile mindset is not compatible with older paradigms and bad habits that are still popular amongst many projects. It's getting really painful to contribute.

Hopefully things get better in the future. Thanks for all the hard work you guys do, I really respect that.

Comment 4 Halla Rempt 2018-11-15 22:13:10 UTC

It's very simple. We cannot manage. We get about 1500 bug reports a year for krita, most of them very hard to deal with. Well, I say "we", but in fact, it's mostly _me_. Have a heart: what a great big company has the resources for, _I_ don't. There are a few other people who on and off triage bugs, but mostly it's just me.

Report one issue per bug report. Otherwise I cannot keep track.

Be as clear and concise and to the point as possible, otherwise I cannot manage to understand what's it all about in the time I have for checking the report.