Tomboy, which ships as part of Gnome nowadays, requires gnome-panel-sharp. After upgrading to Gnome 2.26.0, with the gnome-panel-sharp-2.24.0-r10 version in Portage gnome-panel gets into an upgrade/downgrade cycle between 2.24 and 2.26. Copying the 2.24.0-r10 ebuild in Portage to 2.26.0 works fine. Gnome-desktop-sharp (which gnome-panel-sharp is a part of) is already bumped to 2.26.0 in Portage. Consideration should be given to bumping all the gnome-destkop-sharp derived ebuilds to 2.26.0 or this kind of problem is likely to hit other packages with dependencies on these ebuilds.
Unless you have a local copy of gtk-sharp-module.eclass, based off a version earlier than the commit in URL, what you're saying does not make sense.
(In reply to comment #1) > Unless you have a local copy of gtk-sharp-module.eclass, based off a version > earlier than the commit in URL, what you're saying does not make sense. > I just searched all my overlay directories without finding that -- the only one I have is in /usr/portage/eclass. My understanding is that when gnome-desktop-sharp entered Portage (2.24) the dotnet herd broke it into a series of ebuilds, one of which is gnome-panel-sharp. So far, the main gnome-destkop-sharp ebuild was bumped to 2.26.0 but all the others are still 2.24.0-r10. All it takes is copying those 2.24 ebuilds to 2.26 versions and the eclass takes care of the rest, but that has not yet been done for the majority of the ebuilds derived from gnome-desktop-sharp. For my setup, the only package for which this is a problem is gnome-panel-sharp (as a dependency of Tomboy) but others may require rsvg-sharp, wnck-sharp, etc.
(In reply to comment #2) > My understanding is that when gnome-desktop-sharp entered Portage (2.24) the > dotnet herd broke it into a series of ebuilds, one of which is > gnome-panel-sharp. So far, the main gnome-destkop-sharp ebuild was bumped to > 2.26.0 but all the others are still 2.24.0-r10. That's because that and gtkhtml-sharp are the only ebuilds where code changed. I will do the gtkhtml-sharp bump when gnome enters the tree, but it only has a single bugfix. > All it takes is copying those > 2.24 ebuilds to 2.26 versions and the eclass takes care of the rest, but that > has not yet been done for the majority of the ebuilds derived from > gnome-desktop-sharp. For my setup, the only package for which this is a problem > is gnome-panel-sharp (as a dependency of Tomboy) but others may require > rsvg-sharp, wnck-sharp, etc. Why is this a problem? AFAICT, these are the {R,}DEPENDs of gnome-panel-sharp: qdepends gnome-panel-sharp dev-dotnet/gnome-panel-sharp-2.24.0-r10: sys-devel/libtool =dev-dotnet/gtk-sharp-2.12* =dev-dotnet/gnome-sharp-2.24* =dev-dotnet/gtk-sharp-gapi-2.12* >=gnome-base/gnome-panel-2.24 >=dev-lang/mono-2.0.1 >=sys-apps/sed-4 >=dev-util/pkgconfig-0.23 >=app-shells/bash-3.1 So I fail to see how gnome-panel would come into an up/down-grade loop because of gnome-panel-sharp. You can see which package is pulling in gnome-panel-2.24.x by using the -t (--tree) option with emerge.
Okay, I've downgraded gnome-panel-sharp again and this time I don't have the problem. I think what may have happened is that when I last built gnome-panel-sharp 2.24 I did in fact still have an older version of the eclass in my overlay -- I remember deleting it a couple of months ago because it was causing problems. Sorry to waste your time.
(In reply to comment #4) > Okay, I've downgraded gnome-panel-sharp again and this time I don't have the > problem. I think what may have happened is that when I last built > gnome-panel-sharp 2.24 I did in fact still have an older version of the eclass > in my overlay -- I remember deleting it a couple of months ago because it was > causing problems. Sorry to waste your time. Thanks for caring :-)
