[gentoo-user] Manifest verification failed
I'm trying "emerge --sync" (few times) but I get this error: !!! Manifest verification failed: OpenPGP verification failed: gpg: Signature made Sat 22 Apr 2023 04:39:56 AM UTC gpg:using RSA key E1D6ABB63BFCFB4BA02FDF1CEC590EEAC9189250 gpg: Can't check signature: No public key Action: sync for repo: gentoo, returned code = 1 GENTOO_MIRRORS="http://mirror.csclub.uwaterloo.ca/gentoo-distfiles/ http://gentoo.osuosl.org/ ftp://mirror.csclub.uwaterloo.ca/gentoo-distfiles/ http://linux.rz.ruhr-uni-bochum.de/download/gentoo-mirror/ ftp://linux.rz.ruhr-uni-bochum.de/gentoo-mirror/ ftp://ftp.spline.inf.fu-berlin.de/mirrors/gentoo/ http://ftp.spline.inf.fu-berlin.de/mirrors/gentoo/; -- Thelma
Re: [gentoo-user] Another week without chromium.
Neil Bothwick wrote: On Fri, 21 Apr 2023 13:03:51 -0400, Alan Grimes wrote: I've already pruned everything sus out of my home directory... I'm at a total loss.. This is insane at this point!!! I've been updating my system daily hoping that this will be fixed upstream... =( Have you tried as a different user, or with --user-data-dir pointing to an empty directory, to ignore all your current configurations. It may be an extension causing this, a core problem with chromium is likely to have gained attention very quickly. I tried --user-data-dir, I guess the syntax is non-obvious, it did not appear to do anything, I gave it ~/temp/chromium as a parameter. I deleted the preferences file and tried to open settings, this is what happens for __ALL__ pages including about:blank. HA! just had the idea of taking my .config/chromium directory and renaming it to chromium.old, damn thing still crashed with a blank config directory. I also deleted a bunch of stuff that looked like it could be an extension or thing that could cause problems... With only one tab open, the rate at which it created dump files increased to about 1,500 in the space of time it took to create this screenshot. I'm baffled as to how profoundly broken this appears to be, I mean if I were hired to write code for somenoe (which is something that will never happen but I can dream can't I?) I would do sanity checks, I'd make sure that it was always possible to trace effects back to causes... I'd say to myself this is production code so therefore I'd front-load my code path with sanity checks so that I would know for certain that all of my pre-conditions are satisfied before moving forward. Look at how smug this error message is anyway, it assumes that the problem is external to chromium and it basically ammounts to "jiggle the handle, it will work". Well, no it is not working and I am put in the position where I need to diagnose WHY it doesn't work and the "learn more button" is either errored out itself or is circular with this page. How do I even read the .dmp files it spews out anyway? is there actually any useful information in them? Furthermore, lets assume the most junked up crufty directory that has been in use since I first installed chromium (which is basically the case at hand but well...) Now you have done ??? that breaks this badly given an old working config from a fairly recent version. 1. HOW IN GOD'S NAME DID YOU EVEN BREAK IT THIS BAD EVEN IF YOU TRIED??? 2. Why isn't there basic filtering for known classes of things in old configs that are not kosher anymore. 3. WHY IN GOD'S NAME IS YOUR SOFTWARE THIS FRAGILE WRT THINGS THAT COULD BE IN THE USER'S HOME DIRECTORY -- Beware of Zombies. =O #EggCrisis #BlackWinter White is the new Kulak. Powers are not rights.
Re: [gentoo-user] How to install Ruby bindings in an ebuild
* Michael Orlitzky:
> The eclass sets S=$WORKDIR at first because it creates a separate
> source tree for each version of ruby that will be built for. [...]
Hm. While that sounds useful for "full Ruby" ebuilds, I don't see how to
circumvent the impact for the particular ebuild I am trying to extend,
other than overriding S in src_compile() etc.
The build needs to create a C shared library, Python bindings, and now
an additional shared library containing the Ruby bindings. Might this be
a case where a new, separate ebuild for the Ruby bindings would be a
better option than expanding the existing build?
> That uses the currently-eselected version of ruby to determine the
> path though.
I thought of that and tried to use ${RUBY} instead, but the variable was
empty. Hence I use the literal 'ruby' as a workaround, until a better
method comes to mind.
-Ralph
Re: [gentoo-user] How to install Ruby bindings in an ebuild
On Fri, 2023-04-21 at 09:16 +0200, Ralph Seichter wrote:
>
> I tried what you suggested. However, inheriting from ruby-ng.eclass
> introduces an odd problem: For some reason unknown to me, "${S}" no
> longer matches the default value of "${WORKDIR}/${P}", but only what I'd
> expect in "${WORKDIR}".
The eclass sets S=$WORKDIR at first because it creates a separate
source tree for each version of ruby that will be built for. For
example, you might have both $WORKDIR/ruby27 and $WORKDIR/ruby28. Later
on in the each_ruby_foo phases, $S will point to one of those, so it
should look more like what you're expecting.
> library something.so needs to be installed. Right now, I changed to
> this:
>
> local p=$(ruby -e 'puts $LOAD_PATH' | grep 'vendor.\+linux')
> [[ -d "${p}" ]] || die "'${p}' is not a directory"
> exeinto "${p}"
>
> Not very pretty either, but at least this avoids any hardcoded
> directories.
>
That uses the currently-eselected version of ruby to determine the path
though. If you eselect another version, or if you update the current
one, the bindings will stop working.
It may still not be worth the effort, but I'd keep that in mind when
updating ruby.
Re: [gentoo-user] Nvidia-drivers fails to patch
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 :-) :-)
Re: [gentoo-user] Another week without chromium.
On Fri, 21 Apr 2023 13:03:51 -0400, Alan Grimes wrote: > I've already pruned everything sus out of my home directory... I'm at a > total loss.. This is insane at this point!!! I've been updating my > system daily hoping that this will be fixed upstream... =( > Have you tried as a different user, or with --user-data-dir pointing to an empty directory, to ignore all your current configurations. It may be an extension causing this, a core problem with chromium is likely to have gained attention very quickly. -- Neil Bothwick Top Oxymorons Number 42: Airline Food pgpmNy_34EYjO.pgp Description: OpenPGP digital signature
Re: [gentoo-user] Nvidia-drivers fails to patch
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. pgp76AGQEPv1X.pgp Description: OpenPGP digital signature
Re: [gentoo-user] Can I safely switch (no)multilib profile???
Le 21/04/23 à 18:26, Dr Rainer Woitok a tapoté :
> Skimming farther upward reveals the string "x86_64" being derived
> in line "33:" from environment variable "ARCH" which is defined
> in my shell initialization scripts:
>
>export ARCH=$({ arch || uname -m || echo unknown ; } 2> /dev/null)
You should open a bug to explain that ARCH variable is already defined
in your shell environment. As a consequence the results on the following
commands are different :
> $ ARCH=x86_64 portageq envvar ARCH
> x86_64
> $ portageq envvar ARCH
> amd64
An this finally leads to eselect failure in some cases :
> $ ARCH=x86_64 eselect profile list
> !!! Error: Failed to get a list of valid profiles
> exiting
[gentoo-user] Another week without chromium.
I've mostly been living on my *cough* windows gaming machine because chromium STILL spams "Error 11" in all tabs. A 30 second test dumped bout 415 crash dumps to the log folder. =\ Has ANYONE gotten a handle on this error yet? Any idea what package causes it? Chromium seems very self-contained... Is it some funky interraction with this kernel version? That hardly seems plausible... =\ I've already pruned everything sus out of my home directory... I'm at a total loss.. This is insane at this point!!! I've been updating my system daily hoping that this will be fixed upstream... =( atg@tortoise ~ $ uname -a Linux tortoise 6.2.9 #2 SMP PREEMPT_DYNAMIC Mon Apr 3 09:22:43 EDT 2023 x86_64 AMD Ryzen Threadripper 3960X 24-Core Processor AuthenticAMD GNU/Linux atg@tortoise ~ $ -- Beware of Zombies. =O #EggCrisis #BlackWinter White is the new Kulak. Powers are not rights.
Re: [gentoo-user] Nvidia-drivers fails to patch
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 :-) :-)
Re: [gentoo-user] Can I safely switch (no)multilib profile???
Netfab,
On Friday, 2023-04-21 14:43:32 +0200, you wrote:
> ...
> I do not see anything particular in your emerge --info.
> What is your eselect version ?
> > $ eselect --version
$ eselect --version
eselect 1.4.20
Copyright (c) 2005-2020 Gentoo Authors.
Distributed under the terms of the GNU GPL version 2 or later.
$
> You can get bash debug output by running the following :
> > $ bash -x /usr/bin/eselect profile list 2> /tmp/debug.log
Oops, I didn't know or expect "eselect" to be a Bash script. Otherwise
I would have done this already :-)
I've appended the trace output at the end. This sure revealed the pro-
blem: skimming upward from the call to "die" in line ">196:" one can see
the script trying in line ">>>129:" to extract lines matching "^x86_64"
from "/var/db/repos/gentoo/profiles/profiles.desc". However, there are
none. Skimming farther upward reveals the string "x86_64" being derived
in line "33:" from environment variable "ARCH" which is defined in
my shell initialization scripts:
export ARCH=$({ arch || uname -m || echo unknown ; } 2> /dev/null)
But the only architectures supported by my "profiles.desc" file are:
$ gawk '! /^#|^$/ { print $1 }
' /var/db/repos/gentoo/profiles/profiles.desc | sort -u
alpha
amd64
amd64-linux
arm
arm-linux
arm64
arm64-linux
arm64-macos
hppa
ia64
loong
m68k
mips
ppc
ppc-macos
ppc64
ppc64-linux
riscv
riscv-linux
s390
sparc
sparc-solaris
sparc64-solaris
x64-cygwin
x64-macos
x64-solaris
x64-winnt
x86
x86-linux
x86-solaris
x86-winnt
$
So what is causing this? Why is environment variable "ARCH" expected to
have a value different from "$(arch)"? In fact, running
$ ARCH= eselect profile list
[1] default/linux/amd64/17.1 (stable)
...
[35] default/linux/amd64/17.0/musl/hardened/selinux (exp)
$
succeeds, which is slightly puzzling, at least for me :-/
But if that's the way it has to be, I can live with it by just setting my
"eselect" alias to "eselect='ARCH= eselect --color=no'", which works.
In any case thanks for your time and effort :-)
Sincerely,
Rainer
And here's the complete trace output:
$ PS4='>$LINENO: ' bash -x /usr/bin/eselect profile list
>20: ESELECT_DATA_PATH=/usr/share/eselect
>23: ESELECT_DEFAULT_MODULES_PATH=/usr/share/eselect/modules
>28: ESELECT_MODULES_PATH=("${HOME}/.eselect/modules"
"${ESELECT_DEFAULT_MODULES_PATH}")
>31: ESELECT_CORE_PATH=/usr/share/eselect/libs
>34: ESELECT_DEFAULT_ACTIONS=/usr/share/eselect/libs/default.eselect
>37: ESELECT_PROGRAM_NAME=eselect
>38: ESELECT_VERSION=1.4.20
>41: ESELECT_BINARY_NAME=/usr/bin/eselect
>42: ESELECT_KILL_TARGET=22018
>45: EPREFIX=
>46: EROOT=
>50: unalias -a
>51: unset -f rm
>52: unset CDPATH GLOBIGNORE
>53: IFS='
'
>55: shopt -s extglob
>56: shopt -s expand_aliases
>58: umask +rx
>61: (( BASH_VERSINFO[0] == 4 && BASH_VERSINFO[1] >= 1 || BASH_VERSINFO[0]
> 4 ))
>63: exec
>67: source /usr/share/eselect/libs/core.bash
>69: inherit manip output path-manipulation tests
>113: local x
>114: for x in "$@"
>115: [[ -e /usr/share/eselect/libs/manip.bash ]]
>117: source /usr/share/eselect/libs/manip.bash
>114: for x in "$@"
>115: [[ -e /usr/share/eselect/libs/output.bash ]]
>117: source /usr/share/eselect/libs/output.bash
>114: for x in "$@"
>115: [[ -e /usr/share/eselect/libs/path-manipulation.bash ]]
>117: source /usr/share/eselect/libs/path-manipulation.bash
>114: for x in "$@"
>115: [[ -e /usr/share/eselect/libs/tests.bash ]]
>117: source /usr/share/eselect/libs/tests.bash
>73: trap 'echo "exiting" >&2; exit 250' 15
>111: action=
>112: for suffix in config update{,r} tool manager reader
>113: [[ /usr/bin/eselect != \/\u\s\r\/\b\i\n\/\e\s\e\l\e\c\t ]]
>112: for suffix in config update{,r} tool manager reader
>113: [[ /usr/bin/eselect != \/\u\s\r\/\b\i\n\/\e\s\e\l\e\c\t ]]
>112: for suffix in config update{,r} tool manager reader
>113: [[ /usr/bin/eselect != \/\u\s\r\/\b\i\n\/\e\s\e\l\e\c\t ]]
>112: for suffix in config update{,r} tool manager reader
>113: [[ /usr/bin/eselect != \/\u\s\r\/\b\i\n\/\e\s\e\l\e\c\t ]]
>112: for suffix in config update{,r} tool manager reader
>113: [[ /usr/bin/eselect != \/\u\s\r\/\b\i\n\/\e\s\e\l\e\c\t ]]
>112: for suffix in config update{,r} tool manager reader
>113: [[ /usr/bin/eselect != \/\u\s\r\/\b\i\n\/\e\s\e\l\e\c\t ]]
>119: unset suffix
>121: [[ -z '' ]]
>>122: basename /usr/bin/eselect
>>22: local path=/usr/bin/eselect suf=
>>24: [[ -z /usr/bin/eselect ]]
>>30: path=/usr/bin/eselect
>>33: path=eselect
>>36: [[ '' != \e\s\e\l\e\c\t ]]
>>36: path=eselect
>>39: echo eselect
>122: binname=eselect
>123: for prefix in config update{,r} manage 'read'
>124: [[ eselect != eselect ]]
>123: for prefix in
Re: [gentoo-user] Nvidia-drivers fails to patch
Arve Barsnes wrote: > On Fri, 21 Apr 2023 at 11:55, Dale 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 > > That's right. I rarely do anything with local overlays so I forgot about that. Next time I'll try to remember to copy the whole directory, without deleting files no longer in the tree tho. Don't want to remove one I need. ;-) Thanks. Dale :-) :-)
Re: [gentoo-user] Nvidia-drivers fails to patch
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 :-) :-)
Re: [gentoo-user] Nvidia-drivers fails to patch
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 :-) :-)
Re: [gentoo-user] Nvidia-drivers fails to patch
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. pgp7HlTOyzzcT.pgp Description: OpenPGP digital signature
Re: [gentoo-user] Nvidia-drivers fails to patch
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. pgptWnU_q8g1I.pgp Description: OpenPGP digital signature
Re: [gentoo-user] Can I safely switch (no)multilib profile???
Le 20/04/23 à 17:41, Dr Rainer Woitok a tapoté : > Netfab, > > On Tuesday, 2023-04-18 19:23:08 +0200, you wrote: > > > ... > > Please post your emerge --info. > > $ emerge --info I do not see anything particular in your emerge --info. What is your eselect version ? > $ eselect --version You can get bash debug output by running the following : > $ bash -x /usr/bin/eselect profile list 2> /tmp/debug.log Hopefully this will show what's going on into /tmp/debug.log.
Re: [gentoo-user] Nvidia-drivers fails to patch
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 signature.asc Description: PGP signature
Re: [gentoo-user] Nvidia-drivers fails to patch
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
Re: [gentoo-user] Nvidia-drivers fails to patch
On Fri, 21 Apr 2023 at 11:55, Dale 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
Re: [gentoo-user] Nvidia-drivers fails to patch
Arve Barsnes wrote: > On Fri, 21 Apr 2023 at 10:58, Dale 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 :-) :-)
Re: [gentoo-user] Nvidia-drivers fails to patch
On Fri, 21 Apr 2023 at 10:58, Dale 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
Re: [gentoo-user] Nvidia-drivers fails to patch
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
:-) :-)
Re: [gentoo-user] Nvidia-drivers fails to patch
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!
signature.asc
Description: PGP signature
Re: [gentoo-user] How to install Ruby bindings in an ebuild
Hello Michael. Long time no read. ;-)
> I think the best way to support that in a package is to declare which
> ruby versions are supported with USE_RUBY and ruby-ng.eclass.
I tried what you suggested. However, inheriting from ruby-ng.eclass
introduces an odd problem: For some reason unknown to me, "${S}" no
longer matches the default value of "${WORKDIR}/${P}", but only what I'd
expect in "${WORKDIR}". That means the base directory for src_compile
and src_install is not correct, causing the build to fail. It might be a
bug in ruby-ng, or a side effect of inheriting from ruby-ng on top of
the other eclasses already needed/used by the ebuild. I don't feel
comfortable with opening this particular can of worms when only a single
library something.so needs to be installed. Right now, I changed to
this:
local p=$(ruby -e 'puts $LOAD_PATH' | grep 'vendor.\+linux')
[[ -d "${p}" ]] || die "'${p}' is not a directory"
exeinto "${p}"
Not very pretty either, but at least this avoids any hardcoded
directories.
-Ralph
