Today I have fallen into a trap using Calibre ebook viewer program.
- On Ubuntu 24.04 I have tried to start Calibre and got error:
MESA: error: ZINK: failed to choose pdev
glx: failed to create drisw screen
-
I remembered I have updated Ubuntu packages manually at the morning and I was wrongly convinced Ubuntu installed some broken MESA package.
-
I searched the web to update MESA drivers and found found askubuntu.com link that suggests to update MESA drivers following article and rebooted Ubuntu. Still the problem.
-
Maybe this is not Ubuntu problem… I start testing application after application and I see only Calibre application is affected. I was wrongly convinced (again) that I have installed Calibre using deb package, so I have searched upstream bug tracker and have not found anything reported.
-
Then… I finally found out that I am using Calibre installed as flatpak from flathub.org.
-
I searched the bug tracker for Calibre on Flathub and found reported bug at bug tracker.
-
From bug tracker I see new manifest file was updated 23 hours ago, bug was reported 11 hours ago and first respond on bug tracker was 8 hours ago that users should revert flatpak version to previous commit and mask the flatpak.
What I see somehow we are living in a broken word, several issues in quality assurance:
-
It looks like package is built on Flathub (or underlying Github) and after flatpak is built it is not tested if flatpak is runnable. I assume this, because this flatpak can’t be run at all.
-
Like I understand there is no phasing release, when flatpak gets build on Flathub all of the users gets update (depends of frequency of new flatpak checks).
-
Now to the flatpak’s maintainers. From bug tracker it is clear he/she/it/they have recognized flatpak is broken from bug tracker. It looks to me no testing was done after flatpak was built.
-
When report was performed on bug tracker in my humble opinion the first action should be to immediately revert commit of manifest file and rebuild flatpak, to minimize the number of users affected.
-
They have reported the bug upstream which is fine but step 4 was just cut out.
-
Upstream fixed the bug, this is great and new commit to manifest file and new flatpak is built.
Now I also see that Calibre flatpak on flathub.org in not maintained by developers but probably by volunteer. Volunteer may not care as much for flatpak stability as original developer, I guess.
I have finally manage to fix a problem, but instead of this I could read a book… 
QUESTION: Are there any plans to do some improvements of quality:
- After flatpak is built at least run it and see if flatpak is at least runnable?
- Is there any plan for phrased release?
- Do some information on incidents on Flathub.org individual package web site. For example incident reported on this flatpak like 1 day ago (that maintainers are not doing the best job).
- Flatpaks that get incidents reported should not be allowed to automatically publish new versions of flatpak, but should be manually vetted by flathub personnel or/and some testers.
I know everything can get broken… but it really depends how quality assurance is governed to minimize negative impact.
Now I remember, few years ago I have had the similar problem with Calibre, but package that was installed from official Ubuntu Software. There was some Python library update that broke Calibre. At the time it was obvious Ubuntu package maintainer packaged some pre-stable release of Calibre and when problem appeared Calibre developers suggested to install new version of program from tar file. For a work-around it is fine. This was not original upstream problem, but Ubuntu’s one, not pushing easy to fix work-around (one line of code needed to be updated), but fix was not getting in for days and a lot of users affected.
That I why I though flatpak is more stable, because flatpaks are independent from host system, but… it can only be more stable if some testing is really done.
I would like to see some debate on quality improvements. I know Flathub is run by volunteers, flatpaks are build by volunteers etc but we can’t go back and suggest users to install programs from tar files, we are not in the Linux 90’s.