As announced earlier today in the gramps-announce ml[1], the gramps project released the first 3.3.0 version today. The project page hasn't been updated yet, but there's already a new section in the wiki about the new version[2] I'm going to attach the diff to the 3.2.6 version, the update patch for bsddb3 and the complete 3.3.0 ebuild I've used locally to test the new version. The README file in the tarball has a note that the pyexiv2 and osmgpsmap packages are "strongly" recommended. AFAICS, we don't have them on Gentoo yet. [1] - http://sourceforge.net/mailarchive/forum.php?thread_name=BANLkTim96ndBNgr6q9Za0WZCf%2BV5wyJpVw%40mail.gmail.com&forum_name=gramps-announce [2] - http://www.gramps-project.org/wiki/index.php?title=Gramps_3.3_Wiki_Manual
Created attachment 276846 [details, diff] Diff to the gramps-3.2.6.ebuild in the tree
Created attachment 276850 [details, diff] Updated patch for the bsddb3 support
Created attachment 276852 [details] Complete gramps-3.3.0 ebuild
Thank you very much, I also started working on the Gramps 3.3.0 ebuild yesterday. The patch is identical, but I also added pygoocanvas as dependency, which is needed for some plugins.
Some optional dependencies could be added. The version bump itself happened, the package is hard masked because of database changes...give it at least one more minor revision bump.
The gramps project released version 3.3.1 on October 2nd[1]. I've updated osm-gps-map in my overlay[2] and added a new package python-osmgpsmap[3] for the python bindings. I'll have to talk to to the sci and python teams about adding them to the tree. I'm in the process of testing gramps-3.3.1 locally. I'll submit the ebuild here when I finish testing it. [1] - http://gramps-project.org/2011/10/version_3-3-1/ [2] - git.overlays.gentoo.org/gitweb/?p=dev/jmbsvicetto.git;a=tree;f=sci-geosciences/osm-gps-map [3] - http://git.overlays.gentoo.org/gitweb/?p=dev/jmbsvicetto.git;a=commitdiff;h=446e31fe1fa83ed6d268b1656e57e83610baacb2
I bumped to 3.3.1 without any big changes. Hard mask removed. Jorge, you can add yourself as maintainer, too
FYI: Version bump to Gramps 3.4.0 (Tuesday, May 22nd, 2012) Suppose to be some new libwebconnect stuff, allowing users to export their trees to a remote WWW server.
(In reply to comment #8) > FYI: Version bump to Gramps 3.4.0 (Tuesday, May 22nd, 2012) Suppose to be > some new libwebconnect stuff, allowing users to export their trees to a > remote WWW server. The request for the new version bump should be made in a new bug. I've been looking at 3.3.2 and 3.4.0 but have yet to be able to get it to install to a sane file structure.
In reference to Comment #9, since you have some working/non-working gramps-3.4.0.ebuild started, would be best for you to initiate the new bug which might get others with spare time during this summer to fix. I'm quite busy now, but might take a look in my spare time too.
(In reply to comment #10) > In reference to Comment #9, since you have some working/non-working > gramps-3.4.0.ebuild started, would be best for you to initiate the new bug > which might get others with spare time during this summer to fix. I'm quite > busy now, but might take a look in my spare time too. I also tried it and since 3.3.2 ggettext.py is not properly installed and byte-compiled by the build system, thus Gramps is not starting. Just copy over the ebuild, merge it and try to run Gramps. Up to now I was not able to find the problem.
sci-geosciences/osm-gps-map is now in portage, seems we can drop pyexiv dep, but PyICU is still required: http://svn.code.sf.net/p/gramps/code/branches/maintenance/gramps40/README "No longer needed in 4.0: pygoocanvas, pygtk, pyexiv2"
*** Bug 533684 has been marked as a duplicate of this bug. ***
*** Bug 464954 has been marked as a duplicate of this bug. ***
*** Bug 492870 has been marked as a duplicate of this bug. ***
Anybody completed any EBuilds for the recent gramps-4.1.* releases? As of this date, the Portage tree only contains version up until gramps-3.4.5.
I should note, gramps-4.1.1 fixes a bug with UTF-8 GEDCOM imports and Ancestry.com appears to be exporting family tree GEDCOM files in UTF-8 format now. $ file *.ged MyFamilyTree-20130414.ged: GEDCOM genealogy text version 5.5\015, ISO-8859 text, with CRLF line terminators MyFamilyTree20150119.ged: GEDCOM genealogy text version 5.5\015, UTF-8 Unicode text, with CRLF line terminators
Created attachment 394388 [details] gramps-4.1.1 ebuild
Created attachment 394390 [details, diff] gramps resourcepath patch
(In reply to Roger from comment #17) FYI I attach my current version, distutils-r1 based. One problem with it is that, at least with python 3, you need to remove the precompiled directories __pycache__ from /usr/lib/python3.4/site-packages/gramps because otherwise it fails with "ImportError: cannot import name 'PluginWindows'". The module is there but due to the compilation happening in a sandbox at some other location, it is not found when the precompiled files are used in their new location. I did read the distutils-r1 documentation but could not find a fix...
gramps-4.1.1.ebuild: * QA Notice: gramps.desktop does not have a semicolon as the trailing char. (I use DWM. ;-) * I checked my /usr/lib/python2.7/site-packages/gramps/ folder prior to installing, and the folder contained many gramps byte compiled (py/pyc/pyo) files dated Jan 19, 2015. Now there are five sub-folders, with all files dated Jan 20, 2015, except for one or two (__init__.py, grampsapp.py) dated Oct 24, 2015. (Those files look to be renamed to *.pyc & *.pyo and the sub-folders are dated Jan 20.) So it looks as if I'm not having any problems with your stated issue here with python-2.7 during runtime. Other then this, compiles fine on 64bit Intel without any other apparent warnings or errors. * Missing RUNTIME dev-python/pyicu depend! This package is only currently found within Sunrise Portage! (Guess this pyicu package needs to get pushed to main Portage, before gramps-4.1 is included in Portage.) After installing, I now get the following error during execution of gramps-4.1: $ gramps 2015-01-20 13:36:14.527: ERROR: grampsgui.py: line 361: Gramps failed to start. Please report a bug about this. Traceback (most recent call last): File "/usr/lib64/python2.7/site-packages/gramps/gui/grampsgui.py", line 335, in __startgramps from .logger import RotateHandler, GtkHandler File "/usr/lib64/python2.7/site-packages/gramps/gui/logger/__init__.py", line 65, in <module> from ._gtkhandler import GtkHandler File "/usr/lib64/python2.7/site-packages/gramps/gui/logger/_gtkhandler.py", line 24, in <module> from ._errorview import ErrorView File "/usr/lib64/python2.7/site-packages/gramps/gui/logger/_errorview.py", line 36, in <module> OK. Bingo, your bug concerning not cleaning of /usr/lib??/python?.?/site-packages/gramps/!?! And these are the ones dated Oct 24 2014. So I removed (rm -rf)_/usr/lib64/python2.7/site-packages/gramps, and recompiled gramps-4.1 I still get the above error. But now the folder has many more files, some dated Sep. (Some really odd dates on the files.)
(In reply to Roger from comment #21) > After installing, I now get the following error during execution of > gramps-4.1: > $ gramps > 2015-01-20 13:36:14.527: ERROR: grampsgui.py: line 361: > Gramps failed to start. Please report a bug about this. > > OK. Bingo, your bug concerning not cleaning of > /usr/lib??/python?.?/site-packages/gramps/!?! And these are the ones dated > Oct 24 2014. > > So I removed (rm -rf)_/usr/lib64/python2.7/site-packages/gramps, and > recompiled gramps-4.1 I still get the above error. But now the folder has > many more files, some dated Sep. (Some really odd dates on the files.) I suggested to only remove the precompiled files, which are __pycache__ directories for python3 and *.py[oc] files for python2. After removing these files, gramps should run (it does here). Reinstallation, of course, also installs the (bad) precompiled files again.
Bernd, thank you for providing an ebuild for the latest version of gramps. Yesterday I gave it a shot, and now want to give some feedback: Your "delete __pycache__" trick wasn't necessary for me, because I'm still using Python version 2.7. Nonetheless, I was greeted also with the PluginWindows error. But I found an easier way to make it stop. Gramps seems to be unable to load the plugin because of a simple typo(?). The second patch, which I'll upload, fixes this minor problem. (Does anybody know, why they could assume that __doc__ is already set?) The first patch simply adds minimal error handling (at least printing errors), which is imho the more proper way to do and which I used to find the error. If you apply both (for testing simply copy them into /etc/portage/patches/app-misc/gramps/), the startup error should disappear. There were additional problems which included two error messages complaining about missing webkit and missing OsmGpsMap. As both packages (net-libs/webkit-gtk and sci-geosciences/osm-gps-map) are installed, the errors seem to come from not expected versions. Gramps 4.1 seems to need a more recent version of OsmGpsMap, which uses GTK version 3. The current OsmGpsMap version in the portage tree (0.7.3) still uses GTK+ v2. Bug #499592 takes care of OsmGpsMap version 1.0.2. The provided ebuild works for me, after copying osm-gps-map-0.7.3-fix-docs-location.patch from the original portage tree to the overlay's files directory. Gramps suggests to fix the webkit problem by installing "gir1.2-webkit-3.0". The content of this package is minimal (http://packages.ubuntu.com/de/trusty/amd64/gir1.2-webkit-3.0/filelist). Nonetheless, I gave net-libs/webkit-gtk:3 a try, and after several hours of compiling I can confirm that slot 3 does the trick. I had also problems that two icons were missing (gtk-edit.png and gtk-index.png). I don't fully understand why they are missing and who should be responsible for them, but I was able to "fix" the problem by copying them from "/usr/share/gtk-doc/html/gtk3/gtk-{edit,index}.png" to "/usr/share/icons/gnome/24x24/actions/". (x11-themes/gnome-themes-standard seems to include them as well, but installing it didn't fix the problem.) At this point the basic things seem to work (I haven't tested thoroughly). There's only a paint/repaint problem in the side bar of the geography tab, and of course the PyICU missing warning during startup. (Note: I had several other warnings which came from an orphaned and obsolete /etc/pango/pango.modules.) Bernd, could you please check whether webkit-gtk is necessary for you as well and make it together with osm-gps-map an (optional) runtime dependency in your ebuild?
Created attachment 396120 [details, diff] print errors patch Prints errors when importing PluginWindows fails. Not necessary to make gramps run, but good for debugging purposes.
Created attachment 396122 [details, diff] Initialize __doc__ variable patch Initializes the __doc__ variable in gramps/gen/datehandler/_datestrings.py instead of appending to it. Appending throws an error if __doc__ is not initialized yet.
(In reply to Sven Wehner from comment #23) > Bernd, thank you for providing an ebuild for the latest version of gramps. > Yesterday I gave it a shot, and now want to give some feedback: Your "delete > __pycache__" trick wasn't necessary for me, because I'm still using Python > version 2.7. Nonetheless, I was greeted also with the PluginWindows error. > But I found an easier way to make it stop. Gramps seems to be unable to load > the plugin because of a simple typo(?). The second patch, which I'll upload, > fixes this minor problem. (Does anybody know, why they could assume that > __doc__ is already set?) The first patch simply adds minimal error handling > (at least printing errors), which is imho the more proper way to do and > which I used to find the error. > If you apply both (for testing simply copy them into > /etc/portage/patches/app-misc/gramps/), the startup error should disappear. Thanks a lot, it does! It's interesting how this __doc__ problem only occurs with those precompiled files... In your first patch, could you change the print statements to functions please? It fails under python3 otherwise. > Bernd, could you please check whether webkit-gtk is necessary for you as > well and make it together with osm-gps-map an (optional) runtime dependency > in your ebuild? I'm not aware of optional runtime dependencies settable in ebuilds. I didn't get messages regarding osm-gps-map here despite having the older version, and no missing icons. I had webkit-gtk:3 installed anyway. If gramps refuses to run without it, this should surely be added as a dependency; if simply part of the functionality is disabled, one could either leave it to the user to install the optional packages, or add USE flags to pull in the packages automatically if a certain functionality is requested. For my taste, I'd prefer the former if gramps basically also works without.
Bernd, thank you for giving it a try. The patch that prints errors isn't necessary to run anything, it just helped to find the problem. Nonetheless, I'll upload an updated version. Regarding webkit-gtk:3 and >=osm-gps-map-1.0: Both packages are optional, so you don't need them. Gramps just informs the user with two warning dialogs, which have "don't show this message again" check boxes. Maybe you checked them before. Do you have a running geography tab with the older version? I just checked if it works with version 0.7.3, it doesn't, at least for me. Imho the geography tab is informative, and I would recommend everyone to enable it. Webkit seems to be necessary to show html content within gramps (see https://gramps-project.org/wiki/index.php?title=GEPS_029:_GTK3-GObject_introspection_Conversion#WebKit_for_Htmlrenderer). I don't know if I ever used this feature. On the other hand, the user should be able to know what is missing before playing around (webkit-gtk took me several hours to compile, and it seems like webkit-gtk:2 is the "default slot"). > "add USE flags to pull in the packages automatically if a certain functionality is requested" I would prefer this way! How about a default disabled geography use flag that pulls in >=osm-gps-map-1.0 within RDEPEND, and a default disabled html use flag that pulls in webkit-gtk:3 within RDEPEND. Bernd, could you please do this? (In my last message I mentioned the paint/repaint problem in the geography tab, the error has been filed before and a working fix has been commited today: https://gramps-project.org/bugs/view.php?id=7615 and http://sourceforge.net/p/gramps/source/ci/dadb588d837b8aa6141139387a6bf6cfc9046b25/)
Created attachment 396246 [details, diff] print errors patch (v2) Use print as a function, and use traceback.print_exc().
Created attachment 396258 [details] Updated ebuild Okay, updated ebuild uploaded, incorporating your patches and the USE flags!
This bug seems confusing, or is it now just missing the current gramps EBuild version for version bumping? The current Portage tree version of gramps is "=app-misc/gramps-3.4.5-r1", while the latest is gramps-4.1.1, but this bug only now currently lists the older EBuilds titled "gramps-3.3.0.ebuild", etc. Studying this bug a little further, I see the gramps-4.1.1 ebuild recently deleted or updated; and now is renamed to simply "Updated ebuild" I propose renaming the named file/attachment "Updated ebuild", to the gramps-4.1.1.ebuild version (or to the latest version for version bumping) so developers can possibly process this bug and incorporating within the Portage tree. ;-) 1. Rename "Updated ebuild" to gramps-4.1.1.ebuild 2. Rename the attached patches to having suffix patch, using lower case within filenames? (ie. initialize __doc__ variable.patch, print-errors.patch, ...) 3) Clean any not needed attached files? I still get bsd module not found error after compiling using the "Updated ebuild" (AKA gramps-4.1.1.ebuild) Seems this updated ebuild is missing applying the "patch for the attached bsddb32 support patch. Currently the gramps-4.1.1.ebuild is only applying the following patches: gramps-4.1.1-doc-initialize.patch gramps-4.1.1-print-guiplug-error.patch gramps-4.1.1-resourcepath.patch I added the bsddb3 support patch (or gramps-4.1.1-use_bsddb3.patch), but the gramps-4.1.1.ebuild errored when applying the patch.
The " Updated patch for the bsddb3 support" attachment patch is referencing an old config.py file location. The current config.py referenced by this patch is likely "gramps-4.1.1/gramps/gen/config.py" instead of "gramps-3.3.0/src/config.py" designated within the patch.
Created attachment 397336 [details, diff] gramps-4.1.1-use_bsddb3.patch config.py referenced by this patch is now located within gramps-4.1.1/gramps/gen/config.py. There is another config.py file deeper within this folder, but I do not think it also needs editing as things "just work" now. Besides, there's no reference to bsd support within the other config.py file!
Created attachment 397340 [details] gramps-4.1.1.ebuild 1. Renamed __doc_initialization.patch to gramps-4.1.1-python-doc-init.patch 2. Added gramps-4.1.1-use_bsddb3.patch I have a working install of gramps-4.1.1 here, aside from an initial OsmGpsMap error. For which has an option to be permanently suppressed for users not wanting USE="geography", which requires ">=sci-geosciences/osm-gps-map-1.0" and this version is not even yet within Portage. Let me know if you guys want me to delete the old files and rename the remaining files more appropriately so a developer can simply push this version bump!
print errors patch (v2) is also no accurately named, and within the ebuild is named as ${FILESDIR}/${P}-print-guiplug-error.patch. So four patches in total.
Oh I see what going on with attachments. They're listing the description instead of intended file name. I never understood the logic of the person used to design the Attachment interface. For me, I don't have to nor want to click five times to download the attachment, or just to see the server side file name.
Roger, I agree with most of your comments. So sorry for messing up patch names. The "print-guiplug-error.patch" is not necessary, I would even suggest to remove it from the ebuild as it only helped to debug a problem. You're also right that >=osm-gps-map-1.0 is not even part of the official portage tree. Nonetheless it is the version that is necessary to support the geography tab, and there is an ebuild in #499592. Can somebody add this as a dependency of this bug? I would also suggest to raise the required version of gtk+:3. At the moment there's no specific version required, just the slot. The reason to raise it is that there seems to be problem with GTK <3.14.8, see https://gramps-project.org/bugs/view.php?id=7772, which references https://bugzilla.gnome.org/show_bug.cgi?id=742636, which mentions https://github.com/GNOME/gtk/commit/561ff51abb9629c11855d346432cb1792b117815 or https://github.com/GNOME/gtk/commit/4a5d06fb72d10d0df9656ac0cdea68e5f296c67f. Gramps froze about every tenth modification I made, with an ~arch gtk+:3 (version 3.14.8) it seems to run stable. Bernd, Roger, do you have problems with freezing, and what's your gtk+ version?
Well, according to the Bugzilla user interface, your patch names are apparently fine with them. But as you can see, I just document the patch file name within the description as well, as it makes easier reading with a simple glance. And the fact one doesn't have to click so many times to see the real patch file name. As far as the Gramps user interface freezing with specific versions of GTK-3 or less, I'm unaware of this. What hinders my usage of Gramps, is the fact it doesn't provide a similar family member viewing layout as Ancestry.com. With Gramps, I can barely see much at all as to the lineage. Nevertheless, I'll keep an eye out for this UI bug. So delete "print errors patch" or AKA gramps-4.1.1-print-guiplug-error.patch, and remove this patch from the EBuild patch line? If you think we'll ever be debugging the same routine within the future, I usually just opt for commenting the patch/line out and making a note to enable for debugging, but this looks like some really customized and specific debugging routines that may rarely if ever used again?
4.2.1 was released, Python 2 support was dropped (remove 2.7 from PYTHON_COMPAT) and patches use-bsddb3 and python-doc-init doesn’t seem to be needed anymore. Resources path patch need to be updated, I will attach it.
Created attachment 416256 [details, diff] Patch for resource path (version 4.2.1)
I've added an ebuild for gramps-4.2.1 in my new genealogy overlay (not yet in o.g.o): https://github.com/tecknicaltom/gentoo-genealogy-overlay It's based on the ebuild for 4.1.1 and discussion in this bug, with the following changes: * change license to gpl-2+ (https://gramps-project.org/wiki/index.php?title=Project_License) * remove print-guiplug-error.patch - was debugging code * remove use_bsddb3.patch - bsddb3 is no longer optional, patch no longer needed * remove python-doc-init.patch - issue was fixed upstream (gramps-project/gramps@0725bfe) * add [${PYTHON_USEDEP}] to dependency on dev-python/bsddb3 * documentation calls for >=pygobject-3.12 (https://github.com/gramps-project/gramps/blob/master/README.md) * webkit no longer needed * change USE flag from gexiv2 to the more standard exif Should remove from Gentoo bug #371324 dependency on #289004 since the dependency on pyexiv2 was dropped in Gramps-4.0 (now using gexiv2) The overlay also contains an ebuild for the dependency sci-geosciences/osm-gps-map-1.0.2 (#499592) to use the geography addon. The issue with PyICU (#237888) still exist, but it doesn't work any worse than the old ebuilds for gramps-3.x in the main gentoo portage portage
Hi, Tom. I wish Gentoo Bugzilla interface would have a download link to the Attachments, which included saving to the given File name. Also, seems Github suffers from also the same problem, including using the clipboard which includes the interfaces HTML code at times. Wish user intuitiveness was more so, than not being present at all. Sigh, the joys of when Microsoft were a successful company providing good competition! Any ways, I grabbed/downloaded your GitHub "gramps-4.2.1.ebuild" and the "Patch for resource path (version 4.2.1)", further renamed and moved to files/gramps-4.2.1-resourcepath.patch. Upon performing within /usr/local/portage/app-misc/gramps/, "emerge ./gramps-4.2.1.ebuild digest && emerge -uq ./gramps-4.2.1.ebuild" --- Begin of Snip --- !!! Problem resolving dependencies for ./gramps-4.2.1.ebuild !!! The ebuild selected to satisfy "=app-misc/gramps-4.2.1::x-portage" has unmet requirements. - app-misc/gramps-4.2.1::x-portage USE="exif reports spell -geography" ABI_X86="64" PYTHON_SINGLE_TARGET="-python3_3 -python3_4" PYTHON_TARGETS="python3_4 -python3_3" The following REQUIRED_USE flag constraints are unsatisfied: exactly-one-of ( python_single_target_python3_3 python_single_target_python3_4 ) --- End of Snip --- I then further performed with success: USE="python_single_target_python3_4" emerge -uq ./gramps-4.2.1.ebuild All these different Python Targets USE variables seems to be throwing a few loops here and there!
Cheers. Everything appears to work with the exception of maybe a graphical user interface bug with Toolbar font colors appearing the same color as the toolbar color, or disappearing. Here's the apparent successful command line information and/or warnings, omitting upgrade info of the previous old version family tree information. --- Snip --- $ gramps .gramps.gen.utils.grampslocale.WARNING: ICU not loaded because No module named 'PyICU'. Localization will be impaired. Use your package manager to install PyICU /usr/lib64/python3.4/site-packages/gramps/gui/viewmanager.py:835: Warning: The property GtkSettings:gtk-menu-images is deprecated and shouldn't be used anymore. It will be removed in a future version. self.uimanager.ensure_update() /usr/lib64/python3.4/site-packages/gramps/gui/glade.py:124: Warning: The property GtkWidget:margin-left is deprecated and shouldn't be used anymore. It will be removed in a future version. self.add_from_file(path) /usr/lib64/python3.4/site-packages/gramps/gui/glade.py:124: Warning: The property GtkWidget:margin-right is deprecated and shouldn't be used anymore. It will be removed in a future version. self.add_from_file(path) Gtk-Message: GtkDialog mapped without a transient parent. This is discouraged. 2015-12-14 14:08:34.667: WARNING: write.py: line 653: Python upgrade requested from 2 to 3 --- Snip --- Gramps-4.2.1.ebuild looks stable here for me on 64bit for pushing to the Portage Tree.
Created attachment 428688 [details] ebuilds for gramps-4.2.2, osm-gps-map-1.1.0, and PyICU-1.9.2 Here is my ebuild for gramps-4.2.2, along with the dependencies which are not available in gentoo right now (osm-gps-map is too old and PyICU doesn't exist). I've sent my changes to Tom for his genealogy overlay, too. But can we have an up to date gramps in gentoo, please?
I might be willing to proxy maintain this package.
commit 2621df486a36a61ea5f21039709f5094688a8864 Author: Marek Szuba Date: Thu Sep 22 14:53:32 2016 +0000 app-misc/gramps: version bump to 4.2.4 Dependency on sci-geosciences/osm-gps-map temporarily removed because we haven't got the right version in Portage yet.
Created attachment 448842 [details, diff] Patch for dependencies Some suggestions for improvements to the dependencies based on: https://gramps-project.org/wiki/index.php?title=Linux:Build_from_source#Gramps_4.2 pycairo and dev-python/pygobject[cairo] introspection needed for x11-libs/gtk+ Plus dev-python/gtkspell-python is for Python 2, uses app-text/gtkspell:3[introspection] N.B. the gramps-project.org link lists Python 3.5 and it works for me!
(In reply to Chris Mayo from comment #46) > Created attachment 448842 [details, diff] [details, diff] > Patch for dependencies > > Some suggestions for improvements to the dependencies based on: > https://gramps-project.org/wiki/index.php?title=Linux: > Build_from_source#Gramps_4.2 > pycairo and dev-python/pygobject[cairo] > introspection needed for x11-libs/gtk+ > > Plus dev-python/gtkspell-python is for Python 2, uses > app-text/gtkspell:3[introspection] > > N.B. the gramps-project.org link lists Python 3.5 and it works for me! I've put this and a fix for the document versioning here: https://github.com/gentoo/gentoo/pull/2517
Gramps 4.2.5 was released in December, do you think it can be bumped?
lol
(In reply to Julien Papasian from comment #48) > Gramps 4.2.5 was released in December, do you think it can be bumped? I am not the maintainer of this package (yet this is assigned to me). This package should be able to be bumped to 4.2.5. I have an ebuild for 4.2.5 merged on a system and is working well. I do not have the time or facilities to verify stability absolutely on a non ~amd64 system though.
The reason I posted "lol" is due to the ever increasing dependency versions, and sometimes not written into the ebuilds. And, just because there are so many constant dependency related changes with Gramps. For example: =app-misc/gramps-4.2.4-r1 $ gramps Your version of gi (gnome-introspection) seems to be too old. You need a version which has the function 'require_version' to start Gramps Likely due to dev-libs/gobject-introspection at 1.48 versus 1.50? Another Gramps usage deterrence, Ancestry.com's tree layout is far more readable than Gramps'. (eg. Gramps uses a pie chart for viewing many individuals, with only a report function for providing a similar view to Ancestry.com's layout.) I would live to use Gramps more, in effect being able to help maintain an ebuild, but things seem to be stuck in this state for some reason.
Please work with one bug ticket per topic. I moved the bump request to https://bugs.gentoo.org/show_bug.cgi?id=616796 Please attach your ebuild there, if you have already a working ebuild or a good start, or was a simple bump sufficient? app-misc/gramps-3.3 and 4.0 are no longer in the tree. https://github.com/gentoo/gentoo/pull/2517 is closed too. @Kevin you are assigned to the ticket and it is marked as "in progress" What is actually in progress? Or is this outdated and we can close the ticket here?
(In reply to Jonas Stein from comment #52) > Please work with one bug ticket per topic. > I moved the bump request to > https://bugs.gentoo.org/show_bug.cgi?id=616796 > > Please attach your ebuild there, if you have already a working ebuild or a > good start, or was a simple bump sufficient? > > app-misc/gramps-3.3 and 4.0 are no longer in the tree. > https://github.com/gentoo/gentoo/pull/2517 is closed too. > > @Kevin you are assigned to the ticket and it is marked as "in progress" > What is actually in progress? Or is this outdated and we can close the > ticket here? Jonas, I was assigned because I was the maintainer for a short time. I am no longer the maintainer. Nothing is in progress and I feel this bug should be closed.
