Yes, indeed, GNOME 2.22 is now unmasked in Gentoo and entered ~arch and the updated profiles should be on the way to a mirror near you. But only ~x86 and ~amd64 for now, as there is still some keywording work to prepare for the rest. As I'm pretty much exhausted from the intention of getting this done before sleep and it getting done past 5am, I'm gonna be short and sweet.

Upgrade guide here (updated April 3rd); bugs go here of course. Praises (to the whole team, I am just one) go in comments right here or whereever we see, general complaints to /dev/null or comments as appropriate. My appreciation for the GNOME upstream goes to Planet GNOME with right this post (Thanks for the nice release!)
And now I mv /proc/self /dev/bed and hope stuff doesn't break too much.

Rumor has it that Skype might be willing to add PulseAudio support to their Linux version, as long as they get all the help necessary to make that a smooth process. A meeting is rumored to happen on that topic tomorrow, where some finger pointing to relevant and interested PulseAudio community members could be useful. As rumors have the tendency to get the facts twisted, see the linked origin if interested.

In addition, there are rumors that I am myself now working since mid-January at Artec Design LLC as an Embedded Software Engineer.

Yes, that's right. gnome-power-manager-2.20.0-r1 in Gentoo now shows its tray icon after GNOME startup.
So everyone using some workaround hacks (usually involving scripts with sleeps, killalls and restarts), please remove them after upgrading to this revision
As Gnome-2.20 is planned to go to stable tree quite soon, I didn't fix the 2.18 series.

So what was wrong you might ask?
Well, let me explain then, at least then this post might be somewhat useful to Planet GNOME readers, considering that there are some notions that other programs might be affected:

Somewhere in the 2.17 development cycle, gnome-power-manager added code to handle some special X keysyms, such as XF86XK_PowerOff. This code is realized through a callback from the gdk_window_add_filter mechanism. The documentation of it says the following:

Adds an event filter to window, allowing you to intercept events before they reach GDK. This is a low-level operation and makes it easy to break GDK and/or GTK+, so you have to know what you're doing.

If the GdkFilterFunc() callback returns GDK_FILTER_REMOVE then the processing of this event is stopped and gtk+ won't see it, if it returns GDK_FILTER_CONTINUE then it's continued and gtk+ will see it if some other filter that might be set up doesn't stop it.
When a notification area applet is ready to accept icons, it acquires ownership of the _NET_SYSTEM_TRAY_Sn (n is the screen number) X selection on MANAGER atom and GtkStatusIcon takes notice of this through a XClientMessageEvent that is listened in a GdkFilterFunc of its own to know when it can create the icon and set up some other filters for a (orientation) property and destroy notification.
Now, the gnome-power-managers filter that is set up tries to filter for keypresses to catch the power management related ones and return GDK_FILTER_REMOVE for those and any other event gets a GDK_FILTER_CONTINUE. Well, that seemed to be the plan, it's just that instead of
if (xev->type == KeyPress) { ...; return GDK_FILTER_REMOVE; } return GDK_FILTER_CONTINUE;
there was
if (xev->type != KeyPress) { ...; return GDK_FILTER_REMOVE; } return GDK_FILTER_CONTINUE;
stopping propagation of any non-keypress up to gtk+ and especially gtktrayicon-x11.c that was trying to listen to xev->type == ClientMessage type of events on the X root window for knowing about the tray manager appearing to create the tray icon into it. Whoops. No icon, no reaction to the keys.

So, lesson of the day - if you are an application or daemon with a tray icon be triple-careful if you need to use gdk_window_add_filter for some reason, or you might end up with the icon not appearing if the app is launched on startup or when the notification-area-applet (or any other notification manager) is reloaded manually or on a gnome-panel crash. You already need to be double-careful in using this mechanism and use it only when really really necessary - it's a great way to make GDK or GTK+ break, just as the documentation says.

This is already fixed on trunk in the gnome-power-manager case, as per the relevant bug. Thanks, Richard. Also many thanks to Shogun, who figured out this happens in the --enable-xevents specific code, which is also probably the reason many of the other distros weren't affected as they likely just don't use this configure switch.

And, again, if you use a workaround hack for this, please remove it after getting the revision with the fix (now or in the near future in case of a stable tree usage) as starting gnome-power-manager twice is no fun

Hello,

Now that GNOME-2.20 is unleashed to ~arch in Gentoo, I can come out of hiding again and try to blog again, as all the cool guys are doing.
As this should be the first post that gets to Planet GNOME - Hello Gnome-ers! Therefore also a quick introduction might be in order:
My name is Mart Raudsepp, I'm from Estonia and I'm a member of the Gentoo Linux GNOME team. That's enough, m'kay? Oh and you might have noticed my mug in Vilanova or Birmingham.

So, coming back to the real topic, I'm intending to gather some feedback about Gnome and Gnome related packages in Gentoo.
Please put anything Gnome related that you have always wanted to see in Gentoo, but still don't, in the comments or e-mail me (leio AT gentoo DOT org).
Any cool ideas or technologies we should integrate? Any cool packages we are missing? What about GNOME development tools and Gentoo as a development platform for GNOME libraries and applications - anything we can do to help there?

Lets see what we really miss based on the comments/mails and we'll see what we can do about it
Now, go comment! I'll look forward to it and do a follow-up post later.

So the long-awaited (sorry about that) GNOME-2.18 has gone stable on most of architectures now. I would like to remind the GNOME-2.18 Upgrade Guide, which I also updated half an hour ago for some minor corrections. As Daniel already noted you better upgrade with revdep-rebuild -X as this ought to fix expat breakage and upgrade GNOME/KDE at the same time, reducing pain.
I would use revdep-rebuild -X -- -va myself to see what it will do
If still some pain happens, especially related to intltool, you might want to rebuild sys-devel/gettext and dev-perl/XML-Parser manually as the first thing and do a revdep-rebuild -X again, if it didn't order them first otherwise.

Now that GNOME-2.18 is stable, cleaning up of GNOME-2.14 from the tree is ongoing. This also means that linux kernel 2.4 subprofiles will loose all GNOME versions, which hopefully isn't a problem because I can't imagine why any desktop would use linux-2.4 still.
Someone please kill off these subprofiles completely, pretty please

For the short-term future my plan is to get some more 2.18.3 version bumps in and stable all the remaining 2.18 updates soon too, which shouldn't be a too big amount of packages. Also 2.20 is upon us soon, for which we will create action plans and take other measures to not slip with unmasking and stabling this time around. 2.19 is having a good life in the gnome-experimental overlay meanwhile, of course. We also have two new team members (hi!) rocking along and helping out a lot and covering times when me and/or Daniel are too busy with work, so the future looks good.
Stay tuned for some GNOME related public comment requests in some days

Just like Andreas, I will be heading to GUADEC as well and be there the whole week. So if you are there, then we should meet up! I might be even convinced to get stabilization of GNOME going in Gentoo with some beer
To my knowledge remi and eva from the gnome team will also be there from Sunday. Who else from Gentoo? Let us know! I think zaheerm?

As I'm already in London, I will be at the Gentoo UK Meeting as well, and also at the "socializing event" the evening before (i.e, now), if welp would hurry up so we could head out
I will arrive to Birmingham for GUADEC depending on what happens after the official Gentoo Meeting schedule, I guess.

News from the GNOME stabilization front:

We decided to go back to stabilizing GNOME in at least two steps again.
GTK+ and co in the first step, followed by the whole of GNOME as the second step.
So there is now bug #156572 for stabling gtk+-2.10 and co. It seems that amd64 is done already

Note that when going from gtk2.8 to gtk2.10, you need to rebuild packages that provide gtk modules (librsvg, gtk-engines and so on), as the modules ABI was upgraded from 2.4 to 2.10 - the gtk ebuild gives information about this too.
Additionally there might be problems with notification daemon related stuff, as noted in the GNOME 2.16 Upgrade Guide, probably won't hurt to also do a revdep-rebuild run just to be sure.

Next step is GNOME-2.16 stabling and I hope that will happen soon...

The step after that?
Why are you asking. World domination of course.

I figure that as I haven't really blogged much as of late, I could just as well note what my latest commit spree was about (related to that - go beat my todays commit count on cia.navi.cx in a productive way ).

I cleaned up redundant versions in the GNOME packages, which mostly amounted to removing the versions for earlier than GNOME-2.14, plus some old 2.16 versions that have a newer version in the tree for 30 days already or the ones with bugs while only a newer version has fixes.
In total about 100 different versions/revisions were removed, so I hope that helps a bit to rsync times and mirror server space.

And, no, no gnome1 packages were removed in the process, just a few revisions that had newer ones in the same major.minor version-set available. That cleanup is for when they have sat in p.mask for long enough and for certain someone else.

Many things not officially part of upstream GNOME haven't been cleaned up yet, as well as some of the most core libraries, just in case (and fear of being reprimanded when removing them ) - such as glib, pango and gtk+.
There is also lots of redundant gstreamer/gnome co-maintained versions around. Could someone at home with gst maintenance take a look please?

I hoped to get the redundant gnome herd (co)maintained ebuild revision count down to ~200, but ended up at 325 for now, from around 420ish at the start of my long "day".

At any rate, the current reason to do the cleanup is more or less fulfilled - easier generation for an GnomeUpstreamDelta wiki page for official GNOME modules, listing patches that we apply on top of upstream tarballs, with an explanation of what it does and if and where it is filed upstream to reduce the delta. This is in line with other distributions doing the same. I believe Luis wanted to start with a proper page of ours very soon

PS: pcheck repo -c RedundantVersionReport rocks.

That is all.

Yes. That's right.
GNOME-2.16 is out of package.mask and now nearing your unstable ~arch systems closest mirror with the speed of, , electrons.
This is currently a 2.16.1 version of it.
For the rare (sub)profiles using Linux kernel version 2.4, GNOME-2.16 will stay masked, due to it requiring HAL (Hardware Abstraction Layer) quite heavily. The Linux version of it uses udev, which is new in 2.6 kernel. These profiles will however now get gtk+-2.10 with the necessary dependencies in their ~arch.

There is an upgrading guide over here:
http://www.gentoo.org/proj/en/desktop/gnome/howtos/gnome-2.16-upgrade.xml

It is likely that it will gain more items to it over time as things come up.

Enjoy! I know I am.
For the stable machines, well, the clock is ticking now.

Thanks to the GNOME desktop team for pulling this through!
I just got to do the finishing touches

Oh and I received a Gentoo GNOME team member badge some time ago for some reason