dantrell

I'm fairly confident that if there is any remaining instability with GNOME 3.14 it has nothing to do with my patchset but instead with changes introduced by GNOME 3.14 itself. The only issue that comes to mind is FL-1687 which I belleive relates to a larger issue of how GNOME 3.14 is handling graphic related things and subsequently affects nvidia-drivers and to a lesser extent, fglrx. Otherwise, 3.14 is an improvement over 3.12 in almost every way. Still, if 3.14 is giving you unnecessary trouble, simply downgrade by masking it.

Could you try building media-libs/mesa-10.3 with the gdm USE flag?

I'm thinking this is related to what is going on with the Nvidia drivers as well since those issues get resolved by switching to nouveau. This also didn't happen in GNOME 3.12. I'm going to have to take a closer look into things.

Did you have this issue in GNOME 3.12?

This issue should be resolved now.

It shouldn't be necessary to use upower-pm-utils. It's also irrelevant wherther you use that or the regular upower if the basic pm-utils package does not work. That said, did you add yourself to the power group?

woodelf, I get what you mean. Overall, it did take a while (although I was on 3.8 and 3.10 througout it all; I regret nothing :P). P.S. Regarding Wayland... no promises. uudruid74, The state of GNOME is such that: systemd is not a hard compile time dependency. You can build everything except for ~2 packages and it will all work out of the box. systemd is a hard run time dependency for basic functionality. Basic functionality is what the GNOME team has decided includes: power management session tracking lid close handling log/event viewing Wayland My patchset has reintegrated support for everything but Wayland (I thank the relevant GNOME and Gentoo teams for making my job easier). Furthermore, my patchset was done for 2 reasons: It was trivial to do so (I'm of opinion that upstream should have left the relevant code in and marked it as deprecated but that's another matter). To buy more time to come up with a proper solution. One possible solution is to fork ConsoleKit and pm-utils then have the GNOME team reintegrate support as they said they would.

There's no need to be combative here. I see no no problem with documenting how to get it working for those who want to try it (although I'm not sure those instructions are 100% correct) so long as they understand that it is not officially supported (and while systemd does work in Funtoo it is necessary to restore certain ebuilds to the their Gentoo variants). There are actually quite a few Funtoo users using systemd because while they want systemd, they also want Funtoo be their underlying ecosystem so I see no reason to remove it. In any case, it is not entirely systemd I dislike but rather the exponentially growing insistence that it must be used and the removal of support for any other alternatives and without a proper transition period. This is why I decided to deliver a complete (or nearly complete) GNOME 3.12+ experience without systemd. P.S. Woodelf, I remember you from your one blog post regarding GNOME 3.12. For the record, it took me about a week if you count testing, not half a year :).

The short answer is that our trees are not exactly same and even though we may have similar packages, the contents of the ebuilds itself can wildly diverge. Since our team is small, it takes time for things to get updated.

For the record, all things related to improving the state of GCC in Funtoo are being tracked on FL-1424.

It would require forking quite a few packages to properly unbundle cups and I'm not sure that's a good idea. I no longer have the time to do it now anyway so what I did do was resolve the blocker. That said, lprng still pulls in cups if you enable the foomatfcidb USE flag. But even you changed that ebuild, foomatic-db-engine also pulls in cups. You may want to try your luck contacting the responsible team on Gentoo upstream.

Aha, sorry about that. I have updated the instructions to reflect the default PORTDIR location. I have also updated the gnome mix-in so in another tree regen (or thereabouts), the package.use change shouldn't be necessary.

I looked into this for you and updated lprng accordingly.

A resync should clear up your issues but you might have to wait for 1 more regen.

I think I have a better idea of what might be happening now. Either try rebuilding gnome-extra/evolution-data-server without the vala USE flag or upgrade to dev-lang/vala-0.24.0*.