Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


dantrell last won the day on August 24 2014

dantrell had the most liked content!

About dantrell

  • Rank
    Advanced Member
  1. 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.
  2. Could you try building media-libs/mesa-10.3 with the gdm USE flag?
  3. 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.
  4. 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?
  5. 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
  6. 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
  7. 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.
  8. For the record, all things related to improving the state of GCC in Funtoo are being tracked on FL-1424.
  9. 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.
  10. 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.
  11. I looked into this for you and updated lprng accordingly.
  12. A resync should clear up your issues but you might have to wait for 1 more regen.
  13. 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*.
  • Create New...