Leaderboard

Hi All, I've created a new YouTube vlog entry for your enjoyment. This one is about the latest shocking news of being let go from a job. View it here -- I appreciate it if you help me get the word out about my channel, send me some upwardly-pointing thumbs and possibly even subscribe! 🙂 Thanks! Best, Daniel

Everyone, arm-32bit and arm-64bit builds of Funtoo Linux 1.3 are now available. Search for "arm" on this page using the search field right above the table to see them: https://www.funtoo.org/Subarches Enjoy. Also note that we could use some help with updating install docs for raspberry pis as well as odroid-xu4, which I hear now should run fine with our debian-sources-lts? If you look at our odroid-xu4 page here, you'll see that at the top we link to an install guide specific to this board. I'd like to have docs like this for all the raspis as well: https://www.funtoo.org/ODROID-XU4 Thanks, Daniel

This is not linux, this is lindows :-). I can't understand why Poettering still haven't added to systemd registry and bsod...

Just a note for the future: When removing a feature many people are relying on, it often pays of to have the replacement ready. I get the feeling that essentially disabling Steam and Wine and telling people to hold of on playing games for a couple months is going to drive many people away. I understand that there is too much to do for too few people, and dropping features you don't feel are needed seems like a good option, but you are also serving a community of users. Telling a portion of that community that they are not wanted and should go elsewhere seems like a bad strategy, even if it frees up development time. Personally I'm going to hold off on the 1.3 upgrade for as long as possible, and see how that turns out.

So I noticed multilib support is being removed with the 1.3 release. I personally welcome moving to pure AMD64 and have done so ages ago on most machines I manage, but then there's all that pesky ｐｒｏｐｒｉｅｔａｒｙ　ｓｏｆｔｗａｒｅ that cannot be recompiled at-will. I've seen the wiki guide on running a x86 chroot as a workaround, but it looks like it creates a purely AMD64 system with a purely x86 system in a chroot. But I'd like to clear something out: with this particular approach, is it possible to somehow fuse the base system with whatever is in the chroot to make a makeshift multilib-like system? Reason for asking this is because in particular, some games require additional x86 software to launch / run, while the game itself outright requires AMD64 (e.g. running a AMD64-only game on steam, which itself needs x86). How about Wine, too? To quote Wine Wiki: "Even many 64-bit programs still include 32-bit components" (applicable to windows software), so being able to have a WoW64 build of wine would also be preferred, again, mostly for AMD64-only games. If that is not possible, I suppose I could try to run a gentoo chroot within my funtoo gaming machine, but this brings a multitude of other problems, so I'd rather not, if possible. :V TL;DR how do I run games that effectively require both x86 and AMD64 to function after upgrading Funtoo to 1.3?

Sweet, I still have had no issues running with flatpak. I use it for anything that's a dependency nightmare, thanks for the feedback though.

Hello, I just wanted to reach out and say I have installed Steam using flatpak about 2 months ago and I have had zero issues. I know there is away of setting up an overlay and chrooting into a 32bit kernel but that seemed like way to much work. Performance has been fantastic, and even the new proton layer they have been working on seems to chug right along. If you have any questions or if you think maybe there is a a better way of accomplishing this task please let me know. Thanks, Shane

Yo, Systemd is cancer? Yes or sure? https://capsule8.com/blog/exploiting-systemd-journald-part-1/ and https://lwn.net/SubscriberLink/777595/fd4dc34c1fbc5dde/ - coffnix

I'm just glad that we have this awesome distro to avoid all that garbage. Thanks to everyone who contributes!

Reference: Funtoo Linux Live CD

May be it's a time to go to plan9 and make it more usable for everyday use ;-).

Cool, thanks! Then I will attempt to do the stage 4 installation, but that might have to wait until the weekend.

New release of mysql-community available. Version 8.0.14 fixes numerous security fixes. https://www.oracle.com/technetwork/security-advisory/cpujan2019-5072801.html#AppendixMSQL Please pay attention to ebuild post instaaltion messages, if you setting up MySQl for the first time as emerge --config option now removed in favor of upstream and more featureful mysql_secure-installation Report any issues you may find with package install and use cases.

We finally have an answer to this question: official Funtoo AWS images: https://aws.amazon.com/marketplace/pp/B07KT3VN7Q?qid=1548635103743&sr=0-1&ref_=srh_res_product_title

Got a (new to me) Thinkpad T420s and decided Funtoo would be the primary OS. I'm happy to say I went through the install today and I now have Funtoo installed and booted. Just need to setup everything I want on it now.

Okay, first of all, I am sorry I did not post this earlier, even though I had this stopgap of a workaround effectively ready two weeks ago, yet I've been swamped with work. I may or may not have forgotten some minor, yet important steps as while doing it myself I encountered with a lot of strange c**p and I am not sure if my sleep-deprived self at that time memorized every bit, so if anything seems missing / out of place /simply does not work if You try this Yourself, do point out and I shall do my best to fix this post up. Either way, as my base goal from which I can improve upon, I set out to run CSGO (is currently AMD64-only), which also needs steam to launch and run (which is currently x86-only). This would be one typical "muh games" kind of goal, which, if reached, should allow most other stuff "just work", I guess (and for me, most other stuff did work from this point on!). So I went with that. I did achieve this goal, but it was tad a headache to figure out. My current solution is far from perfect and I shall document the main issues I am yet to solve in the end of the post. Also, if You attempt this, please make sure You read it all first and understand what is being done, why it is being done and how, as "You get to keep all the pieces if it breaks". Either way, ask if You're unsure about something. And do refer to the footnotes! For clarification, what this """""guide""""" does is describes a way to make a makeshift multilib system where the libraries are more or less seamlessly provided to the base AMD64 system by the specially crafted chroot environment. Also, this assumes mesa. I have no desire to touch the nvidia binary blob even with a ten meter pole, sorry. If You attempt this and something breaks, You get to keep all the pieces if it breaks. If it so happens I take no responsibility for Your system breakage; do this at Your own risk. I started off basing on the wiki entry on 32-bit chroot by building the chroot in /x86chroot directory. Everything in this post will assume the chroot directory to be that. Also, everything from and including the "Chroot First Steps" entries in that wiki page are irrelevant and skipped [1]. I expanded upon it with these changes: in the OpenRC configuration part, also add these lines [2] in the start() and stop() functions, in the appropriate places (i.e. at the end of the mounting / dismounting parts of the script) for start() mount -o bind /var/lib/layman/ "${chroot_dir}/var/lib/layman/" >/dev/null for stop() umount -f "${chroot_dir}/var/lib/layman/" Crate /lib32 and /usr/lib32 directories on the "host" and add these entries to fstab [3]: /x86root/lib /lib32 none bind,nofail 0 0 /x86root/usr/lib /usr/lib32 none bind,nofail 0 0 next up was to add this symlink in /lib so the x86 elf interpreter can be found where it is expected: ld-linux.so.2 -> /lib32/ld-linux.so.2 On the host, I created a file at /etc/ld.so.conf.d/98-multilib.conf with these contents, so the x86 libraries can be located and loaded properly [4]: /usr/lib32/gcc/i686-pc-linux-gnu/8.2.1 /usr/lib32/gcc/i686-pc-linux-gnu/7.4.1 /usr/lib32/gcc/i686-pc-linux-gnu/7.3.1 /usr/lib32/llvm/7/lib /usr/lib32/llvm/6/lib /usr/lib32/pulseaudio You shall need to modify the mesa ebuild [5] for the chroot system a bit, so do set up a local overlay[6] on the chroot and make sure that the emesonargs variable have this added to it: --libdir=lib32 For the stock mesa-18.3.1 ebuild, the easiest way to do this is to add this line as line #457. You will need to re-emerge mesa after this if it was already emerged at that point. Also, every time after You update/[re]build/etc. anything on the chroot, You will need to run ldconfig on the "host". Next up, is work on the "host". On whatever user that needs to run those icky x86 programs, You need to have these environment variable exported[7], one way or another (You can export these in Your .bashrc, for example) LD_LIBRARY_PATH=/usr/lib:/lib:/usr/lib32:/lib32 PATH="$PATH:/x86root/usr/local/bin:/x86root/usr/bin:/x86root/bin" Do note that the x86 paths need to go AFTER the AMD64 paths, otherwise the x86 binaries will get precedence, which is what we absolutely do not want. At this point, lest I forgot something, You should be able to simply run those x86 programs and "muh games" as first-class-citizens on Your machine again, kinda. KNOWN UNRESOLVED ISSUES: For files under /usr/share/ and such, which should otherwise be arch-independent, the programs from the x86 environment are going to load ones installed for the "host". This is normally not a problem, but for some ebuilds that are only emerged on the chroot, this can pose a problem, as those files would be missing on the "host", e.g. for steam, which then fails to locate its icons and so on. One dirty solution is to copy (or symlink) the required files by hand, but this is tedious and dirty. The other solution would be to delete the said directory on the chroot and bind-mount it from the host to the chroot, sharing it. This should otherwise work fine, but, in case of man pages, there may or may not be some differences between x86 and AMD64 versions of some of them. And since You'd get the whichever arch version installed most recently, this can lead to frustrating (and hilarious?) results. I also tried working around this by playing with XDG_DATA_DIRS and other such stuff, but steam, at least, seems to ignore those like a pro. Wine. Having a proper WoW64 wine build is non-trivial and the official ebuilds don't support that anymore, I suppose. But, with the chroot You can still do a WoW64 build manually[8] and then run it "like normal" (albeit, I'd recommend running from the build directory, i.e. without running make install). Prebuilt wine from e.g. PlayOnLinux should also run fine on this setup, in theory. [1] The chroot is assumed to be otherwise prepared by the user with all the required libs and such for the "muh games" to run by themselves and that is otherwise not covered in this post. If You attempt this but need help configuring the x86 chroot to have all You need to run 'dem muh games, You might need another thread, but do ask either way. [2] These are required assuming You're using steam-overlay (recommended) for installing the steam client launcher instead of trying to unpack the little sucker Yourself (not recommended). [3] I suppose symlinks would also work, but I opted out for the bind mounts. I don't remember why. [4] Your needs for gcc-provided lib versions may vary. I added all the ones that were available at the time; feel free to use whichever You want (and having them point to missing dirs is fine, too). The last entry with pulseaudio is required for steam as it otherwise absolutely refuses to load one specific pulseaudio lib and dies. Before You point out LD_LIBRARY_PATH, I shall note that this needs both, overall, as for some reason I am yet to figure out, some libraries absolutely need to be in ld.so.cache on thr "host" or the x86 programs are going to absolutely refuse to load them and some other libs that need their directory path to be fed through LD_LIBRARY_PATH or, again, x86 programs are going to absolutely refuse to load them. huh. *scratches head* [5] This is needed as it appears mesa hardcodes the paths where it loads the driver libs from and in the chroot that is /lib, while on the host system that points to the AMD64 versions of the drivers (whoops!), making the x86 mesa refuse to load those and dying. I found no other way to work around this other than give it the path that is correct for the "host" system at compile time. [6] How to set up a local overlay is out of scope for this guide. I am sure there's some wiki page about it somewhere or something. [7] for LD_LIBRARY_PATH, please refer to [4], and for PATH, well, You need to be able to load x86 binaries, I guess *wink*. [8] On how to build that Yourself, see Wine Wiki entry on Shared WoW64, although if You never build Wine manually yourself before, You may want to refer to several other sections of that page, too. #define rant P.S. Jesus Christ, I hate this WYSIWYG editor in this forum, how do I turn that POS off? Pretty much every single forum I ever encountered in my life allows switching to manual mode where the underlying markup, be it BB code, "markup", literal html (yes, seen that, too) or whatever is exposed directly and one can edit that comfortably. I fail to find such switch on this forum and that is making me have a baaaaaaaad time. #undef rant

Everyone, Funtoo Linux 1.3 is now officially released. Check out a detailed description of all the changes here: https://www.funtoo.org/Release_Notes/1.3-release Best, Daniel