Bug 962097 - Cannot open pdf file with Zathura
Cannot open pdf file with Zathura
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: zathura (Show other bugs)
rawhide
x86_64 Linux
unspecified Severity unspecified
: ---
: ---
Assigned To: François Cami
Fedora Extras Quality Assurance
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-05-11 14:20 EDT by Fredrik Nyqvist
Modified: 2014-04-15 18:45 EDT (History)
6 users (show)

See Also:
Fixed In Version: girara-0.1.6-2.fc19
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-06-07 23:42:30 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
display a warning when a file cannot be opened (2.63 KB, patch)
2013-05-28 09:18 EDT, François Cami
no flags Details | Diff

  None (edit)
Description Fredrik Nyqvist 2013-05-11 14:20:22 EDT
Description of problem:

I installed zathura from the fedora repository and try to open a pdf file with it --> pdf file won't open and I get these messages from the terminal:

error: could not open plugin directory: /usr/lib64/zathura
error: unknown file type

Version-Release number of selected component (if applicable):

0.2.2

How reproducible:

always

Steps to Reproduce:
1. Open terminal
2. run: zathura file.pdf
  
Actual results:

pdf file won't open --> error messages:

error: could not open plugin directory: /usr/lib64/zathura
error: unknown file type

Expected results:

Open and show content of pdf file

Additional info:
Comment 1 Kevin Fenzi 2013-05-11 14:26:39 EDT
Hum, yeah, this isn't right. ;) 

As a workaround: 

yum install zathura-pdf-poppler

and it should work, but you shouldn't have to do so. :(
Comment 2 Fredrik Nyqvist 2013-05-11 14:32:16 EDT
OK, thanks! That works :)
Comment 3 François Cami 2013-05-11 15:48:17 EDT
AFAICT the choice is to have zathura depend on all its plugins, which defeats the plugin philosophy, or the statu quo, which lets the end-user choose which plugin(s) to install.
I'm rather happy with the current setup, so I'm closing this (NOTABUG).
Please feel free to reopen if you do not agree.

PS: Thank you Kevin. :)
Comment 4 Petr Šabata 2013-05-13 03:44:47 EDT
I agree with François and adding that to %description (done already) was the way to go.
Comment 5 Kevin Fenzi 2013-05-13 10:35:15 EDT
Would it be possible to change the error you get with no plugins installed?

Something more like "You must install at least one plugin of ..." or something?

Just a thought.
Comment 6 François Cami 2013-05-13 10:38:08 EDT
It should be rather easy, except maybe for the upstreaming of said patch.
I'll work on it, thanks for the suggestion :)
Comment 7 poma 2013-05-27 20:16:21 EDT
(In reply to François Cami from comment #3)

Is there a chance for a one round for Fedora 18 - with a note about plugins and a Zathura-plugins-all subpackage, all by 0.2.3.?

http://lists.fedoraproject.org/pipermail/users/2013-May/435829.html
Comment 8 Wilbert Isaac Cortés González 2013-05-27 21:08:57 EDT
(In reply to Kevin Fenzi from comment #5)
> Would it be possible to change the error you get with no plugins installed?
> 
> Something more like "You must install at least one plugin of ..." or
> something?
> 
> Just a thought.

Maybe something like Amarok or Rhythymbox when you try to open an mp3 file: "This format isn't supported, do you want to look any plugin?" or sort of option/message; I think this how it should be done: giving still the option to the user; but without the headache.
Comment 9 Michael Schwendt 2013-05-28 01:48:53 EDT
Re: comment 3

> AFAICT the choice is to have zathura depend on all its plugins,
> which defeats the plugin philosophy,

This is a misunderstanding of the plug-in concept, IMO. The primary purpose of a plug-in interface is _extensibility_ and decoupling of a main program from its extensions. Making every plug-in optional to reduce install footprint (or such) is a very questionable goal. A good plug-in method makes it possible to disable individual plug-ins at run-time.

For the users of upstream Zathura in source from this also means they don't need to spend time on building plugins they don't want.

However, a distributor such as Fedora should know better. As such, the "zathura" packaging leaves much to be desired.

It would have been a better choice to make "zathura" a meta-package for easy installation, which pulls in "zathura-core" (or zathura-base) and the most important plugins (or even all plugins that are available).
Comment 10 Petr Pisar 2013-05-28 03:27:33 EDT
D(In reply to Michael Schwendt from comment #9)
> Re: comment 3
> 
> > AFAICT the choice is to have zathura depend on all its plugins,
> > which defeats the plugin philosophy,
> 
> This is a misunderstanding of the plug-in concept, IMO. The primary purpose
> of a plug-in interface is _extensibility_ and decoupling of a main program
> from its extensions. Making every plug-in optional to reduce install
> footprint (or such) is a very questionable goal.

I cannot agree with it

> A good plug-in method makes
> it possible to disable individual plug-ins at run-time.
> 
because there is no point having a plug-in installed if the plug-in is disabled.

> For the users of upstream Zathura in source from this also means they don't
> need to spend time on building plugins they don't want.
> 
> However, a distributor such as Fedora should know better. As such, the
> "zathura" packaging leaves much to be desired.
>
I wouldn't like to start argue who knows better.

> It would have been a better choice to make "zathura" a meta-package for easy
> installation, which pulls in "zathura-core" (or zathura-base) and the most
> important plugins (or even all plugins that are available).

Did you want to say a comps group?

I can see the point that package `foo' should deliver all the bits coming from `foo' sources. It's a valid policy. This should be standardized to provide consistent user experience.
Comment 11 François Cami 2013-05-28 04:17:54 EDT
FYI:
* Zathura is not a Fedora project, e.g. neither I nor Petr S. are upstream for Zathura.
* We can request changes to upstream sources, with the caveat that upstream may or may not be inclined to make them.
* We also accept patches and will forward them to upstream.

We also made our point clear - we will not make Zathura depend on all its plugins. I agree that the application should display a warning when launched without any though.

With that out of the door, I added yesterday - before getting flamed, I should say - a zathura-plugins-all packages that depends on all the plugins, and changed the description to:

"
Zathura is a highly customizable and functional document viewer.
It provides a minimalistic and space saving interface as well as
an easy usage that mainly focuses on keyboard interaction.

Zathura requires plugins to support document formats.
For instance:
* zathura-pdf-poppler to open PDF files,
* zathura-ps to open PostScript files,
* zathura-djvu to open DjVu files.
All of these are available as separate packages in Fedora.
A zathura-plugins-all package is available should you want
to install all available plugins.
"

This is in rawhide - I will push to f19+f18 in a few days.

Granted, this will only change what rpm/yum & friends display about Zathura.
Yet this is consistent with what other well-known packages do - see nagios, and nagios-plugins-all, for instance.
Comment 12 Michael Schwendt 2013-05-28 05:12:23 EDT
> because there is no point having a plug-in installed
> if the plug-in is disabled.

That depends on what the plug-in does. For the user it can make sense to disable plug-ins temporarily, e.g. if they want to choose between multiple alternative ones, or if one causes side-effects, or if it has changed to the worse temporarily. Having to uninstall/reinstall an RPM package is no substitute for that.


> I wouldn't like to start argue who knows better.

Distributors typically aim at making it easy for users to get a working system. If users need to figure out what tiny bits are missing, that's neither helpful nor convenient. On the contrary, if the packages are prepared in a flexible way, users may figure out how to install a stripped-down set of packages if they really want that. That ought not be the default. We don't do a "minimal install" with the default spin either.


Latest koji build of Zathura still advertises being "A lightweight PDF viewer". It also does that in GNOME Shell's default Software Installer. That needs to be fixed before closing this bug.


A new zathura-plugins-all package has been introduced. It would be listed/sorted somewhere between zathura-pdf-poppler and zathura-pdf, whereas a different packaging would appear like:

  zathura : Highly customizable and functional document viewer
  zathura-base : Just the graphical frontend without any plug-ins
  zathura-devel : ...
  zathura-mupdf : ...
  zathura-pdf-poppler : ...


Would that zathura-plugins-all package work as intended? For example, how would Zathura handle two different plug-ins for PDF support? (e.g. poppler and mupdf)
Does one take precedence over the other? Or is the user forced to uninstall either one?


> I can see the point that package `foo' should deliver all
> the bits coming from `foo' sources. It's a valid policy.

Is that documented anywhere? With such a policy, e.g. Audacious would not do much without its plug-ins, which reside in a separate package and are built from a different src.rpm.

For Audacious we even had to kill all separate .desktop files for the individual file formats in individual (sub-)packages, because GNOME Shell Default Applications couldn't handle the multiple files that referred to Audacious. What happens if multiple Zathura plugin .desktop files use "Name=Zathura" and advertise the same MIME type?


> Did you want to say a comps group?

No. My opinion is that a "yum install zathura" should install something useful, not a crippled frontend that cannot handle any documents at all.


As a compromise, if a warning dialog could be added, I would consider that as helpful. Agreed?
Comment 13 François Cami 2013-05-28 06:03:00 EDT
> For the user it can make sense to disable plug-ins temporarily
> e.g. if they want to choose between multiple alternative ones

Agreed, but this is on upstream side, not Fedora's.
I suggest working with them directly.

> Latest koji build of Zathura still advertises being "A lightweight PDF viewer". 

Oy, I had not updated the summary. Good catch, thank you. Fixed:
http://koji.fedoraproject.org/koji/buildinfo?buildID=422375

> how would Zathura handle two different plug-ins for PDF support? (e.g. poppler and mupdf)

I have no idea. I should mention that zathura-mupdf is not packaged yet because it has less features than the poppler plugin.

> As a compromise, if a warning dialog could be added, I would consider that as helpful. 

Zathura currently outputs to STDERR "error: unknown file type" if there is no plugin to handle the file you are trying to open.
However, the plugin-system is handled in document.c while the window system is handled in zathura.c - and there is no built-in way to pass the error from document.c to zathura.c. So while creating a new window to display an error message is easy, it does not look good, and trying to display the error in the main window is tricky though. 
I am going to add a way to forward the error from document.c to zathura.c but I am loath to patch what we ship until upstream accepts my patch.
Comment 14 Petr Šabata 2013-05-28 06:44:46 EDT
(In reply to François Cami from comment #13)
> > how would Zathura handle two different plug-ins for PDF support? (e.g. poppler and mupdf)
> 
> I have no idea. I should mention that zathura-mupdf is not packaged yet
> because it has less features than the poppler plugin.

Those two plugins conflict.

Anyhow, I dare to say zathura targets a different audience (e.g. me) than Gnome and forcing Gnome packaging practices here is somewhat off.  When I install a piece of software, I expect just that -- not a bunch of plugins I won't ever use and can't easily remove from my system while keeping the original software I wanted.  Installing xorg-x11-server-Xorg, fortunately, also doesn't pull in xorg-x11-*.  Even though it doesn't really work without any drivers installed.

Until there's some official Fedora global policy on how to handle those things, I'm against making 'zathura' some kind of metapackage.

What I do agree with is showing a message in zathura window (in addition to stderr) when a) there are no plugins installed at all, and b) a plugin required to handle the file cannot be found.  I believe this is upstreamable, however it will, according to François, require somewhat deep changes in the code first.  Until this is possible, I'd say stderr messages are just fine.
Comment 15 François Cami 2013-05-28 09:18:16 EDT
Created attachment 753920 [details]
display a warning when a file cannot be opened

Minimally invasive way to display a warning when a file cannot be opened.
Note that this is less than optimal due to the inability to detect why the file cannot be opened: either due to a missing plugin or because it does not exist.
Comment 16 François Cami 2013-05-28 09:29:22 EDT
Patch sent to upstream.
Comment 17 François Cami 2013-05-28 11:56:46 EDT
Patch accepted by upstream:
https://git.pwmt.org/?p=zathura.git;a=commit;h=cf96d52790bc8d05a9e556e33af0b6fec1a4cb0e

and fixed in rawhide:
http://koji.fedoraproject.org/koji/buildinfo?buildID=422468

I'll backport to f18/f19 in a few days.
Comment 18 Michael Schwendt 2013-05-29 09:50:27 EDT
Great, François!
Comment 19 Fedora Update System 2013-05-29 11:37:15 EDT
girara-0.1.6-2.fc19,zathura-0.2.3-4.fc19,zathura-ps-0.2.2-2.fc19,zathura-pdf-poppler-0.2.3-2.fc19,zathura-djvu-0.2.3-2.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/girara-0.1.6-2.fc19,zathura-0.2.3-4.fc19,zathura-ps-0.2.2-2.fc19,zathura-pdf-poppler-0.2.3-2.fc19,zathura-djvu-0.2.3-2.fc19
Comment 20 poma 2013-05-30 12:03:08 EDT
(In reply to François Cami from comment #17)
…
> I'll backport to f18/f19 in a few days.

zathura-0.2.2-2.fc18
http://koji.fedoraproject.org/koji/buildinfo?buildID=422951

OK, thanks Fran.
Comment 21 François Cami 2013-05-30 12:33:20 EDT
Our (Petr and I) pleasure. Please leave karma on bodhi as soon as the packages are available in updates-testing:

For f18:
https://admin.fedoraproject.org/updates/zathura-0.2.2-2.fc18

For f19:
https://admin.fedoraproject.org/updates/girara-0.1.6-2.fc19,zathura-0.2.3-4.fc19,zathura-ps-0.2.2-2.fc19,zathura-pdf-poppler-0.2.3-2.fc19,zathura-djvu-0.2.3-2.fc19
Comment 22 Fedora Update System 2013-05-30 13:52:48 EDT
Package girara-0.1.6-2.fc19, zathura-0.2.3-4.fc19, zathura-ps-0.2.2-2.fc19, zathura-pdf-poppler-0.2.3-2.fc19, zathura-djvu-0.2.3-2.fc19:
* should fix your issue,
* was pushed to the Fedora 19 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing girara-0.1.6-2.fc19 zathura-0.2.3-4.fc19 zathura-ps-0.2.2-2.fc19 zathura-pdf-poppler-0.2.3-2.fc19 zathura-djvu-0.2.3-2.fc19'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2013-9651/girara-0.1.6-2.fc19,zathura-0.2.3-4.fc19,zathura-ps-0.2.2-2.fc19,zathura-pdf-poppler-0.2.3-2.fc19,zathura-djvu-0.2.3-2.fc19
then log in and leave karma (feedback).
Comment 23 Fedora Update System 2013-06-07 23:42:30 EDT
girara-0.1.6-2.fc19, zathura-0.2.3-4.fc19, zathura-ps-0.2.2-2.fc19, zathura-pdf-poppler-0.2.3-2.fc19, zathura-djvu-0.2.3-2.fc19 has been pushed to the Fedora 19 stable repository.  If problems still persist, please make note of it in this bug report.

Note You need to log in before you can comment on or make changes to this bug.