Howdy,

I tried a while back to upgrade my kernel but nvidia didn't like it. 
Given I can do this a piece at a time, I thought I'd try again.  Kernel compiled fine and when nvidia complained about missing options, I fixed
those and recompiled the kernel.  I finally got it happy as far as
missing kernel options goes.  Then it fails with this error. 


* Package:    x11-drivers/nvidia-drivers-470.182.03:0/470
 * Repository: mine
 * USE:        X abi_x86_64 amd64 driver elibc_glibc kernel_linux tools userland_GNU
 * FEATURES:   network-sandbox preserve-libs sandbox userpriv usersandbox  * Determining the location of the kernel source code
 * Found kernel source directory:
 *     /usr/src/linux
 * Found sources for kernel version:
 *     6.1.23-gentoo
 * Checking for suitable kernel configuration options ...
 [ ok ]

Unpacking source...
Unpacking NVIDIA-Linux-x86_64-470.182.03.run to /var/tmp/portage/x11-drivers/nvidia-drivers-470.182.03/work
Unpacking nvidia-installer-470.182.03.tar.bz2 to /var/tmp/portage/x11-drivers/nvidia-drivers-470.182.03/work
Unpacking nvidia-modprobe-470.182.03.tar.bz2 to /var/tmp/portage/x11-drivers/nvidia-drivers-470.182.03/work
Unpacking nvidia-persistenced-470.182.03.tar.bz2 to /var/tmp/portage/x11-drivers/nvidia-drivers-470.182.03/work
Unpacking nvidia-settings-470.182.03.tar.bz2 to /var/tmp/portage/x11-drivers/nvidia-drivers-470.182.03/work
Unpacking nvidia-xconfig-470.182.03.tar.bz2 to /var/tmp/portage/x11-drivers/nvidia-drivers-470.182.03/work
Source unpacked in /var/tmp/portage/x11-drivers/nvidia-drivers-470.182.03/work
Preparing source in /var/tmp/portage/x11-drivers/nvidia-drivers-470.182.03/work ...

 * Applying nvidia-drivers-470.141.03-clang15.patch ... /var/tmp/portage/x11-drivers/nvidia-drivers-470.182.03/temp/environment:
line 1291: /var/tmp/portage/x11-drivers/nvidia-drivers-470.182.03/files/nvidia-drivers-470.141.03-clang15.patch:
No such file or directory /var/tmp/portage/x11-drivers/nvidia-drivers-470.182.03/temp/environment:
line 1294: /var/tmp/portage/x11-drivers/nvidia-drivers-470.182.03/files/nvidia-drivers-470.141.03-clang15.patch:
No such file or directory
 [ !! ]
 * ERROR: x11-drivers/nvidia-drivers-470.182.03::mine failed (prepare
phase):
 *   patch -p1  failed with /var/tmp/portage/x11-drivers/nvidia-drivers-470.182.03/files/nvidia-drivers-470.141.03-clang15.patch
 *
 * Call stack:
 *               ebuild.sh, line  136:  Called src_prepare  *             environment, line 3731:  Called default  *      phase-functions.sh, line  872:  Called default_src_prepare  *      phase-functions.sh, line  948:  Called __eapi8_src_prepare  *             environment, line  468:  Called eapply '--' '/var/tmp/portage/x11-drivers/nvidia-drivers-470.182.03/files/nvidia-drivers-470.141.03-clang15.patch'
'/var/tmp/portage/x11-drivers/nvidia-drivers-470.182.03/files/nvidia-modprobe-390.141-uvm-perms.patch'
'/var/tmp/portage/x11-drivers/nvidia-drivers-470.182.03/files/nvidia-settings-390.144-desktop.patch'
'/var/tmp/portage/x11-drivers/nvidia-drivers-470.182.03/files/nvidia-settings-390.144-no-gtk2.patch'
'/var/tmp/portage/x11-drivers/nvidia-drivers-470.182.03/files/nvidia-settings-390.144-raw-ldflags.patch'
 *             environment, line 1359:  Called _eapply_patch '/var/tmp/portage/x11-drivers/nvidia-drivers-470.182.03/files/nvidia-drivers-470.141.03-clang15.patch'
 *             environment, line 1297:  Called __helpers_die 'patch -p1 
failed with /var/tmp/portage/x11-drivers/nvidia-drivers-470.182.03/files/nvidia-drivers-470.141.03-clang15.patch'
 *   isolated-functions.sh, line  112:  Called die
 * The specific snippet of code:
 *              die "$@"
 *


According to the nvidia website, I'm using the correct version.  Thing
is, it's old.  I may have to get a newer video card.  If I can correct
this error tho and it work when I reboot, it would be great.  I don't
think that driver version is in the tree anymore.  It shows it is in my
local overlay.  Given the next version of driver doesn't work with this
card, I may be stuck with current kernel version or buying a newer
card.  Do I need to switch to a different driver?  Novau or something? 

Any thoughts?  Ideas? 

Thanks. 

Dale

:-)  :-) 

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thu, Apr 20, 2023 at 3:36 PM Dale <rdalek1967@gmail.com> wrote:
<SNIP>

* patch -p1 failed with

/var/tmp/portage/x11-drivers/nvidia-drivers-470.182.03/files/nvidia-drivers-470.141.03-clang15.patch
<SNIP>

You know I don't run Gentoo, right?

That looks weird to me - building 470.182.03 but patching it with
470.141.03.
Just looks weird...

I think the other day someone - maybe Thelma? - had a problem
where there was something left over in some 'patch' directory.
Possibly you have something like that going on?

You know I don't run Gentoo, right? ;-)

Cheers,
Mark

<div dir="ltr"><br><br>On Thu, Apr 20, 2023 at 3:36 PM Dale &lt;<a href="mailto:rdalek1967@gmail.com">rdalek1967@gmail.com</a>&gt; wrote:<br>&lt;SNIP&gt;<br>&gt;  *   patch -p1  failed with<br>&gt; /var/tmp/portage/x11-drivers/nvidia-drivers-470.182.
03/files/nvidia-drivers-470.141.03-clang15.patch<br>&lt;SNIP&gt;<div><br></div><div>You know I don&#39;t run Gentoo, right?</div><div><br></div><div>That looks weird to me - building 470.182.03 but patching it with 470.141.03. </div><div>Just looks
weird...</div><div><br></div><div>I think the other day someone - maybe Thelma? - had a problem </div><div>where there was something left over in some &#39;patch&#39; directory. </div><div>Possibly you have something like that going on?</div><div><br></

<div>You know I don&#39;t run Gentoo, right? ;-)</div><div><br></div><div>Cheers,</div><div>Mark</div></div>

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2023-04-21 00:36, Dale wrote:

/var/tmp/portage/x11-drivers/nvidia-drivers-470.182.03/temp/environment:
line 1291: /var/tmp/portage/x11-drivers/nvidia-drivers-470.182.03/files/nvidia-drivers-470.141.03-clang15.patch:
No such file or directory

Any thoughts?  Ideas?

I couldn't reproduce the error here. One thing that comes to mind is that your system might have an error in its repository configuration. /var/tmp/portage/x11-drivers/nvidia-drivers-470.182.03/files is a symlink and should point to your main repository,
normally /var/db/repos/gentoo/x11-drivers/nvidia-drivers/files. When the emerge fails, can you check what that symlink actually points to and if this is where your repository is stored? What is the output of emerge --info? (Repository info is in that
output).

/Morgan

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Morgan Wesström wrote:

On 2023-04-21 00:36, Dale wrote:

/var/tmp/portage/x11-drivers/nvidia-drivers-470.182.03/temp/environment:
line 1291:
/var/tmp/portage/x11-drivers/nvidia-drivers-470.182.03/files/nvidia-drivers-470.141.03-clang15.patch:

No such file or directory

Any thoughts?  Ideas?

I couldn't reproduce the error here. One thing that comes to mind is
that your system might have an error in its repository configuration. /var/tmp/portage/x11-drivers/nvidia-drivers-470.182.03/files is a
symlink and should point to your main repository, normally /var/db/repos/gentoo/x11-drivers/nvidia-drivers/files. When the emerge
fails, can you check what that symlink actually points to and if this
is where your repository is stored? What is the output of emerge
--info? (Repository info is in that output).

/Morgan

I cleared the tmp files to give it a fresh start.  It still failed.  The directory and files it complains about being missing, they are.  I went
to the ebuild to see what patches are supposed to be installed.  This is
the part of the ebuild. 


PATCHES=(
    "${FILESDIR}"/nvidia-drivers-470.141.03-clang15.patch
    "${FILESDIR}"/nvidia-modprobe-390.141-uvm-perms.patch
    "${FILESDIR}"/nvidia-settings-390.144-desktop.patch
    "${FILESDIR}"/nvidia-settings-390.144-no-gtk2.patch
    "${FILESDIR}"/nvidia-settings-390.144-raw-ldflags.patch
)


As you can see, it wants to apply patches from several versions so while
odd, I guess it really does it that way.  I suspect given the age of the drivers that the patches no longer exist or something.  I'd think it
would report it couldn't download the files but maybe not.  I may be
running out of luck here.  Odd thing is, it compiled a while back. 

I tried to google and find the patch, no luck.  No idea where it comes
from.  May run emerge -ef nvidia-drivers and see if it works. 

Also, I switch to the current kernel, it failed in the same way.  It
isn't just the new kernel, it seems to be any of them.  I wonder how
hard it is to switch to that other driver.  From the wiki page, it looks
like a big deal. 

Dale

:-)  ;-)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Am Thu, Apr 20, 2023 at 08:33:22PM -0500 schrieb Dale:

I cleared the tmp files to give it a fresh start.  It still failed.  The directory and files it complains about being missing, they are.  I went
to the ebuild to see what patches are supposed to be installed.  This is
the part of the ebuild. 

PATCHES=(
    "${FILESDIR}"/nvidia-drivers-470.141.03-clang15.patch
    "${FILESDIR}"/nvidia-modprobe-390.141-uvm-perms.patch
    "${FILESDIR}"/nvidia-settings-390.144-desktop.patch
    "${FILESDIR}"/nvidia-settings-390.144-no-gtk2.patch
    "${FILESDIR}"/nvidia-settings-390.144-raw-ldflags.patch
)

As you can see, it wants to apply patches from several versions so while
odd, I guess it really does it that way.  I suspect given the age of the drivers that the patches no longer exist or something.  I'd think it
would report it couldn't download the files but maybe not.  I may be
running out of luck here.  Odd thing is, it compiled a while back. 

If I read your error output correctly, it’s not that the patch file is missing, but that a file that is mentioned inside the patch is.

--
Grüße | Greetings | Qapla’
Please do not share anything from, with or about me on any social network.

Error: this virus requires DirectX and 64 MB of RAM!

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEVbE9o2D2lE5fhoVsizG+tUDUMMoFAmRCOjoACgkQizG+tUDU MMrowg//adKHogwkG8qYDFJ30tqZScStlELyQONO5jg+ZwVF8pzDjo1r2V1tHQhv sVtSQtgfrVHJ8k8HQg7+KhJjKAlQYyCY8zIpy6hTYn16TMBSnd6TKyyPclnVjh9i FUOAdZb/BSbG0IXWeF7lf/g5wziInbyMwf1tEa4xaUf58GBonT47Ok9yB5YHNAE2 OIYuysr3qGfAocAkALlYMydkpxENHdEvMJ739kuT9uuDsH6RpPYpe7VSHnLu3FZ5 SDZyiO8BnmCg8u3iqgBEmkX73icmokH+o/K3vIk5JzSFAreT4oktRW34WSc6hQcG fJ5or//T6yoX+QzDjtDiQ3xU8cGNUBGctqYgDZ8WZWZWrZD/jMy6ioI9IhIQR0ad pbQE3fvEQ8udAzb7JLnXA1KBl9TgfDysNvMlIafE8X4Se9OIH1ogSCM49WdUoUPj sg/9PxjgZC9UC/sgIUpboT7QFsGtdlBAVp3JtvBrqTpbUnD2abvRTfYJfkeOLkqD OABoKDHCzeXSa+flBE90EtCDUE8/Ccbgfeu/uwd+89ZDpotnwJB/kS9SXjMfNCxf m0KcMf6uA7vCeRLb6nh7CDc/6w7n5ftOXT6oXbzHP9xAN1Ev7zd5oXc5PCVoL8Xt Wytkvc6jA0NU38l0UbcagxRoc/SK/Ibv7fc263I3hBPAUc3G468=
=K2If
-----END PGP SIGNATURE-----

--

Frank Steinmetzger wrote:

Am Thu, Apr 20, 2023 at 08:33:22PM -0500 schrieb Dale:

I cleared the tmp files to give it a fresh start.  It still failed.  The >> directory and files it complains about being missing, they are.  I went
to the ebuild to see what patches are supposed to be installed.  This is
the part of the ebuild. 


PATCHES=(
    "${FILESDIR}"/nvidia-drivers-470.141.03-clang15.patch
    "${FILESDIR}"/nvidia-modprobe-390.141-uvm-perms.patch
    "${FILESDIR}"/nvidia-settings-390.144-desktop.patch
    "${FILESDIR}"/nvidia-settings-390.144-no-gtk2.patch
    "${FILESDIR}"/nvidia-settings-390.144-raw-ldflags.patch
)


As you can see, it wants to apply patches from several versions so while
odd, I guess it really does it that way.  I suspect given the age of the
drivers that the patches no longer exist or something.  I'd think it
would report it couldn't download the files but maybe not.  I may be
running out of luck here.  Odd thing is, it compiled a while back. 

If I read your error output correctly, it’s not that the patch file is missing, but that a file that is mentioned inside the patch is.

Oh.  The output of emerge has always been sort of cryptic.  LOL  I just
hope nothing happens where I have to re-emerge it.  At this point, I'd
be in a pickle if the drivers failed and needed to be reinstalled. 

I did a emerge -ef nvidia-drivers and it still fails.  I was hoping that
would pick up the needed files.  Guess not.  I decided to do some more digging.  I noticed that the same version is still in the tree.  I
copied the ebuild a while back to a local overlay to make sure I don't
lose it.  It seems emerge gives my local overlay priority over the one
in the tree.  I renamed the ebuild in my overlay with .old tacked on. 
It emerges fine after that since it uses the ebuild in the tree.  It
seems my overlay is broken somehow.  Likely a design improvement.  ;-) 

I put my local ebuilds in /usr/local/portage.  Obviously emerge sees it
since it was trying to use it.  I don't understand why it doesn't work
tho.  I looked at the ebuild in the tree and my overlay, they look the
same, including the patches from different versions. 

Now I need to figure out why the overlay version isn't working.  I've
had occasion to need older versions before, due to some bug or
something.  Gonna see if it builds against the new kernel now.  Let us pray. 

Always something.  :/

Dale

:-)  :-) 

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Arve Barsnes wrote:

On Fri, 21 Apr 2023 at 10:58, Dale <rdalek1967@gmail.com> wrote:

I put my local ebuilds in /usr/local/portage. Obviously emerge sees it
since it was trying to use it. I don't understand why it doesn't work
tho. I looked at the ebuild in the tree and my overlay, they look the
same, including the patches from different versions.

Now I need to figure out why the overlay version isn't working. I've
had occasion to need older versions before, due to some bug or
something. Gonna see if it builds against the new kernel now. Let us
pray.

If your ebuild and the repo ebuild are the same, that means that the
patch was changed, look in your /usr/local/portage/x11-drivers/nvidia-drivers/files/ folder and
compare with the current files.

Regards,
Arve

Well, there's the problem.  There's no files directory there.  I ran the ebuild command when I added it to the overlay, I don't think it
downloaded anything.  I just copied the ebuild file from the Gentoo
tree.  If I ever need to emerge from the overlay, I hope it works now. 

Did something change with overlays?  In the past, I copied the ebuild
over to local overlay and ran the ebuild command for the manifest.  It downloaded everything that was needed.  Now, it seems it doesn't.  They
add a step?  I miss a step that slipped my mind? 

Dale

:-)  :-) 

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Fri, 21 Apr 2023 at 10:58, Dale <rdalek1967@gmail.com> wrote:

I put my local ebuilds in /usr/local/portage. Obviously emerge sees it
since it was trying to use it. I don't understand why it doesn't work
tho. I looked at the ebuild in the tree and my overlay, they look the
same, including the patches from different versions.

Now I need to figure out why the overlay version isn't working. I've
had occasion to need older versions before, due to some bug or
something. Gonna see if it builds against the new kernel now. Let us
pray.

If your ebuild and the repo ebuild are the same, that means that the
patch was changed, look in your /usr/local/portage/x11-drivers/nvidia-drivers/files/ folder and
compare with the current files.

Regards,
Arve

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Fri, 21 Apr 2023 at 11:55, Dale <rdalek1967@gmail.com> wrote:

Did something change with overlays? In the past, I copied the ebuild
over to local overlay and ran the ebuild command for the manifest. It downloaded everything that was needed. Now, it seems it doesn't. They
add a step? I miss a step that slipped my mind?

I don't think the files/ directory contents were ever downloaded by
the ebuilds, they are a part of the portage tree, so they appear when
you sync. Maybe the files/ contents from the main tree were available
for your overlay ebuild somehow? I've never had that luxury, so now
I*m wondering how your ebuild ever worked :-)

Regards,
Arve

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Dale,

On Thursday, 2023-04-20 17:36:23 -0500, you wrote:

...
* Package:    x11-drivers/nvidia-drivers-470.182.03:0/470
 * Repository: mine

Maybe I'm missing something, but as of today "x11-drivers/nvidia-dri-
vers" version 470.182.03 is still in the normal Gentoo tree. So why use
your personal repo? Do you have a local patch applied?

Sincerely,
Rainer

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thu, Apr 20, 2023 at 05:36:23PM -0500, Dale wrote:

/var/tmp/portage/x11-drivers/nvidia-drivers-470.182.03/files/nvidia-drivers-470.141.03-clang15.patch:
No such file or directory

This sounds like you copied the ebuild to your local overlay but not
the files/ dir which includes the patch. So the patch is not found.

this error tho and it work when I reboot, it would be great.  I don't
think that driver version is in the tree anymore.  It shows it is in my local overlay.

It is in the tree, 470.x is a long-term-support branch and as long as
NVIDIA continue to support it there's no reason to drop it from the
tree. Just use the ::gentoo version.

470.182.03 is even fairly recent, was a security release added to the
tree last month followed by the cleanup of the vulnerable 470.161.03.

https://packages.gentoo.org/packages/x11-drivers/nvidia-drivers

--
ionen

-----BEGIN PGP SIGNATURE-----

iQEzBAABCAAdFiEEx3SLh1HBoPy/yLVYskQGsLCsQzQFAmRCcdQACgkQskQGsLCs QzQY7AgAk+lYcL24Q9UaPbEVHbqKloueLQTG/srVC5u5qPEvRbWcnad9Y7VqO6Wd qKzU/4wOfAdi8Ivk9zjfBsfyaGRv55HMwdACIxGuiNQW6QJiBz6AHFtadC6oAIao vh+/HeZoOgc7EZnBL3DSl2ERt916IxWo0DJ1ykMn8ircS3fKYOkYinwS2fCw9Rwz ZjqhErlX8tJzhJLa3a7ONG73EtgnRu3fSj4Mhm444fWpE+oRcrZ6WCuxL1YZbgwF QiYIjLMe2RxnL3EoyYOWgYuXhipHV4f0/Mr68F7WQKRLcXTy+yA/422nUlXcHBdF U9EeBfMOCfgjj6pJmf/jOJr4oEkmnQ==
=qiLI
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Fri, 21 Apr 2023 03:58:11 -0500, Dale wrote:

I did a emerge -ef nvidia-drivers and it still fails.  I was hoping that would pick up the needed files.  Guess not.  I decided to do some more digging.  I noticed that the same version is still in the tree.  I
copied the ebuild a while back to a local overlay to make sure I don't
lose it.  It seems emerge gives my local overlay priority over the one
in the tree.  I renamed the ebuild in my overlay with .old tacked on. 
It emerges fine after that since it uses the ebuild in the tree.  It
seems my overlay is broken somehow.  Likely a design improvement.  ;-) 

That's the default by design. If you copy an ebuild to your overlay, it's usually because you want to make changes to it, so it should be given
priority. You can change the priority of overlays in
/etc/portage/repos.conf, or you can simply mask the overlay version.


--
Neil Bothwick

Dream as if you'll live forever. Live as if you'll die today.

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEGfLZTV7dXdQXh/dDdCdyyQfftocFAmRCj34ACgkQdCdyyQff tocjqw//fcYi6u7w11+OEOaZXfsQ7kALAKB1oERuniQFuI3foePlloBjjJj5FNxh dlnmZyW3HQ8+1N1KDWyogFUjp5g0O/lZsIaevUSwkRASGt81KTMBS6I+vXJj8NIk kzJ1VZIuyEYBoeIZKav9fXHvT5LZarC79eZ/Nb9wNM5+zDjiInoU7Fw5wQ1zxPJR qqadGAlGfcLOJFujH+Iy8ElyCPrrDdCgQ9TEn8lvxnOqZuxn/HwUfOu8azig+8Fw A67zL7N+2IXKV8sdP9ykFEXlarxHsHJzrmWPGaDhu6U8coWXkLjoMW4trxwWb7Ff KOdGhsniyYmnSgAihae8CpBO7YpRrcAJHuX0J7GAxkc11g7Z6azv2tnruLpZyIGA XoYdJMnEnJzH+twYNUtzSOM0kRKo2CFwGxXBXKWBB/4NyALa3TrzXOUzA6k1N7CN Ufw/x7nAf9OLquvKLnHx8vNQVZvT/MxJrSK3/2FMU/0OhaMJIMYqQmfVDetKO6mi xZkYH5Ds1WYniB04tZwcfq2276pOb4yeKh4dM9pvY+0vMxOINDcxWuYJnmUP+6Yf fWjQuaBdglfPsJRiv2jdcO2DQxe1SmS5LXsivIqkvvSjzFcc8IWwvA7Kr2nag67u FVt1Gw+mIqF27MdwbtMntuUfgCX0t/jxI+WjZizKPHzHcKoTjtk=
=4Rb0
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thu, 20 Apr 2023 20:33:22 -0500, Dale wrote:

Also, I switch to the current kernel, it failed in the same way.  It
isn't just the new kernel, it seems to be any of them.  I wonder how
hard it is to switch to that other driver.  From the wiki page, it looks like a big deal. 

Not really, AFAIR. You just enable nouveau drivers in your kernel config, uninstall the nvidia package and reboot. This assumes you haven't got any direct references to the nvisia driver in /etc/xorg.conf*.


--
Neil Bothwick

New sig wanted good price paid.

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEGfLZTV7dXdQXh/dDdCdyyQfftocFAmRCj+IACgkQdCdyyQff toeNRQ//YyrKivcroAewpttYr5feSIKxDzez66Eo63L2P/FTK7xT1igqqpnSNeU3 JHvscvA6G0FiKom8VeorxkaEyB7fwtZ6hdDGYrikvHBw3YKAbGYRM1ZsBxjAu6cQ xcYkXEoQbEGzaL6IXsmRqA0+u9JwbCXZCMucnHKbPaSGmqPDozd4m0XBC5SC4kc0 hxdSXfXgiJCSBeC+9hZNap1PVLa4EXrDmGhmCm37KQD5L7qR1qbaXD2AFTaTQpEc +i23idFQRWBumMagIEsmr4RqyF45glcEbwnk/fuieR4d0A2IyMX2W0fGY4lom5+q qEqwwh1m028smR3F1aQqEvIMyywY+VZ8Csq6mKQCIhByLqmqZzvOOgGB9EWpxqjh XezeV726yyMQ8hw5Z8bm1aha4BX3J1iGgm/c0i3GNoEHmUDE8jnDx1g5CBEo+55C ng5cOlO856XzRbCO5eGMegiwgEJw/jEABmINHTmxbUqI6AiOLR6Qu+JTVWr0n+M1 bk6uy7bGNeMEZyspA+teCKupAj/6PnpLD/a6ieHpZ4cnLTZH87WG53vSPg8TZkbe HSSQps1UPRc0F1qoEdfylorHivSwr/Im7vJryrpEtACpI2IZDij8xuoqVD8xdkyD 3hsFvaDd8fRUim8b3ZQuN2vJIi9rSU0ev1JtRR8ZfYFJpiRNXfI=
=vm3Q
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Neil Bothwick wrote:

On Thu, 20 Apr 2023 20:33:22 -0500, Dale wrote:

Also, I switch to the current kernel, it failed in the same way.  It
isn't just the new kernel, it seems to be any of them.  I wonder how
hard it is to switch to that other driver.  From the wiki page, it looks
like a big deal. 

Not really, AFAIR. You just enable nouveau drivers in your kernel config, uninstall the nvidia package and reboot. This assumes you haven't got any direct references to the nvisia driver in /etc/xorg.conf*.

I think, pretty much certain, I have it set to nvidia in xorg.conf. 
This is a old install.  If I recall correctly, I have to change that. 
Also, I'd need to edit make.conf I think.  I read the wiki thingy a few times.  It's mostly undoing things but with the age of this install, I
don't think my old way is the new way.  Yep.  I'm getting better at
grep.  lol

root@fireball / # cat /etc/X11/xorg.conf | grep driver
    Driver         "mouse"
    Driver         "kbd"
    Driver         "nvidia"
root@fireball / #cat /etc/make.conf | grep video_cards
VIDEO_CARDS="nvidia vesa"
root@fireball / #

I think I'd have to change those.  It may or may not rebuild some
packages.  Would I need to leave out vesa or OK to leave it in?

The easiest part, enable in kernel and build it.  With your nifty dracut command option, it just works. LOL  By the way, the nvidia-driver
package compiled fine against the new kernel.

I may be into to much today to play with this tho.  Maybe late today.  Tomorrow depending on weather. 

Next time I copy a ebuild to a local overlay, I need to remember to copy
any files directory over too.  I don't recall ever doing that before. 

Thanks to all.  Gotta do some things so may reply to others later. 

Dale

:-)  :-) 

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

This is a multi-part message in MIME format.
Neil Bothwick wrote:

On Fri, 21 Apr 2023 03:58:11 -0500, Dale wrote:

I did a emerge -ef nvidia-drivers and it still fails.  I was hoping that
would pick up the needed files.  Guess not.  I decided to do some more
digging.  I noticed that the same version is still in the tree.  I
copied the ebuild a while back to a local overlay to make sure I don't
lose it.  It seems emerge gives my local overlay priority over the one
in the tree.  I renamed the ebuild in my overlay with .old tacked on. 
It emerges fine after that since it uses the ebuild in the tree.  It
seems my overlay is broken somehow.  Likely a design improvement.  ;-) 

That's the default by design. If you copy an ebuild to your overlay, it's usually because you want to make changes to it, so it should be given priority. You can change the priority of overlays in
/etc/portage/repos.conf, or you can simply mask the overlay version.

Found the needed info on the wiki and added the priority setting.  I
added "priority=100" which should work right?  It will use the Gentoo
tree first and then mine?  That's my reading of the wiki page anyway. 

Thanks.

Dale

:-)  :-) 

<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">Neil Bothwick wrote:<br>
</div>
<blockquote type="cite"
cite="mid:20230421142830.13f35336@digimed.co.uk">
<pre class="moz-quote-pre" wrap="">On Fri, 21 Apr 2023 03:58:11 -0500, Dale wrote:

</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">I did a emerge -ef nvidia-drivers and it still fails.  I was hoping that
would pick up the needed files.  Guess not.  I decided to do some more digging.  I noticed that the same version is still in the tree.  I
copied the ebuild a while back to a local overlay to make sure I don't
lose it.  It seems emerge gives my local overlay priority over the one
in the tree.  I renamed the ebuild in my overlay with .old tacked on. 
It emerges fine after that since it uses the ebuild in the tree.  It
seems my overlay is broken somehow.  Likely a design improvement.  ;-)  </pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
That's the default by design. If you copy an ebuild to your overlay, it's usually because you want to make changes to it, so it should be given
priority. You can change the priority of overlays in
/etc/portage/repos.conf, or you can simply mask the overlay version.


</pre>
</blockquote>
<br>
Found the needed info on the wiki and added the priority setting.  I
added "<span class="na">priority</span><span class="w"> </span><span
class="o">=</span><span class="w"> </span><span class="s">100"
which should work right?  It will use the Gentoo tree first and
then mine?  That's my reading of the wiki page anyway.  <br>
<br>
Thanks.<br>
<br>
Dale <br>
<br>
:-)  :-)  <br>
</span>
</body>
</html>

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Dr Rainer Woitok wrote:

Dale,

On Thursday, 2023-04-20 17:36:23 -0500, you wrote:

...
* Package:    x11-drivers/nvidia-drivers-470.182.03:0/470
 * Repository: mine

Maybe I'm missing something, but as of today "x11-drivers/nvidia-dri- vers" version 470.182.03 is still in the normal Gentoo tree. So why use
your personal repo? Do you have a local patch applied?

Sincerely,
Rainer
.

I ran into a buggy driver a while back and once I synced and upgraded,
the old one was gone.  So, I started keeping a local copy just in case. 
Of course, as long as I keep a older driver to fall back on, it won't
break anymore.  As soon as I miss one tho, problems.  LOL 

Thanks to you and Ionen.

Dale

:-)  :-) 

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Fri, 21 Apr 2023 09:55:24 -0500, Dale wrote:

Also, I switch to the current kernel, it failed in the same way.  It
isn't just the new kernel, it seems to be any of them.  I wonder how
hard it is to switch to that other driver.  From the wiki page, it
looks like a big deal. 

Not really, AFAIR. You just enable nouveau drivers in your kernel
config, uninstall the nvidia package and reboot. This assumes you
haven't got any direct references to the nvisia driver in
/etc/xorg.conf*.

I think, pretty much certain, I have it set to nvidia in xorg.conf. 
This is a old install.  If I recall correctly, I have to change that.  Also, I'd need to edit make.conf I think.  I read the wiki thingy a few times.  It's mostly undoing things but with the age of this install, I
don't think my old way is the new way.  Yep.  I'm getting better at
grep.  lol

root@fireball / # cat /etc/X11/xorg.conf | grep driver
    Driver         "mouse"
    Driver         "kbd"
    Driver         "nvidia"

xorg.conf is often unnecessary these days. I only have a file in
xorg.conf.d to switch the buttons on my trackball.

root@fireball / #cat /etc/make.conf | grep video_cards
VIDEO_CARDS="nvidia vesa"
root@fireball / #

I think I'd have to change those.  It may or may not rebuild some packages.  Would I need to leave out vesa or OK to leave it in?

You'll need to replace nvidia with nouveau here, leave in vesa as a
fallback.

The worst that can happen is that X fails to start and you need to
re-emerge the nvidia drivers, which you quickpkg'd of course.


--
Neil Bothwick

This is as bad as it can get; but don't bet on it.

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEGfLZTV7dXdQXh/dDdCdyyQfftocFAmRC2lEACgkQdCdyyQff tofLpg/7BfxD3cSFk/gTir5ArpaoE0SQTyX5MHu40Fx4LsISDSEoupBuNqqTd94z 21ZNmvgTW07rwhC8bejPCXEP4v27G1i4dsT5ZrfbVb/hsqzE5lqQbiudtHEtXJu2 npkqJBWmWyZoHrAKolMt+Q54a9WtM7wCGxCYt6kgE6JcLjBrwe78/UqMchkeGVwR wuSTbQQ6VPV34wBNh7s8h/tFwJxhEkDeby+VqVyUKizPbn1OgS4wIabwMpTTxWkg ewnsKbGuPBqlkdAFpynfASgndfhgVS7tkSVetiuPyugUo1IaYZWgWZW0M3hlrFJ3 vOh2SCBXaGLNLG24EnukX+XVpqC6r1NO79JlDb0E+H5lIPp06AUOif3oxjb8tolj 5C95ouJ/J3G05lheZQIOV9UEqlJwDwYJqTzrjM8zvGDXPis1g3kugqbfopXfKJZe G/fSr9OqyAnwC6slJj+JMkYcqvUa0cEK4Dz1UWsx6R6rv+3J556gEhg2Du0Vfmd2 52PekaRkZ+6GSB7IylBrgDFDBj1EVp6qEzOTcz5P7D2Z9d7Oo2g+0bFsMaPWwR28 cv1/vBiuH/5026tvF+Njjt/OXtMtVCOJPEHHg8VxKAC+r/hiFCgKaQx3GTLc+aW2 uUQHpXz5+8ET+xNM80C4r2/Gb3lUVbPPLuRqE5+oGTKWXADGNU0=
=BC+E
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Neil Bothwick wrote:

On Fri, 21 Apr 2023 09:55:24 -0500, Dale wrote:

Also, I switch to the current kernel, it failed in the same way.  It
isn't just the new kernel, it seems to be any of them.  I wonder how
hard it is to switch to that other driver.  From the wiki page, it
looks like a big deal. 

Not really, AFAIR. You just enable nouveau drivers in your kernel
config, uninstall the nvidia package and reboot. This assumes you
haven't got any direct references to the nvisia driver in
/etc/xorg.conf*.

I think, pretty much certain, I have it set to nvidia in xorg.conf. 
This is a old install.  If I recall correctly, I have to change that. 
Also, I'd need to edit make.conf I think.  I read the wiki thingy a few
times.  It's mostly undoing things but with the age of this install, I
don't think my old way is the new way.  Yep.  I'm getting better at
grep.  lol

root@fireball / # cat /etc/X11/xorg.conf | grep driver
    Driver         "mouse"
    Driver         "kbd"
    Driver         "nvidia"

xorg.conf is often unnecessary these days. I only have a file in
xorg.conf.d to switch the buttons on my trackball.

I thought I read that somewhere.  This is a old install tho.  A decade
or so.  To be honest tho, I'd like to configure my 2nd screen in the
conf file.  As it is, I have it set up within KDE itself I think.  When
I kill the X part, the 2nd screen dies since KDE and friends isn't
running.  I just haven't had the nerve to do it yet.  I can't even be
sure how it is done nowadays.  I think nvidia has a command that does it. 

root@fireball / #cat /etc/make.conf | grep video_cards
VIDEO_CARDS="nvidia vesa"
root@fireball / #

I think I'd have to change those.  It may or may not rebuild some
packages.  Would I need to leave out vesa or OK to leave it in?

You'll need to replace nvidia with nouveau here, leave in vesa as a
fallback.

The worst that can happen is that X fails to start and you need to
re-emerge the nvidia drivers, which you quickpkg'd of course.

Back when I was using Mandrake, I actually wrote a step by step guide to installing the video drivers and did it a way that even a noobie could
follow it.  That was back in the mid 2000's tho.  It was on Linux
Questions I think.  That thing had tons of views and lots of grateful
users.  I thought I had to change that and the one in the xorg.conf file too.  The big one when rebooting is the xorg file tho.  I just wasn't
sure if something had changed. 

I looked at a Nvidia GTX 1050 video card.  May be good for starting to accumulate parts for new rig.  Anyway, it has a weird set of outputs.  I
need two HDMI, or three, for mine.  My current monitor will take either
DB15HD or HDMI.  My TV ports are HDMI.  I kinda like everything else
about it except the outputs.  I may have to dig further. 

Dale

:-)  :-)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 21/04/2023 19:29, Dale wrote:

I ran into a buggy driver a while back and once I synced and upgraded,
the old one was gone.  So, I started keeping a local copy just in case.
Of course, as long as I keep a older driver to fall back on, it won't
break anymore.

It will break with kernel and x.org upgrades. NVidia still updates the
legacy drivers from time to time to support new kernel and x.org versions.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Nikos Chantziaras wrote:

On 21/04/2023 19:29, Dale wrote:

I ran into a buggy driver a while back and once I synced and upgraded,
the old one was gone.  So, I started keeping a local copy just in case.
Of course, as long as I keep a older driver to fall back on, it won't
break anymore.

It will break with kernel and x.org upgrades. NVidia still updates the
legacy drivers from time to time to support new kernel and x.org
versions.

I don't update kernels that often.  Other than nvidia updating, I don't
have to reinstall them very often.  Maybe I'm lucky on this one??? 
Still, that buggy driver caused me some grief.  I like to have at least
one option available.  Just going back a version is usually enough,
since it worked before.  ;-)

Dale

:-)  :-) 

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)