Leaderboard

Hi all, Please test ego-2.6.0, which is currently masked for testing. As many of you have noticed, there have been significant changes to kit generation and currently, ego is less "flexible" about mixing and matching kits from different releases. This is a side-effect of massively improved merge scripts, which now leverage python's asyncio, use a thread pool for database operations, and have much better internal design. I have put a lot of work into this new codebase and the new design is much better foundation for future development. Currently, it is possible to select a custom xorg-kit or gnome-kit, but all other branches are locked down to the release. For those who may be upset -- We have never "officially" supported anything but the standard collection of release kits anyway, with some tweaks of xorg-kit and gnome-kit, so users who push the limits of mixing and matching kits right now have been using Funtoo in a way that is beyond the scope of what we intended to deliver, likely without realizing it. So if you want to use an unusual combination of kits -- awesome -- we want to support this officially in time, but we are working on getting there the right way rather than committing to supporting all these unusual combinations all at once. If you have gotten accustomed to this flexibility in the past, know that this lack of flexibility is only temporary as we continue to build out our next generation of innovative technologies for managing kits. Re-enabling support for any old combination of kits is going backwards, in my opinion, and instead we need to move forward to OFFICIALLY support more combinations of kits. For the time being, you may need to write a small script to get things exactly how you want in meta-repo. We encourage people to use combinations we officially support if possible -- 1.2 with some variation of gnome-kit or xorg-kit. Things will be easier that way for the time being. Also, we now have the 1.3-release kit names and definitions finalized, so this will allow us to move forward with 1.3 release development. Best, Daniel

My current desktop

Funtoo is my favorite Linux distro. I've been using it enthusiastically since at least 2012. I've been tinkering a lot with FreeBSD for the past 3 years which has divided my attention, but I still use Funtoo as my primary desktop OS. Here's my concern. I'm using Funtoo 1.2. In the past few months, I've encountered a LOT of blockers when trying to emerge world. Sometimes the blockers are things that don't exist in the portage tree, sometimes they are things which need to be unmasked, and sometimes they are things which need to be unmasked by keyword. I went through a short period of time where I filed a lot of bugs about these blockers. But one bug I filed was dismissed as a "workaround" because I filed a bug about something which needed to be unmasked. My feeling on the matter is that, if I try to emerge a package that it unmasked by default, then it should emerge without any problem. It should NOT require me to unmask anything or unmask something by keyword. Only ebuilds which are themselves masked or keyworded should rely on other ebuilds which are masked or keyworded. That's my opinion, but if that is not the opinion of the Funtoo project, I ask that such opinions be made plain so that people like me who love the project and want to contribute do not become nuisances by filing bugs or complaining when that is not the goal of the project. But at the same time, if that is not the goal of the project, then why are such bug reports being closed as "workaround" instead of being properly fixed? I asked Daniel and the rest of the Funtoo devs to please make a clear statement about these sorts of things so that users like me who are trying to help can be a genuine help without being a nuisance.

Funtoo doesn't support systemd and probably never will.

Just wanted to let everyone know if you don't visit www.funtoo.org often that we've updated our wiki with a new version of mediawiki (finally) and a new skin! Enjoy, everyone.