drobbins

None that I can think of. And I will start the 1.4 AWS builds soon as well.

In my testing, the --exclude method did not work and I manually modified the PDEPEND in nvidia-drivers in /var/git/meta-repo/kits for now as a local work-around. Just a note -- you will likely need to do this too. Other option is to also --exclude nvidia-drivers and then do an emerge -1 nvidia-drivers --exclude nvidia-kernel-modules after the big emerge.

If you hit EAPI errors like this, be sure to report bugs to bugs.funtoo.org and be sure to include the release of Funtoo you're using and what you tried to emerge that died and we'll get them fixed! ?

Also note that for now, if you are using nvidia drivers, add an --exclude nvidia-kernel-modules to your emerge line when emerging everything. The nvidia-kernel-modules won't build in containers and you don't need them anyway. I will look into a fix for this.

Also, it should now be possible to post replies here if you are an active forums member.... hopefully it's working ?

Hey everyone, I have added documentation on how to essentially get Steam running in Funtoo using LXD. First, you will want to follow these instructions to get LXD running: https://www.funtoo.org/LXD Then, follow these instructions, which will get you to the point of setting up a multilib Gentoo container that can run glxgears. At that point, getting Steam running should be pretty straightforward: https://www.funtoo.org/LXD/GPU_Acceleration Please test it out and let me know how it works.

Also note -- kde5-plasma *should* also merge cleanly. While I don't personally use this desktop environment, I have started testing plasma builds. Please report any issues you encounter.

Hey everyone, Just wanted to let you know that as of last night, I am happily running GNOME 3.32 with no issues (I did need to fix librsvg to get SVG's to display properly, but after that, it's working great.) I successfully upgraded my dev workstation from 1.3 to 1.4. If you want to upgrade from 1.3, or install a fresh 1.4 using one of our 1.4 stages (now available for Intel only), things should work well. One thing to note, on both the beta 1.4 stages and a 1.3 upgrade, you will need to manually run "eselect python set --python3 python3.7" to set python3.7 to be the default python interpreter instead of 3.6. Our stages will be fixed to have this set already but this is not done yet. I will also include a copy of my post from another place on the forums about upgrading from 1.3: So, upgrade is pretty easy this time around.I will have instructions soon. But you can basically use "standard" upgrade steps. I recommend emerge -1 glibc gcc first, then emerge -auDN @world should generally work. Report any bugs related to upgrade like failed builds because often this can be fixed by tweaking dependencies. Overall the upgrade is MUCH easier than 1.2 -> 1.3. One trick is to remember to "eselect python set --python3 python3.7" after python-3.7 is emerged to make it default. Also, mesa right now is very picky about USE flags related to video card. For example, if you don't have a card that supports vulkan, you cannot have vulkan in USE. Same with xa and other things that were more "permissible" before. As of yesterday, I am now happily running gnome 3.32 and it is working perfectly. I would still call things "in beta" but the remaining issues (there is a "reboot doesn't work" issue currently active, due to a missing /run/initctl -> /dev/initctl symlink) should be worked out with minor package updates.

So, upgrade is pretty easy this time around.I will have instructions soon. But you can basically use "standard" upgrade steps. I recommend emerge -1 glibc gcc first, then emerge -auDN @world should generally work. Report any bugs related to upgrade like failed builds because often this can be fixed by tweaking dependencies. Overall the upgrade is MUCH easier than 1.2 -> 1.3. One trick is to remember to "eselect python set --python3 python3.7" after python-3.7 is emerged to make it default. Also, mesa right now is very picky about USE flags related to video card. For example, if you don't have a card that supports vulkan, you cannot have vulkan in USE. Same with xa and other things that were more "permissible" before. As of yesterday, I am now happily running gnome 3.32 and it is working perfectly. I would still call things "in beta" but the remaining issues (there is a "reboot doesn't work" issue currently active, due to a missing /run/initctl -> /dev/initctl symlink) should be worked out with minor package updates.

Been doing automated tests all day today, adding fixes as I find things, and also added a fix so kde-plasma-5 should merge fine now.

More fixes added for a bunch of build issues I detected overnight. Ibus, gnome-settings-daemon and mutter compilation without wayland enabled, and others. Will continue doing build tests over here to try to find any issues I can.

I found a last-minute bug related to xorg-server building with some new tweaks to mesa and libglvnd. I have applied some fixes and as of right now the tree is being regenerated. When you have the fixes, 'glvnd' global USE will be enabled with workstation or desktop profile. And you may need to re-emerge mesa-19.1 if xorg-server doesn't build. Since it's a beta, I won't always make things perfectly smooth -- that is the goal for the release ?

Everyone, 1.4-release is now in BETA -- GNOME 3.32 should now build and be ready to test. Please file bug reports for any bugs you encounter. Best, Daniel

1.4-release stages, currently in ALPHA, are available for download for all Intel 32-bit and 64-bit CPUs including generic_64: https://www.funtoo.org/Generic_64 Please give them a try. Right now, the core system is pretty solid but GNOME 3.32 doesn't merge yet, and we are expecting a major update to the GL subsystem prior to release. So things may be a bit bumpy in the desktop arena for now but for console-based stuff, the 1.4 builds should be pretty solid. Best, Daniel

Everyone, Please check out https://www.funtoo.org/LXD -- I have begun rewriting this page to give everyone a tutorial-style introduction to LXD and to guide you through the process of setting it up. I have tested these steps myself and it should ensure a fairly pain-free setup of LXD. Note that the second half of the page isn't rewritten yet (Starting with the "features" section) but the top half is.

Hey all, I've been really busy this month -- in Funtoo-land as well as on other projects (currently in Washington, DC area doing some work.) I've just moved 1.4-release to ALPHA status (it was "in development" status) and will be working on getting some alpha builds available. I've updated the snapshot that 1.4 is based upon and frozen 1.4 so 1.4 will be based on a June 21, 2019 snapshot of Gentoo. I will also be looking to start a non-frozen variant of Funtoo again... New Firefox and firebox-bin are now in the tree to address security issues. I've also added the latest version of dev-lang/dart to the tree. This is a very interesting language that comes from Google and recently received a major revamp to make it really nice. Here's an interesting article about it: https://hackernoon.com/why-i-moved-from-java-to-dart-8f3802b1d652 . I am using Dart to do multi-platform development using Google's flutter (which uses Dart) -- and I've enjoyed my experience so far. More updates to come... Best, Daniel

I am seeing only one issue with libevent not rebuilding correctly against the new openssl. I'll be pushing a fix for this shortly... workaround for now is to manually merge or unmask 2.1.8 of libevent and merge. This builds fine against openssl-1.1.1 -- it just happens to have an old mask entry preventing emerge from seeing it.

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

Enjoy!

Container users, All containers now have private meta-repos now. If you previously had a shared meta-repo, you can fix meta-repo by performing the following steps: # rm -rf /var/git/meta-repo # ego sync Then run ego sync to update your meta-repo as needed. Note that 1.2 is no longer receiving updates and many of you need to upgrade to 1.3. I can assist by loading up a new 1.3 container for you to migrate to -- email me if you are interested in this. ?

Everyone, I have just started getting kit-fixups ready for 1.4-release development. Some key changes that are coming in 1.4-release: move away from eselect opengl and to libglvnd. official support of container-based solution for steam, etc. updates to pam and pambase 1.4-release will be tracking "current" gentoo for a while and will freeze sometime this summer, likely in June 2019. If you want to get involved, chat on #funtoo and look at the latest commits to kit-fixups on code.funtoo.org. I'll also be doing some introductory videos on how to get involved with the new release of Funtoo. -Daniel

And to expand on this some more -- While it's true that we don't have a dedicated security team and rely on users to report CVE's, this doesn't mean that we trail behind Gentoo in all areas. For example, we have a fix in gettext for CVE-2018-18751 that gentoo does not appear to have. We also had important fixes for avahi remote exploits before Gentoo. In general this means that our ability to be up-to-date with CVEs depends upon our users' ability to report these. In areas where we have had good reports, we have sometimes had things fixed sooner.

Hi All, Forums have been updated to the latest version and I have re-enabled a new version of member map. Let me know if you encounter any issues. -Daniel

Just to expand on this, it is perfectly fine for us to be a bit behind Gentoo in terms of updates, and even quality of ebuilds in some areas. We will improve, as I get more videos out to help our community do better and my job is to keep our bug tracker responsive to reported issues. I think it is important to be realistic and realize where we are now, it would be foolish to think that a small community is doing everything it needs. That is fine -- we are improving. That is the key thing.

Hi all -- We are in the final stages of prepping a total rewrite of the graphics stack in Funtoo which is based on libglvnd rather than "eselect opengl". This work was done by TemptorSent and improves our NVIDIA support but also essentially updates how GL is handled under Funtoo for everyone to be more modern. If you want to play around with this and have NVIDIA hardware, see https://www.funtoo.org/Package:NVIDIA_Linux_Display_Drivers#TemptorSent's Experimental NVIDIA ebuilds . I actually have libglvnd running fine on my Intel-based laptop as well, so these steps can be used on any hardware -- just re-emerge mesa and skip nvidia-drivers. Debian-sources-lts 4.9.168_p1 is now unmasked for everyone. I have also significantly updated and rewritten the pam and pambase ebuilds. These incorporate the latest updates from gentoo plus a bunch of funtoo changes. Basically, the new pam-1.3.1.20190226.ebuild contains the very latest upstream fixes for pam, and also incorporates the old pambase ebuild. The new pambase ebuild -- pambase-20190426.ebuild -- is simply a 'virtual' package. It just depends on pam to satisfy any dependencies of packages that require pambase. The other funtoo-specific changes in pam are: Relax pam_limits so that it attempts to set resource limits but does not prevent you from logging in if it somehow fails to do this. This is important for preventing lxd users from being locked out due to /etc/security/limits.conf changes in containers. Incorporation of pam_faillock, which is optional functionality that can disable an account login after multiple failed login attempts. This is required by some security standards. (This patch comes from Red Hat.) Deprecate consolekit and systemd support in the ebuild. Deprecate multilib support in the ebuild. This stuff is currently keyword masked and expert users are encouraged to unmask them and test them -- but be prepared for the possibility of login issues on your test system, which means have a livecd or liveUSB handy. Best, Daniel