eyesee reacted to krish in Goodbye 2020 and Hello 2021! Big updates to LLVM-kit, Perl-kit, Ruby-kit, and QT-kit, and metatools!
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.
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!
eyesee reacted to drobbins in The Funtoo Way
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.
eyesee reacted to drobbins in Funtoo Linux and Sabayon Joining Forces
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!
eyesee reacted to drobbins in Funtoo Linux 1.4 MR 5 stages available
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
eyesee reacted to lego12239 in acct-user/acct-group seems wrong
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?..
eyesee reacted to drobbins in Updated Python Eclasses and Autogen
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.
eyesee reacted to drobbins in 1.4 is (almost!) ready to go!
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.
eyesee reacted to drobbins in 1.3 Maintenance Release 1 Now Live
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.
eyesee reacted to drobbins in Funtoo release model
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.
eyesee reacted to drobbins in New drobbins YouTube vlog
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!
eyesee reacted to drobbins in Official Funtoo AWS Images
I'm very happy to announce that we are now offering official Funtoo AWS images in the AWS Marketplace:
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!
eyesee got a reaction from checko55 in Virtualbox issues fresh Funtoo install
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.
eyesee reacted to drobbins in Explicit setting CPU_FLAGS_X86 for Skylake Xeon E3 v5
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. ?
eyesee got a reaction from drobbins in Explicit setting CPU_FLAGS_X86 for Skylake Xeon E3 v5
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?
eyesee reacted to AdiosKid in Bentōō (An user-friendly Stage4 of Funtoo Linux.)
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 ?
eyesee reacted to drobbins in 1.0 release deprecation, 1.3 release development starts!
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!
eyesee reacted to drobbins in Funtoo Stages and Release 1.2
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:
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.
eyesee reacted to drobbins in 1.2 Funtoo Linux Release
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.
eyesee reacted to drobbins in New fastpull distfile service
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.