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 reintegra

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 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*.

I'll be taking of this over at FL-1485.

With the information you have provided, my best guest is that this is related to dev-libs/gobject-introspection. You need to either globally enable (in your make.conf or through the gnome mix-in) the introspection USE flag or globally disable (in your make.conf) it. Then do "emerge -vauDN world" before emerging whatever it is you are emerging. The output of "eselect profile list", the emerge command you were using, the FULL build log (snipped at the point before it started to repeat) and the USE flags of the packages you were emerging is more useful than the output of "emerge --info". Of c

I will be taking care of this over at FL-1474.

Hello and welcome. :) If you are going to put Funtoo in a VM and not configure an appropriate kernel by hand (e.g. gentoo-sources or vanilla-sources) then you are going to need to pump a bit more resources into your VM since, as you discovered, debian-sources is a bit of a hog. If you want less updates, on average, then the stable profile is what you want. It shouldn't be too far behind current.

It took place after this. P.S. How could you forget me already? I thought we had something. ;)

Sorry, I got nothing.

For the record, you should be talking to the people maintaining the mva overlay about this since both Funtoo and Gentoo use RPM from http://www.rpm.org/ whereas you are dealing with RPM vs http://rpm5.org/ so don't file a bug about this. To elaborate, Funtoo and Gentoo puts the RPM from rpm.org at app-arch/rpm and the one from rpm5.org at app-arch/rpm5, the mva overlay squashes it all together. That said, if this worked before and currently doesn't then it is most likely due to the recent sys-libs/db update. Try downgrading that package to 4.8 and see if rpm will build against it. Otherwise

I will be taking care of this over at FL-1445.

Unless I'm missing something, isn't this a simple matter of updating your kernel?

I looked into this over at FL-1439: (1) the blocker was taken care of and upower can now be safely used (2) an additional issue regarding power button settings was handled; and (3) a cinnamon mix-in was added.