bcowan

should be fixed in tree now

yes, thanks for the catch, a PR has been submitted 🙂

I just want to say that gentoo-sources, that is not the LTS version which is currently 4.19 series, is basically mainline and all sorts of bad things can happen or regressions/corruptions/data loss is at a much greater percentage of being introduced. Breakage of nvidia-drivers/modules being a big one. Also you're following a kernel series that *will* be updated at least once a week if not more.Other patchsets have much better hardware support, backporting, bugfixes, and out of tree inclusions that really make the quality of life better all around for a normal linux user. Just my two cents.

The zfs flag is only useful if you're building the binary debian-sources{lts} ebuild as it enables support in the initramfs of genkernel nothing more.

bug FL-6683 https://bugs.funtoo.org/browse/FL-6683

Yeah, might be a good idea to file an improvement request to add to profiles. If you're not using any type of LUKS or encrypted root or home etc, you could always add -static to cryptsetup in package.use. Maybe a cool idea to add a new mix-in for all this, to go along with the documentation that needs upgraded 🙂 There is an open bug for this maybe I'll add to it.

What is your startx actually starting?

I pushed a PR to drobbins, should be hitting the main tree anytime with latest 390.129 nvidia-drivers and nvidia-kernel-modules. This has fixes for latest 5.2.x kernels 🙂

Can you check /etc/boot.conf and make sure that if nomodeset is there you remove it and re-run ego boot update, then reboot.

I just checked on a fresh container of 1.4 and on my main machine as normal user and root. shopt shows progcomp on in all cases

For now you can use the 390.129 in my overlay: https://github.com/bradlyatc/funtoo-overlay/tree/master/x11-drivers

get rid of the nomodeset in /etc/boot.conf re-run ego boot update and reboot.....see if that helps

Most probably the ebuild needs a version bump to 390.129 to build with 5.2 kernels, I bumped and tested here, all built, but I do not have nvidia hardware to test actual quality.

This is now fixed on 1.3 and confirmed. I just tested on a clean container.

This was just fixed in 1.4, will report a bug for 1.3. I personally would recommend installing 1.4 funtoo release as it has been tested very thoroughly now and will be a much better experience at this point 🙂

You should look into the Panfrost drivers for mesa that are being mainlined and mainline support in 5.3 kernels and above for odroid-n2 boards. Exciting times for Mali bifrost graphics. No more binary blobs with proper opensource drivers 🙂

I filed a bug for this, https://bugs.funtoo.org/browse/FL-6664 it should be fixed now.

It is fine to use generic arch, if that is what you *really* want shrug. If you do want generic then you need to add -custom-cflags to USE or package.use for debian-sources-lts

Just saw this and it reminded me of this post https://opensource.com/article/19/9/linux-terminal-colors

We used to let portage handle these moves transparently using profiles/updates. I don't know if that's still the case.

coreutils installs certain system files like /etc/DIR_COLORS and /etc/profile calls /etc/bash/bashrc which sources those colors and sets them.Also sources term files installed by ncurses for term capability etc.

Or its possible you're thinking of needing a multi{arch,lib} setup for funtoo which is not available for any arch ATM. Options are setting up a chroot environment, qemu/kvm/vm, or containers ( LXC, LXD, docker ).

What exactly do you mean by this? Aarch32 is backwards compatible with Aarch64 and should just work. Maybe you are missing support in your kernel for 32-bit ELO?

For some reason doing anything with perl before @world update seems to mess up the dep graph.

Please try without --exclude dev-lang/perl