drobbins

@dkg I am assuming you are experiencing the bug under Funtoo since you are posting on the Funtoo forums. In that case, open the bug on the Funtoo bug tracker. You should not open bugs for issues you experience under Funtoo on the Gentoo bug tracker. So yes, if my assumptions are correct, then close the bug as invalid on the Gentoo bug tracker and open one on the Funtoo bug tracker. If you are experiencing the identical issue on a Gentoo box, then yes, you report the issue you are experiencing on Gentoo to the Gentoo bug tracker. But since you are posting here about a Funtoo issue, and you opened a bug on the Gentoo bug tracker, this is wrong. Just because you also use Gentoo does not entitle you to report Funtoo bugs to the Gentoo bug tracker. This is not helpful at all since I don't see the issue, so the issue will NOT get fixed in Funtoo. I hope that makes sense.

@dkg you should really not file Funtoo bugs on the Gentoo bug tracker. It is an issue in Funtoo, not Gentoo. Please close the bug as invalid on Gentoo's bug tracker and file it on Funtoo's bug tracker.

@kratsy-tony you can "steam-nvidia-launcher attach" to attach to a running container and edit /root/steam.sh. But I think I know why the container didn't update ... keep reading below. BTW, that's really cool that you were able to use the steam-nvidia-launcher under Optimus -- I hadn't tested that. The audio issue *should* be fixed with 1.6, but you *may* need to "blow away" your old container to fix the audio issue, now that I think about it. I don't think the launcher is checking to make sure the container is 1.6 so it's running your existing 1.5 container. Do a "docker ps -a", grab the container ID, then do "docker rm <container-id>". When you use steam-nvidia-launcher the next time, the container will be recreated and you'll have a 1.6 container. Edit: also note your existing downloads should be preserved since they are bind-mounted into the ~/SteamData directory in your home dir on your host.

@dkg you may find that some of the 'left over' things depending on 3.6 are actually 'old'/deprecated and can be removed. For example, pycrypto is old, and should be deleted, and pycryptodome is now being used in its place.

Debian-sources-lts-4.19.98_p1 is now unmasked in the tree with the latest security fixes for Intel. Also available is a new steam-nvidia-launcher 1.6 with fixed audio. The big news is that Funtoo is using a new approach with webkit-gtk. For those who don't know, or need a refresher, webkit-gtk is an ebuild that is part of GNOME. It provides Web browser (HTML rendering + javascript) functionality. In fact, webkit-gtk is just a snapshot of the sources of WebKit (https://webkit.org) which is the foundation of many modern Web browsers, and is actively developed primarily by Apple and other contributors. GNOME just grabs a version of these sources and puts them in a tarball and gives it a version number. Interestingly, although Apple appears to be the primary commercial contributor to WebKit, the WebKit project was actually started by KDE. Learn more here: https://en.wikipedia.org/wiki/WebKit We decided to stop using GNOME's webkit-gtk. Why did we do this? Our Webkit-gtk ebuild started experiencing issues when we upgraded GNOME or some other ebuild recently. In tracking down the problem, I found our current webkit-gtk ebuild, which is the latest upstream stable release from GNOME, was actually very out-of-date and still riddled with bugs that were already fixed in webkit.org's current WebKit. It became very frustrating to work with and there wasn't an easy fix like adding a 'simple patch' or set of patches to fix the situation. So I couldn't just tweak things and get webkit-gtk working well. And the build process used in the ebuild was also unreliable. So rather than try to patch all the significant bugs in webkit-gtk, I took a very recent (2020-01-30) snapshot of WebKit, and applied minor patching to it to get it working under GNOME. The webkit-gtk (now webkit) ebuild was also heavily reworked to build from WebKit sources using the official process, which is very similar to the method that Apple and other use to build WebKit. I also removed a lot of extra USE variables that can be used to tweak WebKit functionality, but can also be used to *break* WebKit if you are not careful. I kept the essential USE variables that we *need* to be able to adjust (X, wayland, etc.) The result is that we are now using our own WebKit that is very lightly forked from upstream WebKit. When you update your system, you will likely see both webkit and webkit-gtk getting merged. webkit-gtk-2.26.3.20200130.ebuild is now simply a virtual/placeholder ebuild that depends on the 'real' net-libs/webkit ebuild, which is our essentially rewritten ebuild. This resolved issues with Evolution HTML rendering not working recently , as well as malfunctioning of midori and other webkit-based browsers. The bug that started this effort can be found here: https://bugs.funtoo.org/browse/FL-6956 I am currently updating our stages to include the new WebKit, prebuilt in our gnome stage. For those upgrading, the sources of WebKit are 1GB and it takes a long time to compile (typically 20 minutes to an hour) because it is a whole lot of code.

This bug was reported to the bug tracker at https://bugs.funtoo.org/browse/FL-6748 .

Some more updates headed your way: nvidia-drivers-440.44 now available. Remember that you will also need to emerge nvidia-kernel-drivers for your kernel to make the kernel modules available. steam-nvidia-launcher is now at 1.5. Fixed are annoying gtk+ dialog messages when starting up the launcher, and also FL-6907 (thanks @nrc) the pulseaudio config hard-coded for UID 1000.

Recent Funtoo News: GNOME 3.34.3 is now available in Funtoo (as part of gnome-kit 3.34-prime, the default kit) A Gentoo dev found that it is theoretically possible for arbitrary users on the system to locallly 'exploit' a package while it is being built. Portage-2.3.78-r1 addresses this by removing 'other' permissions from /var/tmp/portage. ego-2.8.0 is released with updated sync code.

For the love of God, please don't post full build logs on the forums. You can upload them as attachments to the bug tracker.

A full set of Funtoo Linux 1.4 maintenance release 2 stages has been uploaded to build.funtoo.org. These stages include: GNOME 3.34.2 Updates to debian-sources-lts (4.19.87_p1) Updated Linux firmware Updated firefox Various other fixes If you are already using 1.4, you can get all these updates via a regular ego sync and world update. But if you are planning to install 1.4 from scratch, these builds are up-to-date.

As Funtoo Linux 1.4 continues to mature, it has become a much better long-term stable option than Funtoo Linux 1.3, so maintenance and updates for 1.3 will end on March 1, 2020, and users are encouraged to upgrade to 1.4 at this time, or before. In about a week, there will be a second maintenance release of Funtoo Linux 1.4, which will simply be rolled into the official 1.4 release, but will result in updated binary stage3s and GNOME stage3s. The updates will include bumping GNOME from 3.34.1 to 3.34.2 as well as upstream kernel updates with the latest security fixes, in particular ones focused on side-channel vulnerabilities on Intel systems. These updated stages will have 2020-01 timestamps and will be good options for those needing to reinstall an existing 1.3 environment.

I just committed a fixed git-r3.eclass -- added 'PROPERTIES='live'' to the eclass. In my opinion, this is a silly new feature of Portage that was not necessary, as git-r3.eclass is not a wonderful idea in the first place and didn't need a new 'feature' to prevent it from breaking with the network-sandbox feature. Over-engineering. Full fix should appear in meta-repo in 15 minutes.

I've committed a fix just now for libglvnd, but not the larger git-r3.eclass issue (which I'm working on now). The fix for libglvnd should be live in about 15 minutes. I'll repeat what I said in the bug, as I think it's important to point out that git-r3 is a bad idea. Gentoo seems to be in love with git-r3.eclass but it sucks as I point out below: "OK, I want to zoom out on this problem for a moment and just state that git-r3.eclass is in general a bad idea and the 'github hack' should be used in its place if at all possible. Yes, we need to fix git-r3.eclass, but when we have the opportunity, we should convert git-r3 ebuilds to github-hack ebuilds. Benefits are numerous: git-r3.eclass actually uses git, which bypasses mirroring/CDN infrastructure, meaning we don't have a copy of the source code so it could disappear at any moment. Bypassing this infrastructure also bypasses Manifest files, which are used to securely verify integrity of source code git-r3.eclass is fragile and hacks the ebuild to run 'git' during src_unpack() – it does not use src_fetch() at all. So to fix this specific problem, I just updated libglvnd to not use git-r3.eclass. We will need to still fix this but should start to remove all occurrences of git-r3 in core system ebuilds in Funtoo."

You're welcome. Let us know if you encounter any other issues, or if you just want to leave general feedback here. And it's fine to report problems here too -- if they seem like a real bug, don't be shy to report it to the bug tracker too.

I've committed a fix for this -- should be in the tree in 15 minutes.

Stuff like this should be reported to the bug tracker not the forums, but I will go ahead and fix it.

Answers: "build" is not currently used. It was used when we were doing unstable and stable builds but now all are "~" snapshots. The steam-nvidia-launcher is NVIDIA-specific. The Mesa-based one is coming soon and will be called "steam-launcher" or "steam-mesa-launcher". I just did a 1.4 release of the NVIDIA launcher which will be the basis for the Mesa one (had to fix some stuff before the Mesa one is forked.) -Daniel

Before releasing the Mesa-based Steam launcher, it was time to do a maintenance release on our official NVIDIA Steam launcher. This package now has an ebuild and the docs at https://www.funtoo.org/Steam have been updated accordingly. To emerge, type "emerge steam-nvidia-launcher" and then consult the wiki documentation for host setup steps. This new launcher uses an updated container image which will store your downloaded games in ~/SteamData on the host, rather than in the container. This will allow for game persistence (not having to re-download games) for future iterations of the container. For this to work well, the launcher was tweaked so that the steam user inside the container is created dynamically and its UID is set to the UID of the user creating the steam container. This way, there are no permissions problems with ~/SteamData. Also in this release, there were a few minor changes related to PulseAudio which have seemed to resolve an issue of PulseAudio sometimes not initializing properly.

Hi Everyone, I"ve posted a new YouTube video which I hope you find useful. Troubleshooting is an important topic and something worth reflecting on.

@ennui AppArmor is enabled again, and for a bit the dovecot mess resurfaced. But I disabled the dovecot profiles this should have already been resolved. If necessary, reboot your container and it should be fine.

I was able to reproduce the issue with pulseaudio not working until I killed it and I restarted. I spent a day trying to figure out why this was and no luck so far. I am wondering if it's an issue related to how steam interfaces with pulseaudio.

GNOME 3.34.1 is ready for use and will become the default version of GNOME in 1.4-release in a few days. If you would like to use it now, you can add the following to /etc/ego.conf: [kits] gnome-kit = 3.34-prime Then ego sync, emerge -auDN @world, emerge @preserved-rebuild, and restart xdm and you should be in business. If you would like to avoid upgrading to GNOME 3.34, now is the time to insert the following code into /etc/ego.conf: [kits] gnome-kit = 3.32-prime Then, in a few days when 3.34-prime becomes active, you will stick with 3.32-prime and not get the updates until you want them.

Also, please, open a bug for this issue on the bug tracker.

Yes, it boots fine for me using UEFI. What hardware are you attempting to boot it on? (Laptop model or motherboard)

@lazlo.vii will be adding persistent games storage (beyond container wipes) at some point. Can you first make sure that the container works with PulseAudio? I do not currently support ALSA. When you are in the container testing glxgears, type "echo $DISPLAY" and make sure it is set to the same value as your regular user outside of the container, and also run "xhost +local:" as your regular user outside of the container. Then see if glxgears will start. I have not reproduced this issue but someone else has, but they did not tell me the root cause of it. So hang tight, should be fixable.