Bump is trivial, only copying over ebuilds, just adjust the dep to goffice in gnumeric to 0.3.3. They're "development"-versions, so I leave it up to you if you add it. The probably most interesting change is improved opendocument support.
For anyone's interest, app-office/gnumeric-1.7.6 was released awhile ago and it requires the newest x11-libs/goffice-0.3.5. Bumping is still trivial.
*** Bug 165359 has been marked as a duplicate of this bug. ***
*** Bug 165363 has been marked as a duplicate of this bug. ***
Created attachment 109201 [details] gnumeric-1.7.6.ebuild
Created attachment 109202 [details] goffice-0.3.5.ebuild
(In reply to comment #4) > Created an attachment (id=109201) [edit] > gnumeric-1.7.6.ebuild > Gnumeric 1.7.7 is out now. Works just fine by renaming your ebuild to gnumeric-1.7.7.ebuild. It also depends on the newer goffice 0.3.6, so just rename the 0.3.5 ebuild and it'll work (at least for me).
Created attachment 111161 [details] Gnumeric 1.7.7 ebuild Changed ebuild, that uses goffice 0.3.6 (which is listed as dependency on gnumeric homepage) For goffice 0.3.6 existing ebuild has only to be renamed.
Created attachment 115347 [details] goffice-0.3.7.ebuild
Created attachment 115349 [details] gnumeric-1.7.8.ebuild Gnumeric 1.7.8 is out
Someone has experienced this bug with 1.7.x version? https://bugs.launchpad.net/ubuntu/+source/gnumeric/+bug/109204 http://bugzilla.gnome.org/show_bug.cgi?id=432532
They had fix the bug. The patch is here: http://bugzilla.gnome.org/show_bug.cgi?id=432532
1.7.10...
I have been filing bugs for the gnumeric developers for about two years now. There has been major improvements in the graphing capabilities of Gnumeric (error bars, for example), and Excel import/export. Even with the minor cosmetic bugs still appearing, I would very much support releasing the 1.7 development series as ~x86 in the main portage tree. It is very useful for my actual work, whereas the present portage version (1.6) is useless for me. I'll attach my present ebuild. Note that I added a doc USE flag, to support Gnumeric help in a Gnome-less environment.
Created attachment 121367 [details] gnumeric-1.7.10 ebuild, with new doc USE It lists the correct dependencies, and has added USE=doc flag, so people can have access to help in a gnomeless system.
The newest release is now gnumeric-1.7.11 and it requires the newest goffice-0.4.2.
Created attachment 126407 [details] gnumeric-1.7.11 ebuild
Created attachment 126409 [details] x11-libs/goffice-04.2 ebuild
Created attachment 126410 [details] gnome-extra/libgsf-1.14.5 ebuild dependence for gnumeric-1.7.11
Created attachment 126418 [details] gnumeric-1.7.11 ebuild (updated for new libgsf and patch)
Created attachment 126420 [details, diff] fixes redefinition of 'go_conf_get_enum_as_str' error bug fixes redefinition of 'go_conf_get_enum_as_str' error during building
Created attachment 126422 [details] gnumeric-1.7.11.ebuild I updated the gtk+ dep to version >=2.10 according to the configure file. Also, it seems that only libgsf-1.14.4 or greater is needed. However, since neither 1.14.4 nor 1.14.5 is in the tree yet I left the dep at >=1.14.5. Finally, I cleaned up some cruft that seemed to be unnecessary. If anyone thinks I removed too much please comment. This ebuild also uses the patch from comment #20.
Created attachment 126423 [details] gnumeric-1.7.11.ebuild Forgot to remove unnecessary app-arch/bzip2 rdep.
(In reply to comment #21) > Also, it seems that only libgsf-1.14.4 or greater is needed. However, since > neither 1.14.4 nor 1.14.5 is in the tree yet I left the dep at >=1.14.5. I made the dep to 1.14.5 because libgsf-1.14.4 would not compile (problem with the make conf), and 1.14.5 did not have that issue.
deps on libgsf 1.14.4
As goffice versions are parallel installable, 0.4.x could be put in a separate slot if it break stuff that depend on 0.2.x. I have checked I can install by taking the ebuild above, and changing the SLOT value and it installed cleanly.
where are the patches against latest ebuilds in the tree?
Created attachment 129696 [details, diff] ebuild patch for 0.4.2 against 0.2.1 The only changes of significance in the patch are a bump in the version dep on libgs and the addition of a slotted installation. Different versions of goffice can be installed alongside each other, and slotted installation means that installation of 0.4.2 shouldn't break anything so long as 0.2.1 remains in tree.
Created attachment 130140 [details] gnumeric 1.7.12 ebuild Great enhancements in XLS import
Created attachment 130142 [details] goffice 0.5.0 ebuild
Created attachment 130144 [details] libgsf 1.14.6 ebuild
Created attachment 134438 [details] goffice-0.5.1.ebuild An ebuild for goffice-0.5.1 Please note, this is a slotted ebuild.
Created attachment 134442 [details] gnumeric-1.7.13.ebuild An ebuild for the 1.7.13 release.
goffice seems to depend on dev-libs/libpcre.
Created attachment 134478 [details] goffice-0.5.1.ebuild It does, I had missed that when updating the ebuild as I have it installed. The new ebuild fixes the problem, and also corrects several other dependancy issues. Thank for pointing out the error.
Created attachment 135216 [details] gnumeric-1.7.14.ebuild ebuild for the new gnumeric release.
Created attachment 135217 [details] goffice-0.5.2.ebuild And the corresponding goffice ebuild
Created attachment 139358 [details] goffice-0.5.4.ebuild ebuild for the latest 0.5 goffice, probably needs to be cleaned up in the light of the 0.6.1 ebuild in tree.
after 10 months, gnumeric-1.8 is finally in the tree with goffice-0.6.1. Thanks to everyone who tried to help get it into portage. Those releases aren't perfect so feel free to fill bugs where appropriate.
