bcowan
-
Posts
68 -
Joined
-
Last visited
-
Days Won
6
Content Type
Profiles
Forums
Blogs
Posts posted by bcowan
-
-
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.
-
-
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.
-
-
Just saw this and it reminded me of this post
-
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
Debian-sources fails to emerge
in Installation Help
Posted
should be fixed in tree now