|Summary:||DVD-based upgrades don't let the user know they still need to run 'yum upgrade'|
|Product:||[Fedora] Fedora||Reporter:||David Rowe <david.rowe>|
|Component:||anaconda||Assignee:||Anaconda Maintenance Team <anaconda-maint-list>|
|Status:||CLOSED RAWHIDE||QA Contact:||Fedora Extras Quality Assurance <extras-qa>|
|Version:||10||CC:||dcantrell, notting, triage|
|Target Milestone:||---||Keywords:||Reopened, StringChange|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2009-02-16 21:09:39 UTC||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Cloudforms Team:||---||Target Upstream Version:|
Description David Rowe 2007-06-15 16:25:13 UTC
Description of problem: gnucash does not launch. If I launch from the comand line, the response is: --------- $ gnucash gnucash-bin: error while loading shared libraries: libgtkhtml-3.8.so15: cannot open shared object file: No such file or directory --------- I did a search for files called libgtkhtms and the result showed 4 entries, all in /usr/lib: libgtkhtml-2.so.0 (link to shared library) libgtkhtml-2.so.0.0.0 (shared library) libgtkhtml-3.14.so.19 (link to shared library) libgtkhtml-3.14.so.19.0.0 (shared library) I tried de-installing gnucash and then reinstalling it - but no joy. Version-Release number of selected component (if applicable): rpm -q gnucash returns 'gnucash-2.0.5-3.fc7' rpm -qf /usr/lib/libgtkhtml* returns: gtkhtml2-2.11.0-4 gtkhtml2-2.11.0-4 gtkhtml3-3.14.2-1.fc7 gtkhtml3-3.14.2-1.fc7 How reproducible: It happens every time I try to run gnucash Steps to Reproduce: EITHER select gnucash from the gnome/applications/office menu OR type gnucash in a terminal My installation is a new upgrade of FC6 to F7. gnucash worked OK in FC6 I tried removing gnucash and then reinstalling it - but it made no difference.
Comment 1 Bill Nottingham 2007-06-15 16:53:15 UTC
What happens if you install gtkhtml38?
Comment 2 David Rowe 2007-06-15 20:12:16 UTC
Sorry - I didn't look closely enough at the list of available packages. I saw gtkhtml3 at 3.14.2-1 and didn't notice 3.8 further down the list. OK so I loaded gtkhtml38 - but it still didn't work. This time it was missing libgsf-gnome-1.so.114 So I loaded that and this time gnucash seems to work just fine. My problem solved. Thanks very much for your help.
Comment 3 Renich Bon Ciric 2007-06-25 18:28:56 UTC
This bug confirmed on x86_64 and it was solved too. Should anyone here update the status?
Comment 4 Bill Nottingham 2007-06-25 18:30:43 UTC
It should work in the release. David - how did you install it?
Comment 5 David Rowe 2007-06-25 19:29:44 UTC
I am not sure which you are refering to by 'it'. My whole installation was originally FC6 and I updated it to F7 with a downloaded DVD image. I think I had gnucash working in FC6 - but it didn't work after the update - with the symptoms described my original message. (Sorry to be a bit vague but I have been trying several different Linux distributions using Parallels Desktop on a MacBookPro). The installs that cured the problem (i.e. gtkhtml38 and libgsf-gnome-1.so.114) I think I just did using the standard F7 gui Package Installer. I don't think I had to resort to the command line. Does that answer your question?
Comment 6 Bill Nottingham 2007-06-25 19:48:03 UTC
Yes, and, in fact, that explains it. Moving this bug.
Comment 7 David Rowe 2007-06-25 22:36:54 UTC
For your information, I had another problem after upgrading to F7 which may be relevant in the light of your new summary. Nautilus behaved very strangely. As I remember: * If you clicked on the 'Computer' item on the desktop, the list of 'device' names had %20 instead of space characters. * If you clicked on these, they did not open properly. * Help for Nautilus displayed pages of XML - not very useful. I used rpm to remove as many bits of Nautilus as I could conveniently (some bits wanted to remove lots of other packages). I then used rpm to put the bits back again. After that it seemed to work OK (although it has crashed 2 or 3 times). I wan't going to report this as I had found a workaround - but now it may be relevant - something else that didn't get updated properly between FC6 & F7.
Comment 9 Jesse Keating 2008-03-31 17:53:08 UTC
I suspect that we didn't get anything done with this for Fedora 9, and we're past string freeze again. Moving to F10.
Comment 10 Bug Zapper 2008-05-14 13:06:52 UTC
This message is a reminder that Fedora 7 is nearing the end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 7. 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 '7'. 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 7'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 7 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 please change the 'version' of this bug. If you are unable to change the version, please add a comment here and someone will do it for you. 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. If possible, it is recommended that you try the newest available Fedora distribution to see if your bug still exists. Please read the Release Notes for the newest Fedora distribution to make sure it will meet your needs: http://docs.fedoraproject.org/release-notes/ The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 11 Andy Lindeberg 2008-06-03 21:10:45 UTC
Have you encountered the same problem in Fedora 9?
Comment 12 Bill Nottingham 2008-06-04 00:39:56 UTC
I'm fairly certain it's still there, yes.
Comment 13 Bug Zapper 2008-06-17 01:36:20 UTC
Fedora 7 changed to end-of-life (EOL) status on June 13, 2008. Fedora 7 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.
Comment 14 Adam Jackson 2008-08-11 12:54:35 UTC
Reopening. Stupid bug zapper.
Comment 15 Chris Lumens 2008-08-11 14:50:46 UTC
This should be fine in F10, since we will default to enabling the updates repo. Can't really easily test this with rawhide, though.
Comment 16 Jesse Keating 2008-10-03 22:53:58 UTC
Chris, if I composed a tree that looked like the final 10 tree, would you be able to test if we at least try to use the update repo?
Comment 17 Chris Lumens 2008-10-06 13:58:21 UTC
Provided we've got a /etc/yum.repos.d/fedora-updates.repo file with enabled=1 in the install.img, yes we can test if we at least try to use it. Since there won't be an updates repo anywhere out there yet for us to use, it'll fail to grab repo metadata but at least we'll know it's working.
Comment 18 Bill Nottingham 2008-10-24 19:46:30 UTC
IIRC, the original bug isn't about enabling updates vs. not enabling updates, it's about doing an upgrade from the DVD, when you have packages installed that are from the Everything repo but not in the DVD set. Do we enable that as well on upgrades?
Comment 19 Chris Lumens 2008-10-27 14:08:26 UTC
If the Everything repo is marked as enabled=1 in /etc/yum.repos.d/whatever, then yes it will be enabled by default. However we do not have the repo selection screen enabled for upgrades at the moment. There are other open bugs for that.
Comment 20 Jesse Keating 2008-11-14 23:24:49 UTC
So I've done this, but it doesn't appear to be happening. The fedora and fedora-updates repos have enabled=1 in them, but they aren't coming up as enabled. I think something may have changed between then and now, since I don't think we enable repos that have enabled=1 in them, we just offer them up to be checked on at the software screen. Perhaps we aught to offer the same screen in upgrades so that people can add repos.
Comment 21 Bug Zapper 2008-11-26 01:55:12 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 10 development cycle. Changing version to '10'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 22 Jeremy Katz 2008-12-01 20:30:21 UTC
Fixed in my tree and will be present for F11