Red Hat Bugzilla – Bug 754516
Missing `unoconv`: Unable to load "$document" for preview
Last modified: 2013-05-27 11:37:08 EDT
Description of problem:
In GNOME Documents I tried to preview ODT file but it failed with:
Unable to load "$document" for preview
Error invoking Gd.pdf_load_uri_finish: failed to execute child process "unoconv" (No such file or directory)
When installed "unoconv" package (and it's LO uno dep) I was able to see the preview just fine.
Version-Release number of selected component (if applicable):
Add "unoconv" as a dep to g-d package.
*** Bug 752224 has been marked as a duplicate of this bug. ***
For the record: this was discussed on IRC by the desktop team and it was agreed not to add the dep, because it causes most of LibreOffice to be pulled in as a dependency; that's several hundred MB, and makes the live spin too big.
The ideal solution would be - well, unoconv to be made somewhat smaller, or alternatively, gnome-documents growing the ability to prompt for it to be installed via PackageKit when you click on a document that should be handled by unoconv.
Fedora Bugzappers volunteer triage team
Same happened on Fedora 17 beta. I would be happy with the error message suggesting: try to install unoconv package to fix it"
(In reply to comment #3)
> Same happened on Fedora 17 beta. I would be happy with the error message
> suggesting: try to install unoconv package to fix it"
Isn't this why we have PackageKit?
This also happened with a PDF file for me. Totally unnecessary, as Evince was available -- gnome-documents could have handed the file off to Evince instead.
Also: I have LibreOffice installed and upgraded from F16 to F17. Even though LO is available I still had to manually install unoconv!
Upstream is https://bugzilla.gnome.org/show_bug.cgi?id=685095 (as I cannot edit the "See Also" field in this Bugzilla).
This needs to be revisited since LO is now on the Live "CD" -- it is now senseless not to install unoconv by default, as it just makes Documents unuseful. (Though perhaps a Recommends might be more appropriate than a Requires.)
There's no "Recommends" type of dependency in RPM (and therefor there's no such thing in Fedora).
I'm still not convinced we can add this dep without making the live media be too bloated, should probably ask the desktop team.
OK thanks, I'm less stupid now. :-)
I think the previous problem with unoconv was that it would pull in libreoffice-core (230 MB), but that's already in the live CD now. A quick glance at my software history shows that only the libreoffice-pyuno package (1.6 MB) was installed when I installed unoconv (200 KB), so I suspect that space won't be an issue. (However I should note that I installed Fedora 18 with the DVD instead of the live CD and selected LibreOffice at install time; I'm not sure if any components would be different from a live CD install.)
A more significant objection to a dependency would to allow someone to install Documents but not LibreOffice.
"There's no "Recommends" type of dependency in RPM (and therefor there's no such thing in Fedora)."
That's really kind of the other way around. To a large extent, there is no soft dependency code in upstream RPM because Fedora and RHEL don't want it. Both SUSE and Mandriva (and derivatives) have in fact patched soft dependencies into their builds of RPM, and use them. (For the record, RPM 5 also implements soft deps.)
"A more significant objection to a dependency would to allow someone to install Documents but not LibreOffice."
Yes, even though the live image case is now not a problem, this is still potentially an issue.
And the right way to handle cases like this is *still* PackageKit, and I really don't know why someone doesn't code that. When you try to open an LO document with Documents, it should use PackageKit to offer to install unoconv. It's not that complicated.
oh, we could put unoconv in the default comps group without actually making Documents require it. That would at least solve the OOTB case.
Note that in GNOME 3.8, Documents will use PackageKit to automatically install unoconv in case it's missing on the system when opening a document that needs it (the feature is already implemented in the version which is currently in rawhide), so this bug becomes obsolete.
Well then I guess there's no problem. :-) (Though it still seems reasonable to have unoconv in the default install.)
https://bugzilla.redhat.com/show_bug.cgi?id=874873 is a (misassigned) duplicate of this bug
My question is why the file is loading in Documents at all - why not do the same thing as would happen in Nautilus, and open it with the application it's associated with?
This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle.
Changing version to '19'.
(As we did not run this process for some time, it could affect also pre-Fedora 19 development
cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.)
More information and reason for this action is here:
This has been fixed in GNOME 3.8 which is shipped in Fedora 19.