Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 530272 - dev-libs/libgit2-glib-0.0.24, dev-vcs/gitg-3.14.0, dev-libs/libgit2-0.21.5 stable request
Summary: dev-libs/libgit2-glib-0.0.24, dev-vcs/gitg-3.14.0, dev-libs/libgit2-0.21.5 st...
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Keywording and Stabilization (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Mike Auty (RETIRED)
URL:
Whiteboard:
Keywords: STABLEREQ
: 546736 (view as bug list)
Depends on: 536830 537232
Blocks: python-3.4-stable
  Show dependency tree
 
Reported: 2014-11-24 03:15 UTC by Rick Farina (Zero_Chaos)
Modified: 2015-05-15 06:41 UTC (History)
3 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Rick Farina (Zero_Chaos) gentoo-dev 2014-11-24 03:15:22 UTC
please stable =dev-libs/libgit2-glib-0.0.16 for PYTHON_TARGETS=python3_4 support
Comment 1 Pacho Ramos gentoo-dev 2014-11-24 10:53:52 UTC
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 :)
Comment 2 Christian Strahl 2015-01-19 12:50:04 UTC
I use both for more than 30 days without any problems (amd64).
Comment 3 Mike Auty (RETIRED) gentoo-dev 2015-01-21 20:26:28 UTC
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?
Comment 4 Pacho Ramos gentoo-dev 2015-01-22 10:50:54 UTC
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
Comment 5 Tim Harder gentoo-dev 2015-02-12 20:28:15 UTC
(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).
Comment 6 Pacho Ramos gentoo-dev 2015-04-30 11:20:30 UTC
the concrete two versions at summary worked ok together and, then, I guess we can finally CC arches for them
Comment 7 Pacho Ramos gentoo-dev 2015-05-15 06:34:14 UTC
*** Bug 546736 has been marked as a duplicate of this bug. ***
Comment 8 Pacho Ramos gentoo-dev 2015-05-15 06:41:29 UTC
amd64/x86 stable