drobbins
-
Posts
513 -
Joined
-
Last visited
-
Days Won
282
Content Type
Profiles
Forums
Blogs
Posts posted by drobbins
-
-
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.
-
-
-
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-primeThen 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-primeThen, 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.
-
Hi All,
I've upgraded our authentication framework, and you should be able to log in. But the migration was not without hiccups.
You should be able to log in to forums, wiki, bugs, code.funtoo.org and friends.
You might notice that some bugs on bugs.funtoo.org have my name listed as "drobbins#1". This isn't because I think I'm awesome, but because our migration triggered some bad behavior in JIRA and I need to repair its user database. It's annoying, but very fixable, and I'll get to this soon, and should continue to work in the meantime.
If you have login issues, please message me privately on the forums, or contact me directly on discord or telegram (links on the main wiki page.)
-
With the steam container running, use the launcher with the "attach" option to connect to a shell inside the container and try running "glxgears", and debug from there. There is info on the Steam page on the wiki on how to do this.
-
Steam now has an official launcher script to make it easier to use, called "steam-nvidia-launcher". I've updated the Steam documentation at https://www.funtoo.org/Steam to now direct users to use the launcher script instead. It's easier to use and more robust, as you just have one script that does everything from download the docker image, to create the container, to start the container if it already exists and needs to be started locally.
steam-nvidia-launcher also fixes a bug where the Steam container wouldn't start consistently after a reboot.
Launcher is available here. Remember to consult the wiki (link above) for usage info:
https://code.funtoo.org/bitbucket/users/drobbins/repos/docker-steam/browse/steam-nvidia-launcher
-
You simply need to eselect python and choose another default python implementation first.
-
If the man page is correct, then this should work.
SOLVED - libepoxy fails
in Installation Help
Posted
This bug was reported to the bug tracker at https://bugs.funtoo.org/browse/FL-6748 .