Re: [gentoo-portage-dev] [PATCH 0/4] Rename PORT_LOGDIR{,_CLEAN} variables to PORTAGE_LOGDIR{,_CLEAN} Bug 668538
On Mon, 2018-12-17 at 21:09 -0500, Alec Warner wrote: > On Mon, Dec 17, 2018 at 10:51 AM Michał Górny wrote: > > > On Mon, 2018-12-17 at 15:44 +, M. J. Everitt wrote: > > > On 17/12/18 12:54, Michał Górny wrote: > > > > > Not only this, but as noted, unless you know the man pages for > > > > portage and > > > > > make.conf in order to recite them in your sleep, they are confusing > > > > for > > > > > users, as they do not necessarily follow an obvious pattern, and it > > > > wasn't > > > > > until I was attempting to debug something that I noticed that despite > > > > > believing I had the correct settings in my make.conf (set over a > > > > period of > > > > > YEARS) they were in fact completely useless, and it wasn't until I > > > > had to > > > > > spend time with somebody debugging WTF was happening, that this > > > > particular > > > > > issue even became apparent... > > > > > > > > I don't see how this is an argument for anything. You have to read > > > > the manual in order to know that such variable exists and what it > > > > does. > > > > Or, well, technically you don't since it's provided in > > > > make.conf.example > > > > already where you only need to uncomment it. > > > > > > > > Either way, the variable name is trivial. Even if you don't follow > > > > the usual pattern of uncommenting it from make.conf.example or copying > > > > from the manual, remembering it for the time needed to retype shoudln't > > > > be a problem. > > > > > > > > So, is this a solution to a real problem? Or is it merely a half- > > > > thought-out partial change that's going to require people to update > > > > their configuration for no long-term benefit? And then they will have > > > > to update it again when someone decides to take another variable for > > > > a spin. > > > > > > > > > > In the case you hadn't noticed, clearly you haven't .. the change is > > > backwards compatible.. that has already been thought out. > > > > > > But you haven't actually looked at the patch have you, Michal ? > > > > > > > I did look at it. However, that doesn't change what I said. Being > > 'backwards compatible' does not change the fact that the old variable > > becomes deprecated now. Ergo, users are expected to eventually switch > > to the new one. > > > > So if we rewrote the patches to not deprecate the old one but to support > both; how would that strike you? > As a horrible idea, violating SPOT rule? -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
Re: [gentoo-portage-dev] [PATCH 0/4] Rename PORT_LOGDIR{,_CLEAN} variables to PORTAGE_LOGDIR{,_CLEAN} Bug 668538
On Mon, Dec 17, 2018 at 10:51 AM Michał Górny wrote: > On Mon, 2018-12-17 at 15:44 +, M. J. Everitt wrote: > > On 17/12/18 12:54, Michał Górny wrote: > > > > Not only this, but as noted, unless you know the man pages for > portage and > > > > make.conf in order to recite them in your sleep, they are confusing > for > > > > users, as they do not necessarily follow an obvious pattern, and it > wasn't > > > > until I was attempting to debug something that I noticed that despite > > > > believing I had the correct settings in my make.conf (set over a > period of > > > > YEARS) they were in fact completely useless, and it wasn't until I > had to > > > > spend time with somebody debugging WTF was happening, that this > particular > > > > issue even became apparent... > > > > > > I don't see how this is an argument for anything. You have to read > > > the manual in order to know that such variable exists and what it > does. > > > Or, well, technically you don't since it's provided in > make.conf.example > > > already where you only need to uncomment it. > > > > > > Either way, the variable name is trivial. Even if you don't follow > > > the usual pattern of uncommenting it from make.conf.example or copying > > > from the manual, remembering it for the time needed to retype shoudln't > > > be a problem. > > > > > > So, is this a solution to a real problem? Or is it merely a half- > > > thought-out partial change that's going to require people to update > > > their configuration for no long-term benefit? And then they will have > > > to update it again when someone decides to take another variable for > > > a spin. > > > > > > > In the case you hadn't noticed, clearly you haven't .. the change is > > backwards compatible.. that has already been thought out. > > > > But you haven't actually looked at the patch have you, Michal ? > > > > I did look at it. However, that doesn't change what I said. Being > 'backwards compatible' does not change the fact that the old variable > becomes deprecated now. Ergo, users are expected to eventually switch > to the new one. > So if we rewrote the patches to not deprecate the old one but to support both; how would that strike you? -A > > Even if you don't care beyond changing this now and forgetting about it > afterwards, someone eventually will have to clean up the old variable > and actively force people to update. > -- > Best regards, > Michał Górny >
Re: [gentoo-dev] Last rites: =x11-drivers/nvidia-drivers-375* =x11-drivers/nvidia-drivers-378* =x11-drivers/nvidia-drivers-381* =x11-drivers/nvidia-drivers-384* =x11-drivers/nvidia-drivers-387* =x11-d
On Sun, Dec 16, 2018 at 5:20 PM Jeroen Roovers wrote: > > On Sun, 16 Dec 2018 14:45:11 -0500 > Matt Turner wrote: > > > I guess my question to you is whether you think it's okay to mask -304 > > for removal or whether there are enough users that we should keep it > > under package.mask? > > "The Linux 304.* legacy driver series is the last to support the NV4x > and G7x GPUs and motherboard chipsets based on them. Support for new > Linux kernels and X servers, as well as fixes for critical bugs, will > be included in 304.* legacy releases through the end of 2017." [1] > > That should be fine, then: 304 no longer receives security support so it > can go away along with xorg-server-1.19. Thanks Jer!
Re: [gentoo-portage-dev] [PATCH 0/4] Rename PORT_LOGDIR{,_CLEAN} variables to PORTAGE_LOGDIR{,_CLEAN} Bug 668538
On 17/12/18 15:51, Michał Górny wrote: > On Mon, 2018-12-17 at 15:44 +, M. J. Everitt wrote: >> On 17/12/18 12:54, Michał Górny wrote: Not only this, but as noted, unless you know the man pages for portage and make.conf in order to recite them in your sleep, they are confusing for users, as they do not necessarily follow an obvious pattern, and it wasn't until I was attempting to debug something that I noticed that despite believing I had the correct settings in my make.conf (set over a period of YEARS) they were in fact completely useless, and it wasn't until I had to spend time with somebody debugging WTF was happening, that this particular issue even became apparent... >>> I don't see how this is an argument for anything. You have to read >>> the manual in order to know that such variable exists and what it does. >>> Or, well, technically you don't since it's provided in make.conf.example >>> already where you only need to uncomment it. >>> >>> Either way, the variable name is trivial. Even if you don't follow >>> the usual pattern of uncommenting it from make.conf.example or copying >>> from the manual, remembering it for the time needed to retype shoudln't >>> be a problem. >>> >>> So, is this a solution to a real problem? Or is it merely a half- >>> thought-out partial change that's going to require people to update >>> their configuration for no long-term benefit? And then they will have >>> to update it again when someone decides to take another variable for >>> a spin. >>> >> In the case you hadn't noticed, clearly you haven't .. the change is >> backwards compatible.. that has already been thought out. >> >> But you haven't actually looked at the patch have you, Michal ? >> > I did look at it. However, that doesn't change what I said. Being > 'backwards compatible' does not change the fact that the old variable > becomes deprecated now. Ergo, users are expected to eventually switch > to the new one. > > Even if you don't care beyond changing this now and forgetting about it > afterwards, someone eventually will have to clean up the old variable > and actively force people to update. > Correct, but surely this doesn't apply in any other areas of Gentoo, eg. perhaps Ebuilds? EAPIs? PMS? QA? signature.asc Description: OpenPGP digital signature
Re: [gentoo-portage-dev] [PATCH 0/4] Rename PORT_LOGDIR{,_CLEAN} variables to PORTAGE_LOGDIR{,_CLEAN} Bug 668538
On Mon, 2018-12-17 at 15:44 +, M. J. Everitt wrote: > On 17/12/18 12:54, Michał Górny wrote: > > > Not only this, but as noted, unless you know the man pages for portage and > > > make.conf in order to recite them in your sleep, they are confusing for > > > users, as they do not necessarily follow an obvious pattern, and it wasn't > > > until I was attempting to debug something that I noticed that despite > > > believing I had the correct settings in my make.conf (set over a period of > > > YEARS) they were in fact completely useless, and it wasn't until I had to > > > spend time with somebody debugging WTF was happening, that this particular > > > issue even became apparent... > > > > I don't see how this is an argument for anything. You have to read > > the manual in order to know that such variable exists and what it does. > > Or, well, technically you don't since it's provided in make.conf.example > > already where you only need to uncomment it. > > > > Either way, the variable name is trivial. Even if you don't follow > > the usual pattern of uncommenting it from make.conf.example or copying > > from the manual, remembering it for the time needed to retype shoudln't > > be a problem. > > > > So, is this a solution to a real problem? Or is it merely a half- > > thought-out partial change that's going to require people to update > > their configuration for no long-term benefit? And then they will have > > to update it again when someone decides to take another variable for > > a spin. > > > > In the case you hadn't noticed, clearly you haven't .. the change is > backwards compatible.. that has already been thought out. > > But you haven't actually looked at the patch have you, Michal ? > I did look at it. However, that doesn't change what I said. Being 'backwards compatible' does not change the fact that the old variable becomes deprecated now. Ergo, users are expected to eventually switch to the new one. Even if you don't care beyond changing this now and forgetting about it afterwards, someone eventually will have to clean up the old variable and actively force people to update. -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
Re: [gentoo-portage-dev] [PATCH 0/4] Rename PORT_LOGDIR{,_CLEAN} variables to PORTAGE_LOGDIR{,_CLEAN} Bug 668538
On 17/12/18 15:44, M. J. Everitt wrote: > On 17/12/18 12:54, Michał Górny wrote: >>> Not only this, but as noted, unless you know the man pages for portage and >>> make.conf in order to recite them in your sleep, they are confusing for >>> users, as they do not necessarily follow an obvious pattern, and it wasn't >>> until I was attempting to debug something that I noticed that despite >>> believing I had the correct settings in my make.conf (set over a period of >>> YEARS) they were in fact completely useless, and it wasn't until I had to >>> spend time with somebody debugging WTF was happening, that this particular >>> issue even became apparent... >> I don't see how this is an argument for anything. You have to read >> the manual in order to know that such variable exists and what it does. >> Or, well, technically you don't since it's provided in make.conf.example >> already where you only need to uncomment it. >> >> Either way, the variable name is trivial. Even if you don't follow >> the usual pattern of uncommenting it from make.conf.example or copying >> from the manual, remembering it for the time needed to retype shoudln't >> be a problem. >> >> So, is this a solution to a real problem? Or is it merely a half- >> thought-out partial change that's going to require people to update >> their configuration for no long-term benefit? And then they will have >> to update it again when someone decides to take another variable for >> a spin. >> > In the case you hadn't noticed, clearly you haven't .. the change is > backwards compatible.. that has already been thought out. > > But you haven't actually looked at the patch have you, Michal ? > Whilst I'm here .. you won't also have noticed I've updated the documentation too ... signature.asc Description: OpenPGP digital signature
Re: [gentoo-portage-dev] [PATCH 0/4] Rename PORT_LOGDIR{,_CLEAN} variables to PORTAGE_LOGDIR{,_CLEAN} Bug 668538
On 17/12/18 12:54, Michał Górny wrote: >> Not only this, but as noted, unless you know the man pages for portage and >> make.conf in order to recite them in your sleep, they are confusing for >> users, as they do not necessarily follow an obvious pattern, and it wasn't >> until I was attempting to debug something that I noticed that despite >> believing I had the correct settings in my make.conf (set over a period of >> YEARS) they were in fact completely useless, and it wasn't until I had to >> spend time with somebody debugging WTF was happening, that this particular >> issue even became apparent... > I don't see how this is an argument for anything. You have to read > the manual in order to know that such variable exists and what it does. > Or, well, technically you don't since it's provided in make.conf.example > already where you only need to uncomment it. > > Either way, the variable name is trivial. Even if you don't follow > the usual pattern of uncommenting it from make.conf.example or copying > from the manual, remembering it for the time needed to retype shoudln't > be a problem. > > So, is this a solution to a real problem? Or is it merely a half- > thought-out partial change that's going to require people to update > their configuration for no long-term benefit? And then they will have > to update it again when someone decides to take another variable for > a spin. > In the case you hadn't noticed, clearly you haven't .. the change is backwards compatible.. that has already been thought out. But you haven't actually looked at the patch have you, Michal ? signature.asc Description: OpenPGP digital signature
Re: [gentoo-portage-dev] [PATCH 0/4] Rename PORT_LOGDIR{,_CLEAN} variables to PORTAGE_LOGDIR{,_CLEAN} Bug 668538
On Mon, 2018-12-17 at 05:12 +, M. J. Everitt wrote: > On 15/12/18 08:55, Michał Górny wrote: > > On Sat, 2018-12-15 at 02:25 +, M. J. Everitt wrote: > > > This patchset aims to fix potential ambiguity and confusion between older > > > PORT_LOG* variables, > > > and more recent PORTAGE_* variables - often leading to mysteriously > > > lacking logging due to > > > incorrect variable names. Documented in Bug 668538; with thanks to Zac > > > for diagnosis, and > > > solution assistance! > > > > > > > Does 'often' actually affect more than one person? Do you have any > > evidence to support this? > > > > Given that a lot of Portage variables don't have any prefix or sane > > names, I dare say this one doesn't especially stand out. > > > > Just a thought, but how about you apply your skill and wisdom to reviewing > the patches, instead of wasting it on writing snide replies? > Quite radical I know, but whadda ya think?! You didn't answer my question. However, given the level of aggression in your reply, I'm going to presume I've caught you on a blatant lie and that this problem affects exactly one person, yourself, and you are making an unnecessary change to bend the world to your mistake. > As it happens, I was going for consistency here, as that often reflects > code quality, and you being a keen QA member, I'da thought perhaps you > might have spotted this! Are you? Do you have any evidence to support that? Because as far as I can see (and it's even quite visible in your patch), none of the variables in the group with 'PORT_LOGDIR' in it use 'PORTAGE_' prefix. So are you improving consistency in variable naming, or are you replacing one inconsistency with another? > Not only this, but as noted, unless you know the man pages for portage and > make.conf in order to recite them in your sleep, they are confusing for > users, as they do not necessarily follow an obvious pattern, and it wasn't > until I was attempting to debug something that I noticed that despite > believing I had the correct settings in my make.conf (set over a period of > YEARS) they were in fact completely useless, and it wasn't until I had to > spend time with somebody debugging WTF was happening, that this particular > issue even became apparent... I don't see how this is an argument for anything. You have to read the manual in order to know that such variable exists and what it does. Or, well, technically you don't since it's provided in make.conf.example already where you only need to uncomment it. Either way, the variable name is trivial. Even if you don't follow the usual pattern of uncommenting it from make.conf.example or copying from the manual, remembering it for the time needed to retype shoudln't be a problem. So, is this a solution to a real problem? Or is it merely a half- thought-out partial change that's going to require people to update their configuration for no long-term benefit? And then they will have to update it again when someone decides to take another variable for a spin. -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
[gentoo-dev] [PATCH] eclass/java-utils-2: switch to eapi7-ver
Signed-off-by: Marty E. Plummer
---
eclass/java-utils-2.eclass | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/eclass/java-utils-2.eclass b/eclass/java-utils-2.eclass
index 473b177e539..a4c218c394e 100644
--- a/eclass/java-utils-2.eclass
+++ b/eclass/java-utils-2.eclass
@@ -1,4 +1,4 @@
-# Copyright 2004-2018 Gentoo Foundation
+# Copyright 2004-2018 Gentoo Authors
# Distributed under the terms of the GNU General Public License v2
# @ECLASS: java-utils-2.eclass
@@ -15,7 +15,7 @@
# you should inherit java-pkg-2 for Java packages or java-pkg-opt-2 for
packages
# that have optional Java support. In addition you can inherit java-ant-2 for
# Ant-based packages.
-inherit eutils versionator multilib
+inherit eutils multilib
IUSE="elibc_FreeBSD"
@@ -25,6 +25,9 @@ export WANT_JAVA_CONFIG="2"
# Prefix variables are only available for EAPI>=3
has "${EAPI:-0}" 0 1 2 && ED="${D}" EPREFIX= EROOT="${ROOT}"
+# EAPI 7 has version functions built-in. Use eapi7-ver for all earlier
eclasses.
+[[ ${EAPI} == [0123456] ]] && inherit eapi7-ver
+
# @VARIABLE: JAVA_PKG_E_DEPEND
# @INTERNAL
# @DESCRIPTION:
@@ -1518,8 +1521,8 @@ java-pkg_is-vm-version-eq() {
local vm_version="$(java-pkg_get-vm-version)"
- vm_version="$(get_version_component_range 1-2 "${vm_version}")"
- needed_version="$(get_version_component_range 1-2 "${needed_version}")"
+ vm_version="$(ver_cut 1-2 "${vm_version}")"
+ needed_version="$(ver_cut 1-2 "${needed_version}")"
if [[ -z "${vm_version}" ]]; then
debug-print "Could not get JDK version from DEPEND"
@@ -1570,7 +1573,7 @@ java-pkg_is-vm-version-ge() {
debug-print "Could not get JDK version from DEPEND"
return 1
else
- if version_is_at_least "${needed_version}" "${vm_version}"; then
+ if ver_test "${vm_version}" -ge "${needed_version}"; then
debug-print "Detected a JDK(${vm_version}) >=
${needed_version}"
return 0
else
--
2.20.0
