Jump to content

drobbins

Funtoo Linux BDFL
  • Content Count

    391
  • Joined

  • Last visited

  • Days Won

    177

Everything posted by drobbins

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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."
  6. 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.
  7. I've committed a fix for this -- should be in the tree in 15 minutes.
  8. Stuff like this should be reported to the bug tracker not the forums, but I will go ahead and fix it.
  9. 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
  10. 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.
  11. 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.
  12. @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.
  13. 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.
  14. 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.
  15. Also, please, open a bug for this issue on the bug tracker.
  16. Yes, it boots fine for me using UEFI. What hardware are you attempting to boot it on? (Laptop model or motherboard)
  17. @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.
  18. 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.)
  19. 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.
  20. 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
  21. You simply need to eselect python and choose another default python implementation first.
  22. Hi everyone, Since the 1.4 release, we have technically supported running Steam under Funtoo using LXD, docker or chroot, but we didn't really have an official build of Steam or official instructions, so a lot was left to the user and I know this was frustrating for a lot of people. When I realized that Steam setup was an ongoing, painful, still unresolved issue, I started work on an official set of instructions for setting up Steam, and I wasn't happy with the existing documentation out on the Interwebs for getting this set up, so I had to create our own reliable solution for this. The fruit of this effort is that we now have an official Steam Docker image for use on NVIDIA systems, as well as official setup instructions here: https://www.funtoo.org/Steam This is now the *official* way to install Steam on Funtoo. If you use our GNOME stage3, you are 95% of the way to getting Steam up and running, audio and all. If it's not working for you, open a bug, and we'll work on fixing the bug. No longer are you left to try to figure this out on your own or troubleshoot on your own. Also note that getting NVIDIA acceleration in containers working properly is a lot more complex than Open Source drivers. You should expect an Open Source edition of the Docker image to appear soon, along with similar detailed and officially-supported instructions. Enjoy! And let me know how it works (you can post in the Announcements Discussion forum) -Daniel
  23. I've added this documentation on subuids and subgids to the wiki, linked under the main LXD page: https://www.funtoo.org/LXD/What_are_subuids_and_subgids%3F#How_Does_LXD_Use_Subuids.3F
  24. OK, interesting, this means that as you found, the defaults in login.defs are not wonderful. From the useradd man page (see bolded part): SUB_GID_MIN (number), SUB_GID_MAX (number), SUB_GID_COUNT (number) If /etc/subuid exists, the commands useradd and newusers (unless the user already have subordinate group IDs) allocate SUB_GID_COUNT unused group IDs from the range SUB_GID_MIN to SUB_GID_MAX for each new user. So this means, when you created /etc/subuid, you magically enabled useradd to try to start assigning subuid ranges to new users. And by default, its subuid range conflicts with the one in our LXD docs -- LXD eats up this range. There is no point for useradd to be assigning subuids and subgids to new users it creates by default. It's a cool feature if you need it, I guess, but it should be off by default. So /etc/login.defs should have SUB_GID_COUNT and SUB_UID_COUNT set to 0 by default. Also see bcowan's bug report and my response here: https://bugs.funtoo.org/browse/FL-6773
×
×
  • Create New...