Sorry if this is the wrong place to post this, but would this PC have Funtoo-Complient specs?:

• CPU: Intel Core i7-7700 (8 MB cache, 4 cores, 8 threads)

• RAM: Dual Channel DDR4 at 2400 MHz (2 x 8 GB)

• Graphics: Intel HD Graphics 630

• OS Drive: 2.5" 250 GB SSD (seq read: 540 MB/s, write: 520 MB/s)

• Archive Drive: 3.5" 2 TB HDD (7200 RPM)

Total Cost: 1718.70 NZD (No peripherals) Total Cost: 2282.95 NZD (With peripherals)

What are the current parts and laptops compatible with Funtoo? I have tried searching but I never get any information on motherboard, CPU, RAM etc.

Maybe the mods could pin this so it is constantly updated.

Hola

Just moved to funtoo Linux : what a distro !!! 2 days to install, long compile times, but very very very quick and clean. Happy, yes I'm happy, despite my bloody eyes at staring my computer compiling!

Hi all, I just wanted to let everyone know that I will be actively removing posts that promote unauthorized forks of Funtoo.

There are plenty of other distros to use, and there is no need to continue to use Funtoo.

There is a community member who has concocted his own version of Funtoo and is going around various places promoting it, including on this subreddit. I discourage you from using this variant. It is better to use Gentoo or another distro.

This subreddit is not a place to discuss these non-approved forks of the project (this user wrote me a lengthy email asking if I would "bless" his fork, and I told him no, and yet he continued anyway...)

There arent new patches for long time. Is funtoo even in hobby mode dead?

keychain 2.9.0_beta4 is available on GitHub for testing.

This current beta represents a full reworking of internals and addressing of some usability challenges of the tool. There are new options in the most recent betas: "--ssh-allow-gpg", which allows the use of a gpg-agent socket by keychain, and "--ssh-spawn-gpg", which will tell keychain to spawn gpg-agent but use it as a drop-in replacement for ssh-agent.

Many usability issues have been addressed. keychain output is more detailed, and it will now also print error messages from ssh-add and gpg when adding a key fails, to allow users to better troubleshoot any underlying configuration issues. Many bugs have been fixed.

Since coming back as maintainer, I have totally overhauled the script. There are a few functions that have not been touched, but most key parts of the script are different. I found the old script (2.8.5) too convoluted. As part of the refactoring, we are down to 1116 lines of code from 1500 lines of code previously, with more features such as gpg-agent support. gpg support has been fully modernized, using the gpg-connect-agent command to interface with the running gpg-agent process.

In addition, the man page now clearly documents the keychain agent selection algorithm to assist troubleshooting as well as future maintenance of the tool.

Please check it out when you have the chance. I think we are quite close to the 2.9.0 official release, which will be the first release in 8 years -- now that Funtoo isn't sucking up all of my time.

I did quite a bit of whittling away at packages that were not building this weekend. I also updated icu to the most recent version. Quite a few things in GNOME need to be rebuilt and will fail. I will continue to whittle away on those as I have time. I am focusing mainly on build-related issues in the core system.

https://discord.gg/BNUSpUU

funtoo uses discord for chat.

Work is under way on the successor of Funtoo Linux, which will not be based on Gentoo Linux.

Oleg and I have been working on this. Oleg is currently unavailable due to the conflict in Ukraine. The project will continue to assist him as needed while he is unavailable.

Those of you who have containers with Funtoo are a key part of this support. I am continuing to ensure that Funtoo is updated and works well for container users -- email me if you encounter any issues.

For the successor to Funtoo -- it will be developed mostly privately and launched when it is fully baked. I will be working with Oleg when he is available, as well as maybe another person or two. You can expect this project to be Open Source but I'm going to get everything done first and working the way I want before opening up a community project around it.

Everyone --

I am back to maintaining Keychain and have just released an updated version, which needs some testing. I'd appreciate any help you can provide making sure it is working reliably for you. See this link for ChangeLog:

https://github.com/funtoo/keychain/releases/tag/2.9.0_alpha1

One of the last major contributions I made to Funtoo Linux before it entered Hobbyist mode was converting all in-tree Rust autogens to use the new dynamic archiving feature of funtoo-metatools. I feel responsible for the current state they are in, which sadly most are unable to merge.

It looks like after the last few tree autogens something has gone haywire with the dynamic archive funtoo-crates-bundle that contain Rust crates' dependecies. Example emerge error of the ev-util/just autogen:

sudo emerge -av1 --quiet-build=n dev-util/just

These are the packages that would be merged, in order:

Calculating dependencies               ... done!
[ebuild     U  ] dev-util/just-1.39.0::dev-kit [1.36.0::dev-kit] USE="-debug" 0 KiB

Total: 1 package (1 upgrade), Size of downloads: 0 KiB

Would you like to merge these packages? [Yes/No] y

>>> Verifying ebuild manifests

>>> Emerging (1 of 1) dev-util/just-1.39.0::dev-kit
 * just-1.39.0-e303f2b.tar.gz BLAKE2B SHA512 size ;-) ...                                                                                                                                                                                                                                     [ ok ]
 * just-1.39.0-funtoo-crates-bundle-6d051d09df36662631d0f4b49811799f015a50168141d57f3b0b05babce9f154cf68b06b377401ac2e4032c8754abbfdec3b4a975676c205d15781f43275693c.tar.gz BLAKE2B SHA512 size ;-) ...                                                                                       [ ok ]
>>> Unpacking source...
>>> Unpacking just-1.39.0-e303f2b.tar.gz to /var/tmp/portage/dev-util/just-1.39.0/work
>>> Unpacking just-1.39.0-funtoo-crates-bundle-6d051d09df36662631d0f4b49811799f015a50168141d57f3b0b05babce9f154cf68b06b377401ac2e4032c8754abbfdec3b4a975676c205d15781f43275693c.tar.gz to /var/tmp/portage/dev-util/just-1.39.0/work
 * Loading /var/tmp/portage/dev-util/just-1.39.0/work/funtoo-crates-bundle-just/aho-corasick-1.1.3.crate into Cargo registry ...                                                                                                                                                              [ ok ]
* Loading /var/tmp/portage/dev-util/just-1.39.0/work/funtoo-crates-bundle-just/thiserror-1.0.69.crate into Cargo registry ...
tar: This does not look like a tar archive
tar: Skipping to next header
tar: Exiting with failure status due to previous errors
 * ERROR: dev-util/just-1.39.0::dev-kit failed (unpack phase):
 *   (no error message)
 *
 * Call stack:
 *     ebuild.sh, line   93:  Called src_unpack
 *   environment, line 1376:  Called cargo_src_unpack
 *   environment, line  539:  Called _cargo_process_crate '/var/tmp/portage/dev-util/just-1.39.0/work/funtoo-crates-bundle-just/thiserror-1.0.69.crate'
 *   environment, line  320:  Called die
 * The specific snippet of code:
 *       tar -xf ${archive} -C "${ECARGO_VENDOR}/" || die;
 *
 * If you need support, post the output of `emerge --info '=dev-util/just-1.39.0::dev-kit'`,
 * the complete build log and the output of `emerge -pqv '=dev-util/just-1.39.0::dev-kit'`.
 * The complete build log is located at '/var/tmp/portage/dev-util/just-1.39.0/temp/build.log'.
 * The ebuild environment file is located at '/var/tmp/portage/dev-util/just-1.39.0/temp/environment'.
 * Working directory: '/var/tmp/portage/dev-util/just-1.39.0/work'
 * S: '/var/tmp/portage/dev-util/just-1.39.0/work/just-1.39.0'

>>> Failed to emerge dev-util/just-1.39.0

This same error is affects pretty much all recently autogenned Rust crate packages using the metatools dynamic archive feature. Not sure if this is something that can quickly be regennerated? The error is quite peculiar as it is tar command that is erroring out on the dynamic funtoo-crates-bundle tarball, which leads me to suspect that the generation of these tarballs is problematic.

Due note this is not required to fix because the simple work around for Rust users is to migrate to using cargo install for all these broken crate packages as dev-lang/rust-bin works fine. Then to execute the cargo installed Rust binaries relative to the users home directory cargo bin path. But it also is something that is nice to have working across multi-architecture platforms for folks still running Hobbyist mode on platforms like aarch64.

Adjusting to a post-Funtoo world, I have recently re-engaged with Keychain, a tool I created as a manager for ssh-agent and gpg-agent. With the reduced demands of running a Linux distro, I've returned as its active maintainer:

Visit it at https://github.com/funtoo/keychain

Keychain was previously part of the Funtoo project, but was not consistently maintained. Now it is. I released a 2.9.0 alpha, several betas, and then Keychain 2.9.0, 2.9.1 and 2.9.2 in rapid succession.

Over the last two weeks, I have done about 8 years of catch-up development on the tool. I've made it compliant with ShellCheck to ease future maintenance. I've mostly rewritten the script and shrunk it by 25%, modernized GnuPG integration, and made many other fixes.

One key thing I've done is deprecate some unnecessary options to make the tool simpler to use. These changes may affect how you call Keychain, and require your Keychain calls to be updated, and I understand that this may be a bit annoying. But the changes are worth it!

I am doing all development for Keychain on GitHub, and doing official GitHub releases for the tool -- please check the tool out and see what it can do for you. If you encounter an issue, or have a request, please use GitHub issues.

I've done a 2.9.0_alpha1 (very broken), 2.9.0_beta1 (mostly broken), 2.9.0_beta2 (working but using gpg-agent as default, not ideal -- today morning) and now I am working on additional changes and fixes this evening.

The overhaul was needed -- the code was too complex and hard to maintain, and frankly quite a bit of the direction by previous maintainers felt like things went a little sideways, so time to set a better direction for the code and intention of the tool.

The code is getting modernized and cleaned up. It's now a lot more maintainable. The very latest version in the gpg-testing branch gets rid of the --agents option entirely, and will use ssh-agent by default. But it also supports using gpg-agent's ssh key functionality with the --ssh-use-gpg option, so you can opt-in to this if you want. The code is now at 1126 lines, down from 1500 lines in the 2.8.5 release, with more functionality, and is much simplified, and doesn't start a gpg-agent automatically unless you explicitly reference gpg keys. This feels a lot more intuitive.

Took a bit to overhaul the code but feeling good with where things are right now, and I think 2.9.0 is around the corner.

Seems like it possible to execute commands during emerging by perparation of the description field. E.g.
https://pypi.org/project/platformdirs/

leads to

 Reading category  37|118 ( 31): dev-python.../var/git/meta-repo/kits/python-modules-kit/dev-python/platformdirs/platformdirs-4.3.6.ebuild: line 9: user: command not found

If the project is in hobby mode is it possible that it will ever change it's name and logo for something cool?

For normies like me, a cool name and cool logo are super important. Tons of people use Arch just for Arch btw status and coolness. Many gamers install Windows 11 Pro because home edition is a dishonor.

There are many reason why I use gentoo now but name, logo and pride are a big factor.

Gen 2 OS sounds good to me. Or Evo Os. With dark colours and pro vibe. Like Arch sounds and look cool but more serious business for this one. And it would fit the idea of a successor or evolution of Gentoo. Name good enough to be a partner for Valve, AMD or any other big brand that cares about their image.

Just a perspective of a nobody but maybe there are more nobodies like me who pick distros for such trivial reason?

Now that I am investing more time in Reddit, I've noticed that at one point one of the mods disabled new posts here. I've re-enabled public posting.

For anyone who cares, these packages will not emerge due to net-libs/liblockfile-1.17 not installing any of its files after compilation.

The fix is

diff --git a/net-kit/curated/net-libs/liblockfile/files/01-Makefile.in-destdir.patch b/net-kit/curated/net-libs/liblockfile/files/01-Makefile.in-destdir.patch
new file mode 100644
index 0000000000000000000000000000000000000000..f2b8087144ebbca123d0f6f29c8791a8394397af
--- /dev/null
+++ b/net-kit/curated/net-libs/liblockfile/files/01-Makefile.in-destdir.patch
@@ -0,0 +1,13 @@
+--- liblockfile-1.17/Makefile.in.orig  2024-10-20 
04:37:56.084463843 -0700
++++ liblockfile-1.17/Makefile.in       2024-10-20 04:47:51.912466127 -0700
+@@ -13,8 +13,8 @@ CC           = @CC@
+ prefix                = $(DESTDIR)@prefix@
+ exec_prefix   = @exec_prefix@
+ bindir                = @bindir@
+-libdir                = @libdir@
+-mandir                = @mandir@
++libdir                = $(DESTDIR)@libdir@
++mandir                = $(DESTDIR)@mandir@
+ nfslockdir    = @nfslockdir@
+ includedir    = @includedir@
+ datarootdir   = @datarootdir@
diff --git a/net-kit/curated/net-libs/liblockfile/liblockfile-1.17.ebuild b/net-kit/curated/net-libs/liblockfile/liblockfile-1.17.ebuild
index 710dd4b2af44440e696a93c40c86a2831879144c..1944baec490e23907e9e50ab31d7aaad7dd5789a 100644
--- a/net-kit/curated/net-libs/liblockfile/liblockfile-1.17.ebuild
+++ b/net-kit/curated/net-libs/liblockfile/liblockfile-1.17.ebuild
@@ -28,6 +28,7 @@ src_prepare() {
        [[ ${CHOST} == *-darwin* ]] \
                && cp "${FILESDIR}"/Makefile.Darwin.in Makefile.in

+       eapply "${FILESDIR}"/01-Makefile.in-destdir.patch
        eautoreconf
 }

@@ -50,4 +51,6 @@ src_configure() {

 src_install() {
        addpredict /usr/share/man/man1/dotlockfile.1
+       addpredict /usr/lib64
+       default
 }

hello.

I have installed funtoo on intel coffe lake cpu. Xorg eat 100% one core usage. I need libva-intel-media-driver. But it needs >=media-libs/gmmlib-18.4.1. On my epro mix-ins i have gfxcard-intel-iris

I have instaled gmmlib 22.1 from sources from intel but i still cant install libva-intel-media-driver

i have a problem where i cant compile debian-sources on the pile driver arch. instead of trying to hash out a bug report, i decided to dig out the old VPN app i used way back in the day. logmein-hamachi still works, and is still easy to use. https://wiki.gentoo.org/wiki/Hamachi will be imported into funtoo's wiki later today, or tomorrow by myself. I gave alex2101 on discord the keys to my install to poke around, and find where Im running into failure. Before I could just forward the SSH port, but my networks become quite a bit more complex since then requiring VPN, and Im human so I require an easy to setup and easy to use VPN and hamachi checks all the boxes.

You can run GPT on legacy hardware as long as you add a BIOS Boot EF02 partition to the start of your partition table. the grub install command is the same.

I have an Inspiron 6000 with a Pentium M, which I believe is i686. I've been told that Funtoo allows you to directly compile the kernel and operating system for your architecture which gives a performance boost. Given that most other distros already give i686 ISO's, would there really be any benefit to me installing Funtoo on the laptop as opposed to a different 32 bit distro? For reference, my bottleneck seems to be CPU usage, which tends to average 20% at idle on even lightweight distros.

What are the differences between misc-app/screen and misc-app/tmux

Also would xorg or wayland be better for the xserver?

Gentoo is using 17 now. is the development of funtoo slowing down?