Fran?ois

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!
 

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

Glad to hear @mantas -- we hope to get 1.3 released officially in another week. Still a lot of issues to fix which you'll get automatically via updates.

Hi All,
Within 12 hours, I plan to move 1.3-release to BETA status.
Along with this comes the very important change on 64-bit platforms -- I am removing multilib and making "pure64" compatibility the default. This means that 1.3-release builds with the x86-64bit arch will be 64-bit only.
This is done for a variety of reasons, most important of which is that the world has had a 64-bit PC instruction set for approximately 15 years. It is time to drop 32-bit support. For those who still need 32-bit support, it will be available via a Funtoo 32-bit chroot setup.
The story behind multilib is rather complex and interesting, and might be the focus of a future blog post, but for now, you will just have to trust me -- multilib support in Gentoo is a pain in the butt. It takes a lot of effort to work with and slows us down. Our efforts are best spent in other places, and chroot should work for the vast majority of users who truly are running a critical 32-bit application (other options are 32-bit containers, etc.)
EDIT: Upgrade Instructions Here: https://www.funtoo.org/Upgrade_Instructions/1.3-release
Best,
Daniel

Yes, sorry for the inconvenience of this change -- dropbox is supposed to be set up under each user's home directory rather than installed centrally. While this fixes quite a few other complications it does make things more complicated for you. Fortunately there is a pretty good way to get dropbox working the way you want -- using /etc/local.d. See if this works for your needs. Try creating an /etc/local.d/dropbox.start script that will start dropbox as the user of your choice when the system boots:
#!/bin/bash su username -c "/usr/bin/dropbox start" Then...
# chmod +x /etc/local.d/dropbox.start This will run dropbox as user "username" when the system starts.