Tassie_Tux

Hey I just want to jump in and say it's OK, I understand if there are some people that are disappointed about us not having pure rolling releases anymore. It's fine to express your opinions here. I think that's totally understandable, frankly.
Now yes, these changes were totally needed and like I said earlier, there is a strategy that is being very successful so far even though it's in its early stages. The strategy is that I support our users (with things like YouTube videos, code.funtoo.org, fchroot) to be contributors to Funtoo. So yes, right now I think it's fair to say we are playing a bit of catch-up with Oleg moving on to other things -- BUT, considering we just started this effort, I also think it's fair to say that in time we will likely catch up and even go beyond what we were capable of before.
And that means that we can push ahead more with many more updates and possibly even a more up-to-date release (betas?) or a true rolling release again.
In the mean time, I ask @lazlo.vii and others to be supportive of those expressing disappointment since I want people to have a place to vent their disappointment -- I don't see it being overboard or in poor taste at all -- and in my experience, the worst thing for a community is if any disappointment is bottled up and never expressed (and then we need to guess why people are unhappy) so I would much rather have people share how they feel. As long as they understand the reason for the decision, it's fine to share feedback and vent a bit.

Not a criticism or to belittle Drobbins hard work, but I have been doing this for years with a simple bash script.  If you haven't seen his video on fchroot on the forum here and don't know what it does search for fchroot.
I simply keep 2 bash scripts in ROOT directory of any device I want to use it with, navigate to that directory (mounted via NFS)  from the BIG BOY computer and run 1st one script to enter the QEMU chroot, the other to cleanup when exiting.  Here's an example from my odroid C1+, armv7a:
#MOUNTDIRS - script name mount -t proc none proc mount --rbind /sys sys mount --rbind /dev dev mount --bind /dev/pts dev/pts mount tmpfs -t tmpfs -o rw,nosuid,nodev,noexec dev/shm mount --bind /tmp tmp cp /etc/resolv.conf etc echo "" echo "don't use pump" echo 'env -i HOME=/root TERM=$TERM DISTCC_HOSTS="star,cpp,lzo joshua,cpp.lzo mrpink,cpp,lzo micah,cpp,lzo localhost" MAKEOPTS="-j8" chroot . /bin/bash -l' # UMOUNTDIRS - script name umount proc umount -l sys umount -l dev/pts umount -l tmp umount dev/shm umount -l dev umount tmp That's it!  The 1st script echoes some reminders to me and the exact line to chroot in, I just copy & paste it (the script can't run that line directly).  This is a particularly good example because I also set some environment variables on the way in, shows that.
Of course you must set up your makefile as drobbins states, in my case:
QEMU_SOFTMMU_TARGETS="i386 arm" QEMU_USER_TARGETS="i386 arm" And install qemu.  Finally, you must run /etc/init.d/binfmt either in rc-update (bootup) or add starting/stopping it to the scripts.
I find it mainly handy for things that overwhelm the whopping 1G ram on the odroid, it'll work but it's s...l...o...w.  If at all possible it's much faster to use the cross-compile SYSROOT method, search on the web for "gentoo cross-compile", you'll find it.  Unfortunately it doesn't work with many packages, particularly the intensive ones you'd like to use it on.  One notable exception is LLVM.  The odroid can't build it anymore as of a couple of years ago, but I found a trick to build it natively on the powerful machine and output a 32 bit arm package in minutes.  Last time I used the qemu chroot method it was > 10 hours on a core2.  Here are my notes:
****WARNING!!!  DO NOT DO THIS, THERE IS A PROBLEM, READ BELOW****
# LLVM trick notes: # 1. you must have same version already installed on the compile machine # 2. in $SYSROOT/etc/portage/profile/use.mask, put a file that has this in it: abi_x86_64 llvm_targets_X86 # 3. you must have libffi installed: armv7a-hardfloat-linux-gnueabi-emerge libffi type: ABI_X86="" LLVM_TARGETS="BPF ARM" armv7a-hardfloat-linux-gnueabi-emerge -BO llvm:<version> probably just this now: LLVM_TARGETS="BPF ARM" armv7a-hardfloat-linux-gnueabi-emerge -BO llvm:<version> #5. Check out the package.env stuff for llvm, see llvm.conf ENJOY! # ${SYSROOT}/etc/portage/package.env sys-devel/llvm notmpfs.conf nodistccccache.conf llvm.conf # ${SYSROOT}/etc/portage/env/llvm.conf ABI_X86="" CMAKE_EXTRA_CACHE_FILE=/usr/armv7a-hardfloat-linux-gnueabi/etc/portage/env/cmake_cache_files/llvm.cmake # ${SYSROOT}/etc/portage/env/cmake_cache_files/llvm.cmake SET (CMAKE_INSTALL_LIBDIR "lib" CACHE STRING "" FORCE) SET (LIB_SUFFIX="" CACHE STRING "" FORCE) SET (LLVM_TARGETS_TO_BUILD "ARM;BPF" CACHE STRING "" FORCE) SET (LLVM_LIBDIR_SUFFIX "" CACHE STRING "" FORCE) SET (FFI_LIBRARY_DIR "/usr/armv7a-hardfloat-linux-gnueabi/usr/lib" CACHE STRING "" FORCE) SET (FFI_INCLUDE_DIR "/usr/armv7a-hardfloat-linux-gnueabi/usr/lib/libffi-3.2.1/include" CACHE STRING "" FORCE) THE PROBLEM: This indeed makes the package in arm-32 bit format, but later I found it is linked to lib64, non-existent on the arm.  In my case, the odroid does just fine with it for my uses and I'm sure that can be remedied with CMAKE_OPTIONS, but since I have no problem I haven't worked on it.  I skipped Funtoo 1.3 on the odroid, when 1.4 is released I'll update to that and get to the bottom of a solution on it.  It makes a package which you can then install natively on the arm with emerge -K.  Hmm, it's been so long, maybe I did fix that lib problem, maybe that's why it JUST WORKS®.  I dunno...try it at your risk...
I used to build my arm kernels with the SYSROOT method, but nowadays I find that pump distcc on the native device is just as fast and easier.  Here's the basic script for doing such a thing, minus the dracut and mkimage operations:
export SYSROOT=/usr/armv7a-hardfloat-linux-gnueabi armv7a-hardfloat-linux-gnueabi-emerge odroidc1-sources #custom amlogic kernel # cd usr/src/linux # ${SYSROOT}/usr/bin/xkmake menuconfig # cd ${SYSROOT} KERNEL_VERSION=-$(readlink ${SYSROOT}/usr/src/linux|cut -d'-' --complement -s -f1) cd ${SYSROOT}/usr/src/linux ${SYSROOT}/usr/bin/xkmake -j3 ${SYSROOT}/usr/bin/xkmake -j3 modules ${SYSROOT}/usr/bin/xkmake -j3 INSTALL_MOD_PATH="/mnt/nfs/odroid" modules install ${SYSROOT}/usr/bin/xkmake -j3 uImage cp ${SYSROOT}/usr/src/linux/arch/arm/boot/uImage /mnt/nfs/odroid/mnt/sdcard/storage/uImage.funtoo cp ${SYSROOT}/usr/src/linux/arch/arm/boot/dts/meson8b_odroidc.dtb /mnt/nfs/odroid/mnt/sdcard/storage/meson8b_odroidc.funtoo.dtb Just a rough guide there to show what can be done.
The gentoo cross-compile info tells you to use xkmake rather than make when using the cross-compile ${SYSROOT} method.  Here's my ${SYSROOT}/usr/bin xkmake file for the odroid:
#!/bin/bash make ARCH="armv7a" CROSS_COMPILE="armv7a-hardfloat-linux-gnueabi-" INSTALL_MOD_PATH="${SYSROOT}" $* My 2 cents worth...

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

Everyone,
arm-32bit and arm-64bit builds of Funtoo Linux 1.3 are now available. Search for "arm" on this page using the search field right above the table to see them:
https://www.funtoo.org/Subarches
Enjoy. Also note that we could use some help with updating install docs for raspberry pis as well as odroid-xu4, which I hear now should run fine with our debian-sources-lts? If you look at our odroid-xu4 page here, you'll see that at the top we link to an install guide specific to this board. I'd like to have docs like this for all the raspis as well:
https://www.funtoo.org/ODROID-XU4
Thanks,
Daniel
 

Got a (new to me) Thinkpad T420s and decided Funtoo would be the primary OS.
I'm happy to say I went through the install today and I now have Funtoo installed and booted.
Just need to setup everything I want on it now.
 

Moved to Funtoo from Arch after many years.  Did try Gentoo six months back but it was a dependency nightmare compared to Funtoo.  I love how Funtoo just works and seems to be a little more intuitive with packages and current versions.  Anyway here is a pic of my desktop.  Running bspwm on a 32" Samsung Ultra Wide Screen curved monitor.  Top screen shot is a nice empty one and the bottom is a wonderfully fake busy ;)

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

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.

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!

Following ebuilds now available for testing in Funtoo/Linux
sys-fs/zfs-0.7.9
sys-fs/zfs-kmod-0.7.9
sys-kernel/spl-0.7.9
These versions have a portion of upstream fixes and also support for newer kernels. Ebuilds added without keywords and do require manual setting of /etc/portage/package.keywords before update.
https://github.com/zfsonlinux/zfs/releases

New kit, lllvm-kit now added. It consist of small numbers of ebuilds that are directly related to the sys-devel/llvm. The rationale behind this is that ebuilds for llvm had no update for very long time and are problematic to maintain due to those ebuilds were spread all over different kits. Now they are from one kit. This kit is enabled by default and involves following update steps:
ego sync emerge -C llvm:0 clang:0 emerge -1 llvm mesa emerge -auDN @world emerge @preserved-rebuild  

5.12 branch released now

We currently offer iptables support and have for a long time.

For IPv6, our datacenter doesn't have native IPv6 but we will likely set up a tunnel soon to provide IPv6 addressing. That's kind of a bummer. It is more than offset by our datacenter powering our servers using solar power, and passively cooling them (no AC needed) for over half of the year, giving our tiny datacenter an efficiency that rivals Facebook and Google's build-outs.
As for new technology, we are now using ZFS RAID-Z, Intel Optane to accelerate our IO, have 40 core (80 cores hyperthreaded) systems, and are now using LXD and kernel 4.14.12-2 (migrating away from OpenVZ and RHEL6 kernels.) And we also document our setups so others can do the same. (Docs for our 2nd generation infrastructure are in the works.)

Hi All,
In order to have more predictability for users, Funtoo Linux is going to adopt a six-month release schedule starting in 2018. Our kits are currently at 1.0-prime, and we are going to skip over 1.1-prime (it didn't get done fast enough) and jump to 1.2-prime. We are going to start development on 1.2-prime today, December 28, 2017, with a planned release of the production 1.2-prime on January 21, 2018. We will then maintain the 1.2-prime kits for the next six months, until they are replaced with 1.3-prime.
The schedule in detail is as follows:
December, 28, 2017: start development on 1.2
January 1, 2018: we will be rolling out a python-modules-kit and perl-modules-kit as new kits (for 1.0+)
January 4, 2018: Alpha release of 1.2
January 11, 2018: Beta release of 1.2
We will have a release candidate when we feel we are ready, with a scheduled production release on January 21, 2018.
On February 1, 2018, the 1.0-prime kits will be deprecated and users will be migrated to the 1.2-prime kits (this should be seamless unless you've hard-coded 1.0 or 1.1-prime kits in ego.conf.)

For 1.2-prime, what we are going to attempt to deliver is a default gcc of 6.4 and all ebuilds updated to be in sync with Gentoo as of January 2018. We will be using a 'current' (non-snapshotted tree) until around January 4th when we will freeze the tree and then will start backporting security fixes and updates.
In a few hours, the 1.2-prime kits will appear but will be tagged as DEVELOPMENT quality, so they should not be used until they are made default. I will post updates here on our progress.
Regards,
Daniel

Hi All,
Coming in the next regen of meta-repo are ebuilds and supporting tools for configuration of Razer (https://www.razerzone.com/) keyboards and mice. This allows you to create neat glowy and color effects, as well as do other useful things.
To configure your Razer devices, first perform the following:
# emerge polychromatic # reboot Then, you will need to add your desktop user to the plugdev group, and then start openrazer-daemon in your personal .bash-login or .xprofile:
openrazer-daemon At this point, you should be able to run polychromatic controller in your desktop environment to configure your Razer devices.

http://blog.chromium.org/2014/05/update-on-npapi-deprecation.html
I just tried the Java verification site https://www.java.com/verify/ and the applet does not work for me with chromium 38.0.2125.24. It does work with firefox 31.0 and oracle-jdk-bin 1.7.0.67.

Hi all,
A multitude of new kits are coming your way. I'll give you a list of what they are and share other kit-related updates with you.
The new kits you'll be seeing soon are: ruby-kit, haskell-kit, ml-lang-kit, lisp-scheme-kit, and xfce-kit. With the exception of xfce-kit, these kits are all essentially sub-kits of dev-kit (and now have their own kit, just to try to pare down dev-kit a bit.) xfce-kit is for the XFCE 4.12 desktop environment.
In addition, we have snapshotted/frozen the following kits: *java-kit*, ruby-kit, haskell-kit, ml-lang-kit, lisp-scheme-kit, *dev-kit*, xfce-kit and *desktop-kit*. Note that the kits in red are ones that previously following gentoo-current, and are now snapshotted as of today (Oct 22). The other kits listed are the new kits.
With this wave of new kits, I am pushing forward the kit paradigm. With additional snapshotting of previously 'current' kits, I am putting funtoo's developer focus on getting the new 1.1-prime core-kit, media-kit and friends truly ready for production. The goal is to shift major updates to that they come via kit upgrades rather than a trickle of new package updates.
What should you expect over the rest of the year? Expect further stabilization of our now-snapshotted kits. Also, when PHP 7.2.0 is released, expect a php-kit that will be snapshotted at 7.2-prime rather than following current as it does now. You should also expect to see a new generation of kits made available so you can select more recent packages. Also on the radar are automated features to help switch kits cleanly -- think of these as things like perl-cleaner and friends but that get automatically triggered when you switch kits to ensure a smooth transition. And yes, you will likely see a few more kits added to the mix, along with new ego features.
With these new kits, the kit paradigm has been further advanced and will continue to advance. Along the way, you may feel that Funtoo Linux updates are getting 'stuck' or not going as quickly as you like, due to kits being frozen. If this impacts you, please provide us with feedback so we are aware of what things you need updated and why -- and understand that the pause in version bumps is more of a temporary phenomenon rather than a permanent reality. The updates will come -- in the form of kit bumps! The adjustment of our dev process will happen, and soon will reap rewards by offering stability as well as the latest ebuilds for you to choose from.
Please feel free to share your questions and concerns on this thread.
Best Regards,
Daniel

Hi All,
ego-2.2.0 has been released, and is an important update, and will be appearing in meta-repo soon.
New functionality has been added to help you view kit configuration. To view your current kit settings, type:
# ego kit status This will display your current kit settings, as well as their stability level. The stability level is set by Funtoo and lets you know if you are running something we consider 'stable' or not. We recommend that all our users use kits that have a 'prime' stability level. Note that this is different than the kit having 'prime' in its name! When I create a kit, I may call it 1.1-prime if the goal is to make it production-quality, but the moment it is created, it is still considered 'dev' (developers only) status. Type "man ego-kit" for more information on this.
It is now also possible to view a similar listing, but one that displays ALL available kits and their stability levels, by typing:
# ego kit list This new release of ego also includes a host of other improvements, such as improvements to the "ego doc" MediaWiki parser.
Enjoy, Daniel

this link is about testing meta-repo, which will replace portage tree. it has some basic explanation of what kits are. master branches means they are have no direct control by Funtoo and pulling Gentoo ebuilds as they are. using master branch of curated kits, controlled kits, possibly can be provided, but it will not be actively supported.
More details (notice it's old news and ports-2017 is replaced with meta-repo) but it can probably give the idea: 
http://www.funtoo.org/News:New_Ports-2017_tree_and_Kits
It's not possible to give 100% information for now what will be production ready maintaining procedure as meta-repo is still beta. There will be announcement and a guide.
Stabilization of ebuilds is not performed -- if you mean adding stable keywords -- is what actually stable was. 

That's my Plasma 5 system.
 
https://imgur.com/a/0aEUV

there is paludis already and which is even slower than original portage -- it doesn't require python but it does require boost -- just an example. I don't think this will fix anything you maybe think it will by porting to another language. The main problem in portage is not that it's written in python but that many parts of it are obscure, undocumented and doesn't look good, highly over-engineered and maybe also recent portage development only in maintenance mode - not in fixing code or development mode. Many blame portage for being slow, partially agreed with that, but, again it's not because it's in python. Remember that good code is good in any language. To summarize - cloning portage in other language will be only a clone, that's rewriting same framework and design in language that can be really bad experience and can result in much worse cases, like paludis. Ultimate fix, maybe, would be creating package manager from scratch.

Then all complete! Nothing for update or rebuild!
Thank you very much!

Just closing this topic. All works fine.

It is unfortunate that boot has been unsuccessful. Comments left on the Talk page.

I have created a Funtoo for Beagleboard X15. I use the latest released kernel from Texas Instruments that they have with the 3.0 SDK, the kernel version is 4.4.19
EGL works on this version in yocto, I will try to port it to funtoo, I will update to 4.9 when it is supported by TI.
 
If anyone is interested in working on this let me know.
 
Michel