[gentoo-user] Re: How to disable fuzzy-search in emerge?
On 2020-04-10, Grant Taylor wrote: > I took pause for a moment wondering if this was something I typed or > not. ;-) I know what you mean. :) -- Grant (the other one)
Re: [gentoo-user] Re: Per package /bin/sh selection
On 4/10/20 10:29 PM, Ian Zimmerman wrote: > On 2020-04-08 18:49, Michael Orlitzky wrote: > >> Ebuilds are bash, but the ./configure scripts and makefiles that often >> get run within the ebuilds use /bin/sh by default. > > I see, but then it is an upstream problem no? I mean if upstreams keep > putting bashisms in their build systems they will keep doing it no > matter how clean the gentoo dash package is. > Yup. Ideally they will fix the bashisms, but if not and they decide only to support bash, they should still set SHELL=bash or something like that instead of just praying that /bin/sh points there.
[gentoo-user] Re: Per package /bin/sh selection
On 2020-04-08 18:49, Michael Orlitzky wrote: > Ebuilds are bash, but the ./configure scripts and makefiles that often > get run within the ebuilds use /bin/sh by default. I see, but then it is an upstream problem no? I mean if upstreams keep putting bashisms in their build systems they will keep doing it no matter how clean the gentoo dash package is. -- Ian
Re: [gentoo-user] Re: How to disable fuzzy-search in emerge?
On 4/10/20 11:00 AM, Grant Edwards wrote: Yes, that works! Good. Thanks!! You're welcome. I don't know why it didn't occur to me to check for a make.conf variable instead of an environment variable or USE flag. Of course now that I know that make.conf variable's name, I have found it in few other places in the emerge man page, and there's a clear description of it in make.conf(5). Unfortunately, the emerge man page doesn't really discuss make.conf except for a few places where it's mentioned that some specific option can be controlled via make.conf. I often feel like the make.conf file is a collection of environment variables, almost as if the file was sourced prior to running emerge. As such, I have to realize that if something looks like an environment variable, it can probably go into the make.conf as such. -- Grant I took pause for a moment wondering if this was something I typed or not. ;-) -- Grant. . . . unix || die
Re: [gentoo-user] Re: How to disable fuzzy-search in emerge?
Grant Edwards wrote: > On 2020-04-10, Dale wrote: > >> Equery used to behave like emerge does now, and maybe always has. > Really? Equery used to do fuzzy search by default, where it returns > package that don't actually contain the search string? > > What I liked about emerge --search, is that it would show you both the > installed version and the available version. I never figured out how > to get equery to do that. > > -- > Grant > Equery used to do that but it was changed a few years or so ago. It requires a more precise search now or the use of wildcards. Look at the output of mine in previous reply and you can also see what is installed, what is available and it even shows if a package is masked or keyworded. The command and options are equery list -p to get that. If you use overlays a lot, add -o to that or -po will work. Equery is my go to tool since I run some things stable and some things unstable. Dale :-) :-)
[gentoo-user] Re: How to disable fuzzy-search in emerge?
On 2020-04-10, Grant Taylor wrote: > > On 4/10/20 10:08 AM, Grant Edwards wrote: >> Yes, I'm aware I can add "--fuzzy-search n" to make it act sane, but >> is there an environment variable or USE flag or _something_ to make >> emerge --search do the right thing by default? > Does adding it to EMERGE_DEFAULT_OPTS in /etc/portage/make.conf help? Yes, that works! Thanks!! I don't know why it didn't occur to me to check for a make.conf variable instead of an environment variable or USE flag. Of course now that I know that make.conf variable's name, I have found it in few other places in the emerge man page, and there's a clear description of it in make.conf(5). Unfortunately, the emerge man page doesn't really discuss make.conf except for a few places where it's mentioned that some specific option can be controlled via make.conf. -- Grant
[gentoo-user] Re: How to disable fuzzy-search in emerge?
On 2020-04-10, Dale wrote: > Equery used to behave like emerge does now, and maybe always has. Really? Equery used to do fuzzy search by default, where it returns package that don't actually contain the search string? What I liked about emerge --search, is that it would show you both the installed version and the available version. I never figured out how to get equery to do that. -- Grant
Re: [gentoo-user] Re: How to disable fuzzy-search in emerge?
Grant Edwards wrote: > On 2020-04-10, Alec Ten Harmsel wrote: >> On Fri, Apr 10, 2020, at 12:08, Grant Edwards wrote: >>> I really, really hate how emerge now returns bucketfulls of useless, >>> unrelated results when you do a search. WTF is the point of returning >>> a bunch of packages that don't contain the search string when there is >>> is a package name that match the search string exactly? >> This doesn't answer your question, but `eix' is way faster and I've been >> using it since I've started using Gentoo. > Yes, I should just use eix or equery instead, now that emerge --search > is broken by default. > > -- > Grant > Equery used to behave like emerge does now, and maybe always has. A few years ago equery changed tho. Example. You type in equery list -p firefox and it will only return exact matches to firefox. It doesn't even return firefox-bin unless you put a wildcard on the end. Like this: root@fireball / # equery list -p firefox * Searching for firefox ... [-P-] [M ] www-client/firefox-52.9.0:0 [-P-] [ ] www-client/firefox-68.6.1:0 [IP-] [ ] www-client/firefox-74.0.1:0 root@fireball / # equery list -p firefox* * Searching for firefox* ... [-P-] [M ] www-client/firefox-52.9.0:0 [-P-] [ ] www-client/firefox-68.6.1:0 [IP-] [ ] www-client/firefox-74.0.1:0 [-P-] [M ] www-client/firefox-bin-52.9.0:0 [-P-] [ ] www-client/firefox-bin-68.6.1:0 [-P-] [ ] www-client/firefox-bin-74.0.1:0 root@fireball / # I have found that each tool has its strengths. Equery is just better at some things. Since I tend to copy and paste from the output of emerge, I'm able to get the exact name of the package I want info on. I rarely use the wildcards but sometimes they help. Also, you can put wildcards on the front or in the middle too. I think there is a way to get it to list the description to but can't recall the option. There is also those q tools. I rarely use them but I've seen others post output from commands they ran and it is interesting. Sometimes they give info that is much better. Thing is, it's hard for this old dog to learn new tricks when I don't use them often. Maybe one of those will help, or point you in a better direction. Dale :-) :-)
Re: [gentoo-user] No keyserver available
пт, 10 апр. 2020 г. в 00:55, Michael : > > On Tuesday, 7 April 2020 14:36:04 BST gevisz wrote: > > I have a long standing "gpg can't check signature: No public key" > > error while running # emerge-webrsync > > It appears because the webrsync-gpg feature has been set in my > > make.conf however I do not want to switch it off. > > The app-crypt/gentoo-keys is installed, so it is not the reason for above > > error. I have just tried to download gentoo pgp keys manually with the > > command gpg --keyserver hkps://keys.gentoo.org --recv-keys > > 13EBBDBEDE7A12775DFDB1BABB572E0E2D182910 > > and got the following error message: > > gpg: keyserver receive failed: No keyserver available > > Can anybody explain me how to fix this? > > If you can't connect then you may have some network configuration issue, or > potentially the keyserver is busy at this moment. However, this would only be > a temporary problem and you report you've been getting this regularly. > > Do you see if port 443 is open from where you are? > > $ nc -v -z keys.gentoo.org 443 > DNS fwd/rev mismatch: keys.geodns-europe.gentoo.org != trogan.gentoo.org > keys.geodns-europe.gentoo.org [89.238.71.4] 443 (https) open Thank you for your reply. The command above returns exactly the same. And no, this problem is not temporal. > Alternatively, do you also have a problem using rsync? After some changes in configulation files, I can currently sync using # emaint sync -A However, # gpg --keyserver hkps://keys.gentoo.org --recv-keys 13EB... command returns the same error as before.
Re: [gentoo-user] How to disable fuzzy-search in emerge?
On 4/10/20 10:08 AM, Grant Edwards wrote: Yes, I'm aware I can add "--fuzzy-search n" to make it act sane, but is there an environment variable or USE flag or _something_ to make emerge --search do the right thing by default? Does adding it to EMERGE_DEFAULT_OPTS in /etc/portage/make.conf help? -- Grant. . . . unix || die
Re: [gentoo-user] How to disable fuzzy-search in emerge?
On 2020.04.10 12:21, Alec Ten Harmsel wrote: On Fri, Apr 10, 2020, at 12:08, Grant Edwards wrote: > I really, really hate how emerge now returns bucketfulls of useless, > unrelated results when you do a search. WTF is the point of returning > a bunch of packages that don't contain the search string when there is > is a package name that match the search string exactly? This doesn't answer your question, but `eix' is way faster and I've been using it since I've started using Gentoo. Alec Even eix often finds things I think are irrelevant, but I know it's searching on a regexp, so I'll often do "eix ^string$ if I know the package and am just looking for the info about it. Jack
[gentoo-user] Re: How to disable fuzzy-search in emerge?
On 2020-04-10, Alec Ten Harmsel wrote: > On Fri, Apr 10, 2020, at 12:08, Grant Edwards wrote: >> I really, really hate how emerge now returns bucketfulls of useless, >> unrelated results when you do a search. WTF is the point of returning >> a bunch of packages that don't contain the search string when there is >> is a package name that match the search string exactly? > > This doesn't answer your question, but `eix' is way faster and I've been > using it since I've started using Gentoo. Yes, I should just use eix or equery instead, now that emerge --search is broken by default. -- Grant
Re: [gentoo-user] How to disable fuzzy-search in emerge?
On Fri, Apr 10, 2020, at 12:08, Grant Edwards wrote: > I really, really hate how emerge now returns bucketfulls of useless, > unrelated results when you do a search. WTF is the point of returning > a bunch of packages that don't contain the search string when there is > is a package name that match the search string exactly? This doesn't answer your question, but `eix' is way faster and I've been using it since I've started using Gentoo. Alec
[gentoo-user] How to disable fuzzy-search in emerge?
I really, really hate how emerge now returns bucketfulls of useless, unrelated results when you do a search. WTF is the point of returning a bunch of packages that don't contain the search string when there is is a package name that match the search string exactly? Yes, I'm aware I can add "--fuzzy-search n" to make it act sane, but is there an environment variable or USE flag or _something_ to make emerge --search do the right thing by default? I have never, even once, found the current defult behavior to be useful. -- Grant
Re: [gentoo-user] Nvidia-driver installation problems...
On 04/10 12:48, Neil Bothwick wrote: > On Fri, 10 Apr 2020 12:21:46 +0200, tu...@posteo.de wrote: > > > On 04/10 11:11, Neil Bothwick wrote: > > > On Fri, 10 Apr 2020 11:40:59 +0200, tu...@posteo.de wrote: > > > > > > > > package.provided requires a specific version, try > > > > > > > > > > x11-drivers/nvidia-drivers-340.108 > > > > > > > > > > If you want to stop portage trying to replace this with a later > > > > > version, add ">x11-drivers/nvidia-drivers-340.108", note > not > > > > > >=, to package.mask. > > > > > > > > /etc/portage/profile/package.provided is still being ignored. > > > > > > > > Current content: > > > > >x11-drivers/nvidia-drivers-340.108 > > > > > > > > Emerge starts to install the newest driver available. > > > > > > Because package.provided still doesn't contain a single version. > > > Remove the >. > > > > That leads to another problem: > > It will not detect newer version comping into portage... > > I need to include any single version available. > > That's kinda painful... > > That's the burden you take on by managing the package yourself. You have > to watch for new versions yourself. > > > -- > Neil Bothwick > > All generalizations are false. ...I do it, because I try to track down an issue, how Gentoo installs that very package in a way, in which Blender no longer recognize the GPU. Additional see the problem concerning Optix a view days ago with the same package...
Re: [gentoo-user] Nvidia-driver installation problems...
On Fri, 10 Apr 2020 12:21:46 +0200, tu...@posteo.de wrote: > On 04/10 11:11, Neil Bothwick wrote: > > On Fri, 10 Apr 2020 11:40:59 +0200, tu...@posteo.de wrote: > > > > > > package.provided requires a specific version, try > > > > > > > > x11-drivers/nvidia-drivers-340.108 > > > > > > > > If you want to stop portage trying to replace this with a later > > > > version, add ">x11-drivers/nvidia-drivers-340.108", note > not > > > > >=, to package.mask. > > > > > > /etc/portage/profile/package.provided is still being ignored. > > > > > > Current content: > > > >x11-drivers/nvidia-drivers-340.108 > > > > > > Emerge starts to install the newest driver available. > > > > Because package.provided still doesn't contain a single version. > > Remove the >. > > That leads to another problem: > It will not detect newer version comping into portage... > I need to include any single version available. > That's kinda painful... That's the burden you take on by managing the package yourself. You have to watch for new versions yourself. -- Neil Bothwick All generalizations are false. pgpwh2T83AJE2.pgp Description: OpenPGP digital signature
Re: [gentoo-user] How to replace vala:0.46 by vala:0.48
On 04/08/2020 09:47:25 PM, Michael Orlitzky wrote: On 4/8/20 2:26 PM, Helmut Jarausch wrote: > Hi, > Having installed vala:0.48 I still cannot un-emerge vala:0.46 > because gnome-extra/evolution-data-server depends on it. > But I cannot see that dependency in the ebuild. > > What am I missing? > When these changes (affecting RDEPEND) are made without a new revision, commit cf84f5f2ec43468f080513821b83220a79801ecf Author: Mart Raudsepp Date: Wed Feb 12 17:47:54 2020 +0200 vala.eclass: raise VALA_MAX_API_VERSION to 0.48 Signed-off-by: Mart Raudsepp it breaks dependency resolution for everyone who has the package installed. This is already against our written policy, but not in practice, because QA and council members regularly do it themselves. Unless a majority of candidates run for council on the platform of actually doing a good job and/or following the rules, we all just have to live with it forever. Thanks, it turned out that there was an old vala eclass in my local overlay.
Re: [gentoo-user] Nvidia-driver installation problems...
On 04/10 11:11, Neil Bothwick wrote: > On Fri, 10 Apr 2020 11:40:59 +0200, tu...@posteo.de wrote: > > > > package.provided requires a specific version, try > > > > > > x11-drivers/nvidia-drivers-340.108 > > > > > > If you want to stop portage trying to replace this with a later > > > version, add ">x11-drivers/nvidia-drivers-340.108", note > not >=, to > > > package.mask. > > > > > > > > > -- > > > Neil Bothwick > > > > > > .sig a .sog of sixpence. > > > > /etc/portage/profile/package.provided is still being ignored. > > > > Current content: > > >x11-drivers/nvidia-drivers-340.108 > > > > Emerge starts to install the newest driver available. > > Because package.provided still doesn't contain a single version. Remove > the >. > > > -- > Neil Bothwick > > There are only two tragedies in life: one is not getting what one wants; > and the other is getting it. - Oscar Wilde (1854-1900) That leads to another problem: It will not detect newer version comping into portage... I need to include any single version available. That's kinda painful...
Re: [gentoo-user] Nvidia-driver installation problems...
On Fri, 10 Apr 2020 11:40:59 +0200, tu...@posteo.de wrote: > > package.provided requires a specific version, try > > > > x11-drivers/nvidia-drivers-340.108 > > > > If you want to stop portage trying to replace this with a later > > version, add ">x11-drivers/nvidia-drivers-340.108", note > not >=, to > > package.mask. > > > > > > -- > > Neil Bothwick > > > > .sig a .sog of sixpence. > > /etc/portage/profile/package.provided is still being ignored. > > Current content: > >x11-drivers/nvidia-drivers-340.108 > > Emerge starts to install the newest driver available. Because package.provided still doesn't contain a single version. Remove the >. -- Neil Bothwick There are only two tragedies in life: one is not getting what one wants; and the other is getting it. - Oscar Wilde (1854-1900) pgpKWvBWK_RP_.pgp Description: OpenPGP digital signature
Re: [gentoo-user] Nvidia-driver installation problems...
On 04/10 10:29, Neil Bothwick wrote: > On Fri, 10 Apr 2020 11:25:16 +0200, tu...@posteo.de wrote: > > > If I remove nvidia-drivers and install the drivers of the same > > version as provided by nvidia itsself, everything works find. > > > > To examine this a little further I have put nividia-drivers > > into /etc/portage/profile/package.provided: > > > > >=x11-drivers/nvidia-drivers-340.108 > > > > which will silently be ignored and nvidia-drivers will > > be emerged...which will lead to a whole lotta mess. > > package.provided requires a specific version, try > > x11-drivers/nvidia-drivers-340.108 > > If you want to stop portage trying to replace this with a later version, > add ">x11-drivers/nvidia-drivers-340.108", note > not >=, to package.mask. > > > -- > Neil Bothwick > > .sig a .sog of sixpence. /etc/portage/profile/package.provided is still being ignored. Current content: >x11-drivers/nvidia-drivers-340.108 Emerge starts to install the newest driver available. -- Meino Cramer
Re: [gentoo-user] Nvidia-driver installation problems...
On Fri, 10 Apr 2020 11:25:16 +0200, tu...@posteo.de wrote: > If I remove nvidia-drivers and install the drivers of the same > version as provided by nvidia itsself, everything works find. > > To examine this a little further I have put nividia-drivers > into /etc/portage/profile/package.provided: > > >=x11-drivers/nvidia-drivers-340.108 > > which will silently be ignored and nvidia-drivers will > be emerged...which will lead to a whole lotta mess. package.provided requires a specific version, try x11-drivers/nvidia-drivers-340.108 If you want to stop portage trying to replace this with a later version, add ">x11-drivers/nvidia-drivers-340.108", note > not >=, to package.mask. -- Neil Bothwick .sig a .sog of sixpence. pgpDZ61bAu3zZ.pgp Description: OpenPGP digital signature
[gentoo-user] Nvidia-driver installation problems...
Hi, I am using kernel 5.15 / 6.3 vanilla. When using nvidia-drivers via Gentoo I can start X11 and such. Blender does not find the GPU though. If I remove nvidia-drivers and install the drivers of the same version as provided by nvidia itsself, everything works find. To examine this a little further I have put nividia-drivers into /etc/portage/profile/package.provided: >=x11-drivers/nvidia-drivers-340.108 which will silently be ignored and nvidia-drivers will be emerged...which will lead to a whole lotta mess. How can I stop emerge from emergeing nvidia-drivers without masking (which leads to a bunch of new problems) other than pressing CTRL-C each time? ;) Cheers! Stay healthy! Meino
