In upgrading to gnome-2.24+, there are at least two (2.22.x) packages which will not build - gnome-settings-daemon and gnome-control-center. In both cases there is an undefined symbol "gnome_bg_set_uri". Some discussion on the web seems to suggest that this function name changed going from 2.22 to 2.24. The problem is there are a host of binaries in /usr/bin (e.g. gnome-about-me, gnome-control-center, etc.) as well as libraries in /usr/lib/gnome-settings-daemon-2.0 which really *need* to be upgraded to the 2.24 to allow testing of a 2.24 environment. Yet for the life of me I cannot seem to locate the 2.24 ebuilds and/or packages for gnome-settings-daemon and gnome-control-center. Can somebody please tell me how to get these? (I've tried forcing them in package.mask by masking versions <...-2.24 with no success.) I'd like to avoid having to try and build them from the Gnome sources. I think this is related to Bug #242842 as libeel-2.22 had the same problems. Reproducible: Always Steps to Reproduce: 1. emerge gnome-settings-daemon Or 2. emerge gnome-control-center Actual Results: Packages don't build due to undefined symbol. Expected Results: Packages should emerge (or there should be some documentation regarding what is broken until the new version is complete). Yes I know I'm working with an "untested" prerelease, but for a system as intertwined as the gnome packages appear to be it should perhaps be an "all" or "nothing" release.]
*** This bug has been marked as a duplicate of bug 242842 ***
Erf, my text got lost. Look at /usr/portage/profiles/package.mask, you need to unmask nothing or everything in the gnome mask. Thanks
I do not believe comments in /usr/portage/profiles/package.mask fix the problem. Mine currently reads: # Gilles Dartiguelongue <eva@gentoo.org> (20 Oct 2008) # GNOME 2.24 mask being (and related) #>=net-irc/xchat-gnome-0.24.0 #>=gnome-base/gnome-desktop-2.24.0 #>=gnome-base/eel-2.24.0 #>=gnome-base/nautilus-2.24.0 # GNOME 2.24 mask end All this did was enable upgrading gnome-desktop from 2.24.0 to 2.24.1. Some of these gnome masks had to be disabled previously to allow eel-2.24.1 to be emerged I believe. The problem is: .../gnome-control-center-2.22.2.1/work/gnome-control-center-2.22.2.1/capplets/appearance/gnome-wp-item.c contains a call to gnome_bg_set_uri() @ line 62. and .../gnome-settings-daemon-2.22.2.1/work/gnome-settings-daemon-2.22.2.1/plugins/background/gsd-background-manager.c contains a call to gnome_bg_set_uri() @ line 214. Now, I believe that the calls to gnome_bg_set_uri() have been changed to calls to gnome_bg_set_filename() [???!] in 2.24.X. So unless there are packages which include header files that redefine this function or entirely new packages (e.g. gnome-settings-daemon-2.24.X.tar.bz2 and gnome-control-center-2.24.X.tar.bz2) these packages are not going to build on my system. Side note: I have not gone through the gnome sources to see if this is a strict function call name change or whether there are argument and/or context differences. The note I noticed on the web seemed to suggest it was a simple name change. My previous messages were attempting to ascertain whether there were compressed packages or ebuilds (perhaps with patches?) that would provide me with a full 2.24 package set or edits to the 2.22 package set which would in fact build without the undefined symbol.
We know exactly what the problem is, which is described in the bug this was duplicated against (and I am doing that again). But I can understand your confusion, so let me explain a bit in detail what is going on here: "all or nothing" unmasked means all 2.24 or none (that isn't already ~arch and not masked), that is, you will need stuff like gnome-control-center-2.24 and other things whose 2.22 versions were using the gnome_bg_set_uri API from the official gnome development overlay (under the name "gnome" in layman, located at git.overlays.gentoo.org as proj/gnome.git). Why some of this is in portage tree is because initially we didn't realize there is an API break involved, and gentoo-desktop-2.24 simply got bumped as a gradual improvement release. Once it was realized it would involve bringing in core things like gnome-control-center immediately as well, while those needed more work and testing, we package.mask'ed gentoo-desktop-2.24 in portage tree together with everything else in tree requiring that new version of gnome-desktop (eel, nautilus) in portage tree. So you either just don't upgrade gnome-desktop, eel and nautilus until we get the remaining packages using the replacement API for bg_set_uri into the portage tree, or you start using the gnome overlay until they get to tree. This is a different approach in handling a GNOME release than previous ones, as I figured we can add incremental improvement versions of individual modules to ~arch directly if they don't interact with eachother in negative manners if they are at different versions. That way users can get the improvements of those sooner than it takes for the full set to be good enough for ~arch - before everything would sit in package.mask until most everything is ready. Unfortunately there was a temporary mistake in regards to gnome-desktop, as we didn't immediately realize it does interact with other modules and corrected that within some hours, but the things that already got committed to the tree were kept there and simply package.masked instead until all interconnecting packages are ready there to remove the mask from that block at the same time. *** This bug has been marked as a duplicate of bug 242842 ***
Well, I've punted and downloaded copies of some of the gnome 2.24 sources. There appear to be "new" 2.24.x gnome sources for both the control-center and settings-daemon. gnome-wp-item.c appears to be reworked such that gnome_bg_set_uri() @ line 62 may have changed to gnome_bg_set_filename() @ line 72. gsd_background_manager.c may be significantly different, so I am not sure that I can draw comparisons. The bottom line would appear to be that there needs to be releases of the 2.24 gnome packages for these gnome sub-components which can be downloaded and compiled in current systems.
Mart, thank you for the detailed explanation. It will take me a while to process it but I think I have a basic understanding. It may be a classic case of "making sure the whole thing works" (e.g. Murphy's Law). I would urge you to get the currently unavailable 2.24 packages into the release tree. That way people can build a system where the faults are in the programs themselves, rather than in the components which were never designed for compatibility (or may be missing entirely). A faulty/defective program, is (arguably) much easier to deal with than missing "parts". Otherwise you run the risk of people building components 90% from Gentoo and 10% from "who knows what source" and that is likely to be an unproductive path. Side Note: Bug #242842 is *not* strictly a duplicate of this bug. If eel does not build, that is different from other various gnome packages failing to build. If the bug appears to be documenting something which I have already solved (I could build eel-2.24 by disabling some of the Gentoo restrictions) then I am unlikely to read the bug report in detail. There is a big difference between bugs that can be fixed by adjusting the Gentoo package settings (which I can do) and packages that can only be fixed by a downloadable release of updated sources and/or patches (which I cannot do).
(In reply to comment #6) > Mart, thank you for the detailed explanation. It will take me a while to > process it but I think I have a basic understanding. It may be a classic case > of "making sure the whole thing works" (e.g. Murphy's Law). And we have made sure of that, by package.mask'ing the packages that disturb that for the time being. If you are unmasking those packages, you are getting what you are asking - they are package.masked for a reason. > I would urge you to get the currently unavailable 2.24 packages into the > release tree. That way people can build a system where the faults are in the > programs themselves, rather than in the components which were never designed > for compatibility (or may be missing entirely). We are working on it. But again, the packages that break compatibility are package.mask'ed. > A faulty/defective program, is (arguably) much easier to deal with than missing > "parts". Otherwise you run the risk of people building components 90% from > Gentoo and 10% from "who knows what source" and that is likely to be an > unproductive path. The "missing parts" are in the gnome overlay, on the way to portage tree as problems are worked out and quality assurance made. You have no need to go looking for sources if you wouldn't on purpose break your system by unmasking package.masked packages. However if you want the full GNOME 2.24 set, it is in the gnome overlay being worked on. > Side Note: Bug #242842 is *not* strictly a duplicate of this bug. If eel does > not build, that is different from other various gnome packages failing to > build. It is the same. We have simply not generalized the subject to something like "gnome-base/gnome-desktop-2.24 breaks API/ABI and therefore needs to enter ~arch at the same time as the new versions of the packages that use gnome_bg_set_uri function"
