Description of problem: Trying to install gnotime, after an upgrade from Fedora 14 to Fedora 15 & update of all packages, fails due to an unsatisfied dependency on libgtkhtml-3.15.so.19. Version-Release number of selected component (if applicable): gnotime.x86_64 0:2.3.0-8.fc15 How reproducible: Very? Steps to Reproduce: 1. yum install gnotime Actual results: Setting up Install Process Package gtkhtml3-4.0.1-1.fc15.x86_64 already installed and latest version Resolving Dependencies --> Running transaction check ---> Package gnotime.x86_64 0:2.3.0-8.fc15 will be installed --> Processing Dependency: libgtkhtml-3.15.so.19()(64bit) for package: gnotime-2.3.0-8.fc15.x86_64 --> Finished Dependency Resolution Error: Package: gnotime-2.3.0-8.fc15.x86_64 (fedora) Requires: libgtkhtml-3.15.so.19()(64bit) Expected results: gnotime installs along with any dependencies. Additional info: When searching for existing info on this problem, I ran across a Fedora 15 review article on linux.com by Joe Brockmeier that mentioned this exact problem (http://www.linux.com/learn/tutorials/450591-fedora-15-and-the-desktop-is-it-ready?start=1).
I have a clean F15 x86_64 install from the F15 Final DVD with all updates applied, and see the same thing.
Upgraded via preupgrade. Gnotime was updated, but aforementioned missing dependency keeps it from running. Mainly, I just want to be alerted when this is fixed.
This is due to the update to GNOME 3. I also maintain glunarclock, which suffers the same issue. gnotime upstream doesn't seem to be terrible active, which would preclude a port to GNOME 3. I work with upstream for glunarclock, and have brought this up, but I'm not sure they have the cycles. I've attempted work on both of these myself, but with no success. If things don't change in short order, I'll be forced to pull both from the distribution. Sorry for the inconvenience, less-actively developed software sometimes survives major updates to software it needs (GCC, etc), but not always. -J
If you can't get it fixed, you need to get rel-eng to block and remove it from the repo. This reflects poorly on the distro and atleast one review has used this as an example of problems in Fedora.
I am also having the same issue. If gnotime won't be fixed for a while (or possibly ever), is their a comparable package anyone can recommend that does the same thing ?
(In reply to comment #4) > If you can't get it fixed, you need to get rel-eng to block and remove it from > the repo. This reflects poorly on the distro and atleast one review has used > this as an example of problems in Fedora. Agreed. I was hoping for upstream response, but I'll get this and glunarclock blocked. https://fedorahosted.org/rel-eng/ticket/4757 (In reply to comment #5) > I am also having the same issue. If gnotime won't be fixed for a while (or > possibly ever), is their a comparable package anyone can recommend that does > the same thing ? I'm not sure, unfortunately. You may find something here: http://en.wikipedia.org/wiki/Comparison_of_time_tracking_software
(In reply to comment #6) > (In reply to comment #5) > I'm not sure, unfortunately. You may find something here: > > http://en.wikipedia.org/wiki/Comparison_of_time_tracking_software Thanks. Great info. Of the open source options in that list, it looks like Rachota may be the most similar to Gnotime, from what I could tell.
See gnotime sourceforge page, I created a bug report there and it is being actively worked on now... http://sourceforge.net/tracker/?func=detail&atid=477103&aid=3310291&group_id=55463
Excellent, let me know if they put out a release.
*** Bug 719024 has been marked as a duplicate of this bug. ***
Teraya, any updates?
The developer of gnotime, Goedson Teixeira Paixao, has stated in the sourceforge bug report I submitted that the port to Gnome 3 is being worked on and that a buildable version will hopefully be ready by the end of the month.
Excellent, please keep this BZ updated as you find out more, I appreciate it!
Me too, same issue, looking forward to moving from some Windows s/w and commenting so I get notified when fixed. New here, so apologies if I didn't need to comment to get that.
Just as a future reference, you can edit the CC list and add yourself without commenting.
No word, please reopen if upstream releases a version that works with GNOME 3, so we can submit and re-review.
I've been able to get gnotime 2.3.0 to build and run on Fedora 18 (and have also built but not tested for Fedora 17). What I found was that the only real issue is that the symbols in gtkhtml version 4.x which Fedora now ships with are not compatible with the older symbols in gnotime. The solution that I've come up with which works well for me is to rebuild the older gtkhtml3 package from Fedora 14 which is the most recent version with the old symbols. I've renamed the package to gtkhtml314 and made sure there are no file conflicts with the current gtkhtml3 package so it can be installed right alongside the current gtkhtml3 without issue. With gnotime built against this older gtkhtml314 and gtkhtml314 as a dependancy for gnotime it builds and runs just fine. I've put the gnotime and gtkhtml314 packages up in my personal repository at http://www.pajamian.dhs.org/repos/fedora/18/safe/ . I've also built it (but not tested) for Fedora 17 and those packages are there as well. Not sure if this is a solution that Fedora can adopt or not, but hopefully it helps those that need this program to run on newer versions of Fedora.
I wonder if we could take gtkhtml314 and use it as the basis for a compat-gtkhmtl3. Is it parallel-installable with Fedora's gtkhtml3?
Yes it is. With the exception of the single binary "gtkhtml-editor-test" all of the files in the original gtkhtml3 were either in different directories or had different names to the newer gtkhtml3 files. In order to make it fully parallel-installable I've renamed gtkhtml-editor-test to gtkhtml-editor-test-3.14 at install time. I have both installed on my system now and they quite happily co-exist.
If you're a packager, or interested in becoming one (I could sponsor you) you could submit compat-gtkhtml3 for review. If not, I could submit it and maintain it, and then resubmit gnotime as well, since it would need re-review due to the time it's been retired. Let me know which you'd prefer.
I'm happy to leave it to you, thanks. :-)
Just got a chance to start on this, and it doesn't find gnome-icon-theme's .pc file, filing a bug there.
It was a tagging issue, probably resolved soon.
I worked around it, and had to modify things to us compat-guile18, but it works. I'll look into updating qof, since it's way out of date and can probably use modern libgda.
And of course it won't build on modern qof. ghtml.c:1101: undefined reference to `qof_print_hours_elapsed_buff' Are you familiar enough with the gnotime codebase to find a solution?
I assume this is an issue with gtkhtml? The only issue I had compiling that was a gthread-2.0 linking issue and it simply required passing an extra flag to ./configure to fix. I have no idea about qof, I didn't even know what qof was until I looked it up just now, sorry.
I'll see what upstream says. https://sourceforge.net/p/gttr/bugs/95/
Ok, between that bug and another, I worked with upstream to get 2.4.1 out the door, which can use modern qof. I'll update qof and submit the review bugs for compat-gtkhtml314 and gnotime.
qof updated in rawhide, compat-libgda retired, reviews submitted. https://bugzilla.redhat.com/show_bug.cgi?id=985916 https://bugzilla.redhat.com/show_bug.cgi?id=985917
I just realised this bug is still resolved as "CLOSED CANTFIX". Shouldn't it be changed to "CLOSED ERRATA" now (or maybe "CLOSED NEXTRELEASE"?