Bug 244431

What happens if you install gtkhtml38?

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.

This bug confirmed on x86_64 and it was solved too. Should anyone here update
the status?

It should work in the release. David - how did you install it?

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?

Yes, and, in fact, that explains it. Moving this bug.

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.

I suspect that we didn't get anything done with this for Fedora 9, and we're
past string freeze again.  Moving to F10.

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

Have you encountered the same problem in Fedora 9?

I'm fairly certain it's still there, yes.

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.

Reopening.  Stupid bug zapper.

This should be fine in F10, since we will default to enabling the updates repo.  Can't really easily test this with rawhide, though.

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?

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.

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?

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.

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.

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

Fixed in my tree and will be present for F11