This bug is a tracker bug for issues involving gnome-2.10 and/or its keywording. Post any problems you are having with packages in a seperate bug and have it block this one. For archs: Here is a list of new packages that need keywords and packages you will need to rekeyword after that. Mono and evo only need keywords from hppa alpha and mips. #keyword gnome-base/gnome-menus x11-themes/gnome-backgrounds app-admin/system-tools-backends app-text/gnome-doc-utils dev-dotnet/mono #rekeyword app-admin/gnome-system-tools-1.2.0 app-arch/file-roller-2.10.0 gnome-base/eel-2.10.0 gnome-base/gnome-applets-2.10.0 gnome-base/gnome-panel-2.10.0 gnome-base/nautilus-2.10.0 gnome-base/nautilus-cd-burner-2.10.0 gnome-extra/bugbuddy gnome-extra/gnome-utils-2.10.0 mail-client/evolution-2.10.0
~sparc is done.
not quite.. not at that point in the meta, but going to be there : totem-1.0 & sound-juicer-2.10 and their respective deps.
*** Bug 85337 has been marked as a duplicate of this bug. ***
I got problems with mono on hppa. Every other ebuild in to be keyworded (not rekeyworded) will be marked ~hppa soon.
Not sure if this should go here, but eog-2.9.0 and librsvg-2.9.5 should both be in portage and part of gnome-2.10 (at least according to the list at http://ftp.gnome.org/pub/GNOME/desktop/2.10/2.10.0/sources/). In fact, both these versions are in package.mask, but there are no ebuilds for them.
We want to use evolution-2.2.1.1, evolution-data-server-1.2.1, gtkhtml-3.6.1, gal-2.4.1 and libsoup-2.2.3 in the 2.10 meta, not the earlier versions.
I'd just copied the ebuilds, removed the currently applied patch from evolution and it seems to work quite fine.
It seems nobody ported mono (at least the mcs part) on hppa. So, which program will depend on it ? Is it that important ? What do I do ? :)
Just optional use support in evolution. You can stick mono in use.mask if needed.
I've been running these ebuilds of GNOME 2.10 on an x86 system for about 4 weeks now. No ebuild related problems at all. Incidentally, I've packaged the java-gnome language bindings for the gtk 2.6 / gnome 2.10 series and they went fine (see bug #87978). Not exactly a conclusive test or anything, but still a nice positive indicator. Regards, AfC Toronto
i think gnome 2.10 can be unmasked and added at least unstable. more than 1 month sinc its release
As for the most of us, you can simply copy everything concerning gnome 2.10 from /usr/portage/profiles/package.mask to a file called /etc/portage/package.unmask and install gnome-2.10 right away. Though I agree, that gnome 2.10 is stable enough, marking a bug "done" just before it's more than x times old is not a criterion.
i know how portage works! and i know that a bug is not time-only related. but considering that application change very fast, this make packages old, without being used by people. that's strange....kde is in portage 1 week before release and unmasked during the first release day, while gnome, after >1 month is still in hardmasked status (with gnome_pre0 meta...which gives no hope to installed :P )
Instead of complaining maybe helping out would speed up the process : this bug has quite a few depends which indicate known problems that should be resolved before we intend to move gnome 2.10 to ~arch. As for the comments #10 up to #13 : this is not a forum, if you got nothing useful to add, don't add anything.
I took a look of the blocking dependecies and here is an overview FYI. 84831 Its not a bug, its a warning. Reported upstream and don't need to block. Could this be closed? 85013 Conclution: "2.2.1.1 Does not have this flaw, and seems to work just great. (ie, this should perhaps not block gnome 2.10)" So this is actually fixed in the latest version and could be closed? 85153 Is a xorg not gnome bug. Fixed is already there for xorg-x11-6.8.2-r2. Should we wait for xorg-x11-6.8.2-r2 before we unmask gnome 2.10? Or could it just be closed since the bug is handeled (should be handeled) other place? 85384 Patch posted to bugzilla and it is reported upstream. could this be commited and closed? Or are someone waiting for an updated ebuild to be posted? 87114 Conclusion: gal deps in gtkhtml-3.2 are >= , should be = Should be easy to fix that... (just remove the '>' in the ebuild). Could this be closed or are someone waiting for a contributed ebuild? 89531 A patch and updated ebuild is posted. Could this be committed and closed? They are talking about deps in file-roller but is that discussion worth to block the entire gnome-2.10? All other deps seems to be closed. Now what more can non-devs do to help the devs get this unmasked? I think many *want* to help, but they just don't know how.
comment in the bugs... geez thats what they're for. and things that are resolved don't need another 'the solution is here' comment (like most of your comments indicate).
foser: these bugs actually ARE resolved, we just need to commit them. I'm really sick of this discussion, if you allow it, I'll fix these deps listed in comment 15 rather than bitching around
*sigh* thats up to the team to take care of. What you and many others miss to see here is that there's a lot more going on than 2.10 alone and those are higher priority than p.mask-ed commits. When we have the time to make 2.10 stable, those easy fix bugs -which most of them are- will get taken care of. Asking, begging or complaining here are not in any way helpful, fixing the bugs is. If they are fixable as noted in the bugs, that is just fine : move on. We don't need a list here of what should be done for individual bugs, thats what we have the freaking dep list for. Also, it is of no relevance to most people CC-ed on this bug and as such could be considered bugspam. Enough bugzilla-use education for today I hope.
gnome-2.10 is in ~arch now..closing
