please stable =dev-libs/libgit2-glib-0.0.16 for PYTHON_TARGETS=python3_4 support
It's better to try to keep both in sync (for python and for libgit2-glib API that tends to change and has caused problems with gitg in the past). I think this too versions should be ok to go together, but will wait for ikelos to give the OK :)
I use both for more than 30 days without any problems (amd64).
I'm thinking it's probably best if the gnome herd takes this over, given how closely intertwined with libgit2-glib it is. I'm having a hard time carrying out testing of libgit2-glib-0.0.24 because of bug 536830 (which has been fixed by a depedency change, not a fix), and gitg doesn't seem to build with libgit2-glib-0.0.22, which is why this is still in limbo. @Gnome herd, please let me know if it's ok to change the maintainer on the package to just the Gnome herd?
Well, all the chain of problems come from libgit2 package that breaks all reverse dependencies on every new release. I am not sure if maybe the way to go would be to wait a bit more to bump that one (or keep it hardmasked until reverse deps are fixed) I think all consumers but app-misc/subsurface (also broken in the same way) are under gnome radar... but I would like to know how libgit2 maintainer sees this situation. I would opt for keeping the latest versions in hardmask a bit longer to not need to be constantly restricting the dependencies on every bump
(In reply to Pacho Ramos from comment #4) > Well, all the chain of problems come from libgit2 package that breaks all > reverse dependencies on every new release. I am not sure if maybe the way to > go would be to wait a bit more to bump that one (or keep it hardmasked until > reverse deps are fixed) > > I think all consumers but app-misc/subsurface (also broken in the same way) > are under gnome radar... but I would like to know how libgit2 maintainer > sees this situation. > > I would opt for keeping the latest versions in hardmask a bit longer to not > need to be constantly restricting the dependencies on every bump I would lean towards saying no, but I'm biased and don't use or care about any of those 3rd party apps besides pygit2 which I also maintain that generally releases in lockstep with libgit2 (and has locked deps to match).
the concrete two versions at summary worked ok together and, then, I guess we can finally CC arches for them
*** Bug 546736 has been marked as a duplicate of this bug. ***
amd64/x86 stable