gnumeric fails to start after update from gnumeric-1.11 and goffice-0.9 to gnumeric-1.12.0-1.fc17.i686 and goffice-0.10.0-1.fc17.i686 gnumeric: symbol lookup error: /lib/libspreadsheet-1.12.0.so: undefined symbol: gsf_timestamp_to_value libgsf has to be also updated to solve this problem. To simplify update of gnumeric it might be necessary to add such dependence from libgsf.
Hmm, that's a bit odd. Which libgsf do you have installed? The same version is available for all the branches (1.14.24), and on F-18 gnumeric starts fine. Having said that, I think it is up to gnumeric/libgsf upstream to manage their sonames properly.
I had libgsf-1.14.21-3.fc17 and gnumeric failed to start. After update to 1.14.24-1.fc17 gnumeric starts again.
Hmm, I was assuming this sort of dependencies are handled automatically by rpm. In any case, it's great that it works for you as well.
Dear Julian, this is a reason why I has opened this bug. gnumeric rpm does not handle automatically the dependency. The F-17 users will have to find a solution by their own. I do not know if it is a problem for F-18 or not, but in F-17 the standard way # yum update gnumeric will break the functionality of gnumeric (for people as me, who do not update all packages as soon as new updates are appearing). Please, do not close this bug. Or, if you think it is not important, then change the status to CLOSED WONTFIX.
I'll ask on the list on how this should be handled properly. You are right, that # yum update gnumeric will break your install. OTOH, # yum update will not, since libgsf will get updated too. May I ask why you decided to cherry-pick updates? It might help in bringing the case to the list.
I am new Fedora fan (just few months). I like stability of F-17 very much. I used several years openSUSE before. The reasons of my moving to Fedora were stability of some important for me packages, for instance, chromium-browser. In spite of chromium is not included into regular Fedora distribution, I found that chromium from fedorapeople.org was/is much better for me as in stable openSUSE. During last months I experienced only once that after package update it failed to start (it was firefox). I did not keep all old packages in cache and it was difficult to me to find older functioning package in internet. May be in the future (F-18 stable) I will do "yum update" (with keepcache=1). Sorry, for the long, not directly connected to the bug, comment.
yum update libgsf solved this problem removed: libgsf-1.14.21-3.fc17.x86_64 installed: libgsf-1.14.24-1.fc17.x86_64 gnumeric 1:gnumeric-1.12.0-1.fc17.x86_64 works now fine I did cherrypick updates too, but the rpm dependency mechanism should handle this.
It seems that it's libgsf which it at fault here for not versioning its symbols. Caolan, could you provide some insight?
yeah, it must be the case that there wasn't versioning of the additional symbols so the latest libgsf wasn't forced in during the update. Only affects selective update attempts. Workaround is do just "yum update". I guess gnumeric could add an additional libgsf >= foo if necessary, otherwise just leave it and let people do complete updates rather than partial.
To force people to do a complete system update, just to have a working gnumeric?! I do not think, this is a good option for many users. For example, VMware Player does not always support latest kernels. I believe, such users will prefer to keep an old kernel and working virtual machine, rather as to have gnumeric. And, if such packaging policy will be accepted by many other package maintainers, they possibly will switch to an other more conservative linux distribution.
Well, a complete update might be too much, but trying to update libgsf if the error you see is gsf_timestamp_to_value should be quite high on the things to try list. I can introduce a hard-coded dependency, sure, but these are quite likely introduce a false sense of security. It is nigh impossible to test if a package works with an arbitrary versions of packages, especially that you cannot download them anymore once they get superseded.
(In reply to comment #9) > I > guess gnumeric could add an additional libgsf >= foo if necessary, otherwise > just leave it and let people do complete updates rather than partial. Gnumeric already has (in configure.in): libgsf-1 >= 1.14.24 So this seems to me to be more of a pacakging issue, ie. this information was not correctly incorporated in to the created rpm.
This message is a reminder that Fedora 17 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 17. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '17'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 17's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 17 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior to Fedora 17's end of life. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 17 changed to end-of-life (EOL) status on 2013-07-30. Fedora 17 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.