drobbins

Hey Everyone,
We have a new FAQ developed that allows you to more easily browse answers. See:
https://www.funtoo.org/FAQ
You can also submit your own FAQ questions which I will answer! ? Hope you enjoy it.
Best,
Daniel

Hello Everyone --
I want to highlight some improvements that have been made to the wiki besides our new FAQ (https://www.funtoo.org/FAQ)
We now have a new Subarches page that is a lot easier to navigate: https://www.funtoo.org/Subarches
And the look of various things like notes, tips, warnings, etc. have been improved for a cleaner, more consistent look. This is a good sample page to browse the new look. Note that you may need to "hard reload" the page to get the new CSS: https://www.funtoo.org/Upgrade_Instructions
Enjoy!
-Daniel
 

Hi All,
As we move to our third-generation infrastructure, I am currently migrating containers to BTRFS+SSD (from ZFS and HDD+Optane) which may result in up to an hour of downtime, especially if you have a lot of data stored in your containers. But the result will be much, much, much faster IO. So if you have seen your uptime on your container change recently, this is why.
Best,
Daniel

Recently I fell into the trap having march=skylake in my CFLAGS which is not really supported by GCC 7. Now I have fixed this by setting CFLAGS march option to broadwell which makes sense and works so far. Thanks to all the people involved doing the hard work on that beast!
To squeeze out the last bit of my CPU I wonder if it makes sense to adjust the CPU_FLAGS_X86 setting to the output I am getting from the cpuid2cpuflags tool. The output I am getting does differ from the recommendation on the subarches wiki page for skylake and the given x86-64bit make.defaults for Intel Skylake. Could the output be different because I have a Xeon E3 instead of an iCore 3/5/7?
My ego profile shows the following:
arch: x86-64bit build: current subarch: intel64-skylake The basic CPU_FLAGS_X86 option for Intel Skylake is according to the Subarches page:
aes avx avx2 fma3 mmx mmxext popcnt sse sse2 sse3 sse4_1 sse4_2 ssse3
make.defaults for x86-64-bit Intel skylake contains the following (difference underlined):
aes avx avx2 f16c fma3 mmx mmxext popcnt sse sse2 sse3 sse4_1 sse4_2 ssse3
cpuid2cpuflags for my Xeon E3 v5 states there is another option available (difference underlined):
aes avx avx2 f16c fma3 mmx mmxext pclmul popcnt sse sse2 sse3 sse4_1 sse4_2 ssse3
It seems like f16c and pclmul are not used in many packages explicitly. But I am also compiling non-ebuild stuff and some stuff from my own overlay. In general I have not that much insight how CPU flags are used and I do not know if the compilation of GCC with those additional flags would automagically improve compilation results in general.
So my question is: would it be of any benefit to modify the CPU_FLAGS_X86 flag to reflect what cpuid2cpuflags spits out?
Thanks!
eyesee

Hello Everyone --
I want to highlight some improvements that have been made to the wiki besides our new FAQ (https://www.funtoo.org/FAQ)
We now have a new Subarches page that is a lot easier to navigate: https://www.funtoo.org/Subarches
And the look of various things like notes, tips, warnings, etc. have been improved for a cleaner, more consistent look. This is a good sample page to browse the new look. Note that you may need to "hard reload" the page to get the new CSS: https://www.funtoo.org/Upgrade_Instructions
Enjoy!
-Daniel
 

Hey Everyone,
We have a new FAQ developed that allows you to more easily browse answers. See:
https://www.funtoo.org/FAQ
You can also submit your own FAQ questions which I will answer! ? Hope you enjoy it.
Best,
Daniel

Hey Everyone,
We have a new FAQ developed that allows you to more easily browse answers. See:
https://www.funtoo.org/FAQ
You can also submit your own FAQ questions which I will answer! ? Hope you enjoy it.
Best,
Daniel

Hey Everyone,
We are starting to build Funtoo Linux 1.3 ALPHA builds. We will let you know when these are uploaded and ready for testing.
UPDATE: Ryzen 1.3 Alpha builds now available for download and testing: https://build.funtoo.org/1.3-release-std/x86-64bit/amd64-zen/
-Daniel

Hey Everyone,
We are starting to build Funtoo Linux 1.3 ALPHA builds. We will let you know when these are uploaded and ready for testing.
UPDATE: Ryzen 1.3 Alpha builds now available for download and testing: https://build.funtoo.org/1.3-release-std/x86-64bit/amd64-zen/
-Daniel

Also note that I will be helping with this new distribution because I think it is very much needed and wanted by the user community. 

Well, thank you for your work and for basing it on Funtoo. Please keep the project moving forward and let me know if there is anything I can do to help.
Best,
Daniel

OK, done.... ?

OK, done.... ?

Looks great -- good work!

Hi folks O/
 
few years ago I wonder about a friendly version of Gentoo and Funtoo, the gentoo community don't liked, but I keep did some tests but I didn't continue, well, few week ago I start again, but this time only a Funtoo Friendly version, and now I have something really beginning.
the project will resume in few flavors and one version with a overlay with update packages and few extra.
the funtoo flavors are X+openbox, gnome and Plasma, they are just the Funtoo Stage3 Generic with few packages and some configuration.
and has one version with plasma, but with an overlay with few update packages and other stuffs, a stage more out of the box, I want make something to people learn about gentoo/funtoo or for who use the system without spent hours to build the system. 

the webiste will be done in the next weeks, and the stages will be available in the next days "sorry, I'm with one pc now, and the net is a turtle".

website -> https://bentoo.info/
binhost -> http://binhost.bentoo.info

github repos : 
overlay -> https://github.com/lucascouts/bentoo

configurations -> https://github.com/lucascouts/bentoo-cfg

I don't know if the funtoo community will like but anyway I'll forward with this project, but will be great if few users could help with feedback or criticisms.

thank you anyway ?

There is nothing wrong with some branches having "detached head". You will see this when there has been a recent update to our 1.3 development branch.
If you see this at the end:
Sync successful and kits in alignment! :) Then it means things are OK.

The Funtoo authentication system has recently been upgraded to use Authy, a SMS-based verification service. We're using this to protect the funtoo community against spam bots and other nasty things, which are unfortunately an issue we need to deal with.
You will not be able to log in to Funtoo until you upgrade your account!
To do this, go to https://auth.funtoo.org/login, log in, and you will be prompted to provide an SMS number to verify your account.
This will only happen once -- it normally happens upon account registration only -- but existing Funtoo users will need to go through this extra step.
Apologies for the inconvenience, but unfortunately this kind of thing is becoming necessary.
Best,
Daniel

Also note -- in the next release of Funtoo Linux (1.3), we will default to having suid disabled in xorg-server, but it will remain enabled by default in 1.2. Thanks, Oleg, for your work on this.

Good questions.
The issues with blockers due to not having the correct version available will be disappearing with 1.3-release when it is available. It currently happens because we are using different snapshot dates for different parts of the tree, and we are not going to to do that anymore with 1.3+.
1.3-release will be a 'frozen' release when it is released, meaning it will gradually become out-of-date, though we will be bumping critical packages and backporting security fixes. But the process we use to create 1.3 will be used to launch 1.4 development immediately, so we are getting better at this and releases will come a lot more often ? The goal is to have a very stable and tested release that doesn't have unanticipated changes, until you want to pull them in by moving to the next release. So this is the pattern we are trying to establish. Hopefully we can get releases to the point where they are coming frequently enough people do not feel like packages are "stale". That is the goal. With the improvements in our tools, I think we will be able to achieve it. It is actually easier to do releases often rather than infrequently -- right now we are just in the "growing pains" stage where we are in the process of moving to a more rapid release schedule.
As funtoo's team grows, we will have the person-power to actually move ahead of Gentoo in more areas. Right now, these areas are limited due to us only having a ~4 person team and Gentoo having several hundred developers.

Good questions.
The issues with blockers due to not having the correct version available will be disappearing with 1.3-release when it is available. It currently happens because we are using different snapshot dates for different parts of the tree, and we are not going to to do that anymore with 1.3+.
1.3-release will be a 'frozen' release when it is released, meaning it will gradually become out-of-date, though we will be bumping critical packages and backporting security fixes. But the process we use to create 1.3 will be used to launch 1.4 development immediately, so we are getting better at this and releases will come a lot more often ? The goal is to have a very stable and tested release that doesn't have unanticipated changes, until you want to pull them in by moving to the next release. So this is the pattern we are trying to establish. Hopefully we can get releases to the point where they are coming frequently enough people do not feel like packages are "stale". That is the goal. With the improvements in our tools, I think we will be able to achieve it. It is actually easier to do releases often rather than infrequently -- right now we are just in the "growing pains" stage where we are in the process of moving to a more rapid release schedule.
As funtoo's team grows, we will have the person-power to actually move ahead of Gentoo in more areas. Right now, these areas are limited due to us only having a ~4 person team and Gentoo having several hundred developers.

Thanks for adding the 2FA to the site.  I wish more would do it.  I use it every where I can.  Even my home server has the google-auth pam modules for ssh.

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

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

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

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