eyesee

Funtoo Community,
One important quality of the Funtoo community, which is somewhat unique, is that officially, there are no 'developers'. In Funtoo, we are all users. Even as BDFL, I consider myself to be a user of Funtoo, first and foremost, who sometimes puts on a developer hat (OK -- I do this quite often 🙂)
Why is this distinction important?
In Funtoo, I do not want to have two different classes of people, 'users' and 'developers', with different jobs. 
I have found that communities formed around this model can manifest some cultural problems, creating walls for users that denies them a voice, and also encourages a developer culture that is disconnected from the user community.
That is why it's so important.
I have updated the introductions on the following pages to explain this in more detail:
https://www.funtoo.org/Wolf_Pack_Philosophy https://www.funtoo.org/Support_Matrix By having this in two key documents, I'm hoping this concept will become more and more familiar. Remember, when you talk about Funtoo to your friends, be sure to explain that this "user-centric" philosophy is a key part of our culture. We are all users.
Best Regards,
Daniel Robbins
also a user of Funtoo 🙂

As we have more people coming to Funtoo from Gentoo -- and not *quite* understanding the difference -- I realized I was doing a very bad job of communicating what makes Funtoo different. So to help address this, I documented the Wolf Pack Philosophy, which I feel is a great way to explain nearly all of our technical distinctives for the Funtoo project, so you have a better understanding of what Funtoo is all about. I hope you find it informative and enjoyable.
https://www.funtoo.org/Wolf_Pack_Philosophy

@zogg I will answer you.
"From recent activity it seems like funtoo development (except autogenerated updates mostly) is getting to mostly none, including activity even in on this forum."
This is an interesting and funny perspective, because it's actually just the opposite. Funtoo is more active than it has ever been, and we are starting to collaborate with Sabayon on next-gen projects, and we have been growing our Funtoo dev team too.
One thing to realize is that Gentoo has 200+ developers and Funtoo up until recently has had maybe 2-3 developers at most active at a time, but often just one. Think of that. Over the past decade, what was often 'powering' Funtoo, was JUST ONE GUY. Sometimes -- many times -- it was not even me but a more junior developer.
Why? Because I am often busy -- I have a full time job and also a toddler, a wife, two kids in college, and two more kids in elementary and middle school ?
Now we have like 10 actively contributing it seems. So 3x-10x growth in the last few months is actually huge. And we seem to now be getting an influx of people from Gentoo (we don't actively try to recruit users or devs from Gentoo, so this is just an observation and not a 'boast'.)
But I actually DO understand why you have your perspective. It is a PERSPECTIVE, but not reality.
But it's interesting to wonder: why do you have this perspective?

It is probably because you are incorrectly trying to compare the work of 200+ people to what has often been just the work of 1-2 people.

Is that fair? I don't think so. But I am sure you can 'sense' that there is often fewer package updates and general upheaval than in Gentoo. Some people actually LIKE this about Funtoo!
The reality is that actually we are doing many things that Gentoo is not doing, and solving problems that Gentoo is not solving. But these problems are not glamorous, and take time, and we care more about solving these problems than giving you the latest crap to run on your computer.

I'm quite content with our progress. But I don't think that Funtoo is a distro for everyone, and if you feel that Gentoo is more up-to-date or aligns better with what you want, by all means please use it. It doesn't matter to me what you use. No one here is going to try to persuade you to use Funtoo. If you don't see the point in using it, then use something else.

The reason why you did not understand @nrc is because you don't get an important point. You are assuming that Funtoo and Gentoo are trying to do the same thing, and be the same thing, and trying to get you to pick one over the other.

This is actually not true.

That is why you do not understand.

So now that I have addressed the 2/3 of your post that was a troll, I can address your legitimate question -- update on the current state, and roadmap/future of the project.
The current state is that the project is rapidly growing and we are working on getting our growing team to work well together. So we are recently moving beyond 1-2 devs into the 5-10 active devs range.
Autogens will continue to be added to the tree by users. Thanks to user contributions we now have MATE stage3's available for download as well as updated Enlightenment.

As far as I am aware, financially, Funtoo has more funding/resources available to it than the entire Gentoo project despite our small size, is fully independent of any external influences regarding our future, and I expect this to continue to be the reality. I have been regularly sending cryptocurrency to our most active volunteers as a 'thank you' from the Funtoo community for their contributions.
We will continue to prioritize new and interesting ways of solving complex technical challenges rather than expending huge amounts of manual effort to maintain tens of thousands of packages.

While we do this, we also hope that you will find Funtoo to be a useful tool for desktop workstation, laptop as well as dev and production servers for amd64 and arm(64) architectures, as well as riscv, which is being worked on.

For everything else, you will find out about it when it is announced ?
As always, Funtoo is a user-centric project so if there is something you want, you are encouraged to not be shy and explain why you personally want it on the bug tracker and if it is reasonable, the issue will be approved and a PR can then be submitted.

Best,
Daniel
 

 

Hi All,
I wanted to let everyone know about "next" release -- which is the new release of Funtoo that is intended to receive regular updates to all the latest packages.
Currently, a generic_64 build of next-release is available here:
https://build.funtoo.org/next/x86-64bit/generic_64/
'next' release currently includes gcc-11.2.0 and an updated unified binutils (binutils and binutils-libs have been combined, and binutils-config has been removed.) It also has a small handful of updated packages.
Our intention is to gradually add more and more auto-generated ebuilds to 'next' so that it is fully updated at all times. Next-release *may* break -- and if you use next-release, you should be aware of this. Right now, the stage3 is building but it's likely that DE's like GNOME, KDE, Cinnamon, MATE will need gcc10 fixes for certain packages to build properly. I'm hoping to generally keep the stage3 functioning at all times as we gradually update everything inside next-release to be current. We at least have a working stage3 as a starting point :) And it's fine to test DE's and open issues for any ebuilds that don't build -- so we can all start working on fixing them.
SO -- YOU CAN HELP!
So, since Funtoo is a user-based distribution, we provide a way for you, technical user, to help us in our goal of updating next-release. I am particularly interested in autogens for various ebuilds in the stage3. If you would like to autogen something on the stage3, all you need to do is open a bug at https://bugs.funtoo.org, entitled something like "autogen sys-apps/foo in next-release". Then describe what you would like to do and why. I think the most obvious candidates for autogens are stand-alone tools like gzip, for example, which are not libraries. These are the easiest initial candidates. Once your bug has been reviewed, it will be moved to a "ready to fix" state, at which point it will be possible to submit a PR to code.funtoo.org. Here are the steps to create a PR:
Create Funtoo account at https://auth.funtoo.org/new (you need this for the bug tracker and code.funtoo.org) Open an issue on the bug tracker (improvement) for the package you would like to autogen. Talk to us in #dev-help on Funtoo Discord for help in writing your autogen. When the issue moves to 'ready to fix', you are ready to submit your PR. To create your PR, first fork the kit-fixups repo on code.funtoo.org. Then on the bug tracker issue, click "create branch", and choose your forked repo (myname/kit-fixups) as where the branch will live, and make your branch a "feature" against master. Give your branch the name of the bug, like "feature/FL-9000". On your local system, "git pull; git checkout feature/FL-9000". Now do the edits... When creating your files, you can put them in kit-fixups/core-kit/next/sys-apps/foo, for example. This will make the autogen active for next release only. This is a good, conservative place to put it (rather than in 1.4-release too, which is what would happen if you added it to kit-fixups/core-kit/curated/sys-apps/foo.) When you're all done: "git add new files, git commit -a -m "FL-9000: description here." Then "git push", and you will see a URL on your console you can use to create your PR. Click on it, and create the PR against core-repositories/kit-fixups master. You may get comments on your PR -- you can simply do new commits to your "feature/FL-9000" branch and they will automatically appear in the PR without any additional steps when you push to your branch.

Also note that I have a bunch of issues I created for "funtoo-izing" various packages, which was my way of saying "autogen them and put them in next-release." You can find these bugs listed under this epic link (see the associated issues) and if you want to update any of these packages, you can simply "start work" on any of these bugs by clicking the "start work" button and then follow the steps above (minus creating the issue -- since you're using an existing one):
https://bugs.funtoo.org/browse/FL-8375

Thanks in advance for your involvement with next-release. This will be fun!
 

One more thing to consider: not everyone wants to use Discord.

Hello 2021! The first tree-regeneration of the year and its a big one!
In the ongoing effort to improve the Funtoo experience, several kits have been updated and autogenned. Here is a list of what has changed.
Perl-kit from 5.28.2-r1 to 5.32
Ruby-kit from 2.5.5 to 2.7 Please read: https://www.funtoo.org/Ruby-kit
QT-kit from 5.12.7 to 5.15.2
LLVM-kit from 9 to 11.
Python 3 support for Spidermonkey
Display manager change from GDM to SDDM
and many enhancements to Funtoo's metatools!
Also included are many bugfixes and package updates.
PLEASE NOTE:
ALL users will need to run
root# perl-cleaner --all for the perl update and
root# eselect ruby set ruby27 to set the default ruby interpreter to version 2.7.
 
If you have questions, issues, or just want to drop in and say hello you can find us on Discord https://discord.gg/BNUSpUU or Telegram https://t.me/funtoolinux
 
Installation Instructions: https://www.funtoo.org/Install/Introduction
Find and download your Subarch here: https://www.funtoo.org/Subarches
Find a bug or want an improvement? https://bugs.funtoo.org (once you have created a user account, you will need to login with your username in all lowercase)
We hope you enjoy the new updates and thank you for choosing to use Funtoo!

Hey everyone,
I have updated our Development Guide to contain information on the "Funtoo Way". The "Funtoo Way" is a really important philosophy about how we do things at Funtoo and I strongly encourage everyone to read it, even if you don't consider yourself a "developer". It helps to explain how our community works and how we can work together.
https://www.funtoo.org/Development_Guide
Best,
Daniel

Hey everyone,
I'm pleased to announce that Funtoo Linux and Sabayon (https://www.sabayon.org) are joining forces!
Now to explain what this means and how it came about.
Sabayon is one of the great Open Source projects and has an amazing reputation for delivering an easy-to-use Linux desktop that is built using Gentoo. For quite a while, Funtoo has been supporting the Sabayon effort because we believe in what they do.
Over the past several months, in chatting with the Sabayon team, it became really clear that we had a shared vision for creating a friendly and innovative community. We also were working on several next-generation technologies that were a good complement to one another. We decided it would be more powerful -- and fun -- to combine our efforts into one larger effort. So that is what we are doing.
What this means is that while each project will maintain its own personality, projects and management, we will be logically combining into a larger effort and there will be a tremendous amount of cross-project collaboration. This collaboration immediately multiplies our capabilities for delivering some next generation technologies that we have been working on and are excited to share with you.
The most immediate result of this collaboration is that moving forward, Sabayon OS efforts will be built on Funtoo. This, however, is just the first step. What I can say is that there will be much sharing of technology which will benefit both projects, and many new things.
For existing users of Sabayon and Funtoo, the communities you know and love will have new strength, support and ability to tackle a new phase of Linux Open Source innovation. I am really excited about this collaboration.
Welcome, Sabayon team!
Best,
Daniel Robbins

Funtoo Linux stages have been updated to contain the latest stuff in Funtoo: GNOME 3.36.2, latest Mesa/GL stack, support for Intel Iris graphics ("epro mix-in -gfxcard-intel +gfxcard-intel-iris; emerge -auDN @world for those who want to try), and many other updates.
Download here: https://www.funtoo.org/Subarches
Install docs here: https://www.funtoo.org/Install
Enjoy!

Hi, all.
Am only for me this seems strange?
User/group management with packages is wrong, imho. If gentoo wants constant uid/gid for some daemons, why doesn't simply tell package maintainers to do this with enewuser/enewgroup? Why this strange idea?..

Hi All,
To get ready for future improvements to Funtoo, I am adopting a multi-phased approach to 'fix Python'. First step is to address some issues that exist in the Gentoo python eclasses. I've updated these eclasses to be at least somewhat better than they are in Gentoo. These changes will be hitting the tree in an hour or so. For new ebuilds, you can now use the following rather than enumerating every single version of Python:
PYTHON_COMPAT=( python3+ ) Because the minimum version of python3 we support is 3.7, this will ensure that the ebuild will be marked compatible with 3.7 and later versions of Python. Using the '+' symbol is the preferred way to mark ebuilds using PYTHON_COMPAT because it eliminates the time-consuming process used in Gentoo of tagging every single python-using ebuild when a new version of Python comes out. I don't know how they deal with this but it is a lot of wasted energy.
Also supported in the new eclasses are the following:
PYTHON_COMPAT=( python2+ ) # python2_7, python3_7, and beyond PYTHON_COMPAT=( python3_7+ ) # same as python3+ since we start counting at 3_7 PYTHON_COMPAT=( python3_8+ ) # should be self-explanatory... PYTHON_COMPAT=( python3_9+ ) Note that pypy and pypy3 still need to be manually specified, and it is fine to combine as in the usual way:
PYTHON_COMPAT=( python3+ pypy3 ) And another important change I made to the eclass is that any ebuilds still referencing python3_5 or python3_6 will be 'auto-upgraded' to python3_7 compatibility with no user intervention. So this could close a whole slew of bugs. I'm also enabling eclass support for the upcoming Python 3.9.
IMPORTANT FOR ALL USERS: These changes will result in all of your Python-based and Python-using packages being rebuilt. This rebuild is for cosmetic purposes only -- it's due to a weirdness in emerge and the eclasses -- and really is optional and doesn't actually result in any changes except changes to the /var/db/pkg database USE flags. Therefore, these rebuilds can be completed at your convenience as they are not important. More adventurous users may look for ways to write a script to update /var/db/pkg so that these rebuilds are unnecessary -- if you attempt this, please back up /var/db/pkg first and read the following technical note!
TECHNICAL NOTE: Due to how Gentoo implemented the python eclasses, our deprecation of python3_5 and python3_6 in PYTHON_TARGETS will result in some ebuilds going from 'PYTHON_SINGLE_TARGET' mode to just regular 'PYTHON_TARGET' mode. What you will see is that some ebuilds will be turning off python_single_target_python3_7. This is OK. This is just how the eclasses were written by Gentoo -- PYTHON_SINGLE_TARGET is only enabled when there is more than one active implementation of Python in PYTHON_COMPAT. Otherwise it just falls back to using PYTHON_TARGETS.
On another note, our continued use of auto-generation continues to go well with many more packages now in the tree that are auto-generated. Expect this direction to continue.
Best,
Daniel

Hey everyone,
1.4 is almost ready to be released. Thanks so much to everyone who has contributed pull requests for 1.4 and tested 1.4. There's still a bunch of work to do, but there always will be and I believe 1.4 will be our most well-tested release so far.
After 1.4 is released, we will start development on 2.0, to be released some time in the Fall (Sept/Oct timeframe). I've been thinking about the release schedule a lot and I think that aiming for a .0 release every Fall seems to be a good idea. This means the work is completed well before the winter holidays, and fall in the US is a good season of change and looking forward to new things.
What I have left to do for 1.4 is to update the ARM builds to 1.4 and then also to update our documentation, release notes, upgrade steps and related docs. I want to incorporate the new video cards mix-ins into the official installation steps and not leave it to just be a "First Steps" item after install. This way, people can use the install docs to get their desktop environment of choice up and running, too.
I hope to get all this completed in the next few days.
 

Folks,
The Funtoo Linux 1.3 Maintenance Release 1 is now live, and contains the following updates in order to modernize the distro as well as to allow for a smoother transition to 1.4-release, currently in development:
OpenSSL updated to 1.1.1b Ruby stack updated to current 2.6.3 release and moved to independently-maintained status rather than auto-generated. node.js updated to 12.3.0. webkit-gtk updated to 2.24.2. wpa_supplicant update to 2.8 to resolve some connectivity issues. updates to dev-libs/icu, libuv, http-parser, nghttp2, genkernel, eudev System updates should be pretty pain-free with no conflicts or other issues. To upgrade, simply ego sync and then emerge -auDN @world. For security reasons, all packages that use openssl will be automatically rebuilt by emerge. If you encounter complications, a bug report to bugs.funtoo.org would be appreciated. Upgrading from openssl 1.0 to 1.1.1 did require several packages to be updated and there could be a few that were missed and still need patches.
Enjoy!
-Daniel

We are not doing rolling release for the following reasons:
Too much time is spent on fixing various breakages coming in from Gentoo, which takes time away from other things... other things are more important such as new technology like fchroot and the upcoming containerization solution... If users are interested in certain packages being updated, I am encouraging them to submit a pull request and maintain these ebuilds themselves, so I am going to focus on helping YOU maintain ebuilds rather than have a few people (this has generally been Oleg) maintaining them for everyone. This model doesn't scale -- we all need to do a little bit rather than a few people doing a lot. See the YouTube channel here: https://www.youtube.com/channel/UCKmOY6p3c9hxv3vJMAF8vVw for tutorials Short-term, this means development slows down. But in reality, it will speed up development greatly. For those hanging out on IRC, you know that Oleg who has helped to maintain Funtoo for years has moved on to a new chapter in his life, so he is no longer active on Funtoo. But even though I am not slaving away over here, thanks to incoming pull requests Funtoo is continuing to move forward and be responsive to user needs.
So think of it as a course correction as we become more agile and community-oriented, and be part of the solution. If you are reading this, it means you are part of the Funtoo community and just as able to contribute to Funtoo as anyone else (maybe with some tutorials/videos to help).
When I work on technologies, I am trying more to work on key tools that help the community be more productive (like fchroot) rather than focusing on specific ebuilds, which I am leaving to the community to manage using pull requests.
Best,
Daniel

Hi All,
I've created a new YouTube vlog entry for your enjoyment. This one is about the latest shocking news of being let go from a job. View it here -- I appreciate it if you help me get the word out about my channel, send me some upwardly-pointing thumbs and possibly even subscribe! ? Thanks!
Best,
Daniel
 
 

Hi Everyone,
I'm very happy to announce that we are now offering official Funtoo AWS images in the AWS Marketplace:
https://aws.amazon.com/marketplace/pp/B07KT3VN7Q/
Please test them out. They are optimized for specific instance types to offer the best performance possible in AWS. Please leave us a positive review (or file a bug ? ) and take advantage of these free images to Funtoo-ize AWS and advance the benefits of building software from source, optimized for the underlying CPU architecture -- Funtoo style!
Best,
Daniel

Hej!
Good it worked for you so far! ?
I can imagine VirtualBox source ebuild or the installed guest additions have some issues. As said, I remember having problems with the source package on my Intel system too. But I have not investigated any further yet due to lack of time. I just switched to the binary package and that worked for me. So unfortunately I can not tell if this is a Threadripper related problem. I hope someone else can help you better than me. Perhaps you should consider writing a bug report on the Funtoo bug tracker. By the end of year I will also retry installing from sources.
Cheers

Hey, so I think no one is really telling you the obvious -- you found a small bug, and I'm going to fix it with a commit to the profiles so that pclmul is added to CPU_FLAGS_X86 for skylake and skylake-avx512. ?

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

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

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 ?

The 1.0 release of Funtoo Linux is not going to be maintained after September 30, 2018. So please be sure to upgrade your systems to Funtoo Linux 1.2 using https://www.funtoo.org/Upgrade_Instructions so that you will continue to get updates!
We will also be starting development on Funtoo Linux 1.3 in a few days, on August 31. We are moving to a new agile (scrum) process, where we will be doing 1-week sprints (time-constrained sets of work). Our work will include some portion of fixes for 1.2 and some new work on 1.3. When we as a team decide that 1.3 is ready for various milestones (alpha, beta, release candidate) we will mark it as such. Thus, we have no hard deadline for 1.3 as I do not want to try to hit arbitrary dates that are not based on the actual work. But we will get there, sooner rather than later!

Hi All,
By default, we are now building stage3's using Funtoo Linux 1.2 release as default. This means that new installs will have this in their /etc/ego.conf:
[global]
release = 1.2
If you are still using release 1.0, that's fine -- your system will continue to use 1.0. When you upgrade to ego 2.4.1 or later, you will be able to set the release as above in your ego.conf, re-run "ego sync", and you will be upgraded to the 1.2 release. The release= setting is simply a short-hand for setting the various 1.2-related kits individually in the [kits] section, so many of you are already running 1.2.
Best,
Daniel

Hi All,
The Funtoo Linux 1.2 release is now available for use. Many of us are now running Funtoo Linux 1.2. Here's how to upgrade your system to Funtoo Linux 1.2. Note that soon, 1.2 will be the "default" version of Funtoo Linux. For now, you need to perform certain steps to switch over. We're doing this so that power users can switch over right away, and so we can make things a lot easier for less-experienced users to upgrade to Funtoo Linux 1.2. One of the features I have been working on behind-the-scenes is an "easy upgrade" functionality for ego, to perform big updates automatically. This functionality is not yet ready, but is being worked on. When this "easy upgrade" functionality is ready, 1.2 will be released via "easy upgrade" to systems who have not yet upgraded.
For now, power users can upgrade by performing the following steps. First, select the new kits in your /etc/ego.conf:
[kits] core-kit = 1.2-prime security-kit = 1.2-prime kde-kit = 5.12-prime media-kit = 1.2-prime java-kit = 1.2-prime ruby-kit = 1.2-prime haskell-kit = 1.2-prime lisp-scheme-kit = 1.2-prime lang-kit = 1.2-prime dev-kit = 1.2-prime desktop-kit = 1.2-prime Then, perform the following steps, as root:
# ego sync This will activate the new kits. Now, if you have a /etc/portage/repos.conf/funtoo symlink, remove it:
# rm /etc/portage/repos.conf/funtoo Next,
# emerge -u1 gcc This will upgrade gcc. Next,
# emerge -u1 glibc libnsl libtirpc rpcsvc-proto Glibc will now be upgraded. Next,
# emerge -auDN @system This will upgrade your core system set of packages. Next,
# emerge -auDN @world This will upgrade all other packages. Next,
# emerge @preserved-rebuild This will rebuild packages that are linked to old libraries. Now, final step:
# revdep-rebuild --library 'libstdc++.so.6' -- --exclude sys-devel/gcc This will rebuild all remaining packages that need to be linked against the new libstdc++.
At this point, you are now upgraded to Funtoo Linux 1.2! Please report any bugs to https://bugs.funtoo.org and let us know of any issues you experience, either as part of the upgrade, related to dependencies, or related to functionality on your upgraded system.
Best,
Daniel Robbins

Hi All,
Thanks to funtoo supporters, we now have a new fast download service that is available for everyone. Upgrading to the latest portage-2.3.25_beta2 will enable this service. The fastpull service consists of a lot of different moving parts, but it adds up to distfiles downloading very fast and being available. Here's how it works.
When we regenerate meta-repo and kits, ebuilds are scanned for new SRC_URI tarballs, etc. These new distfiles are queued for download. Our fastpull spider then downloads these distfiles automatically, and uploads them to Google Cloud Storage. When you try to download a SRC_URI, you hit https://fastpull-us.funtoo.org first, which redirects you to the download on fast Google Cloud Storage. The design of fastpull is to ensure that all distfiles are always available going forward. It will also help us to identify situations where for some reason or another we are missing a distfile for download, although these situations should happen less and less frequently (and hopefully disappear) now that fastpull is deployed.
Best,
Daniel Robbins