[gentoo-dev] [PATCH 2/2] xorg-2.eclass: Remove XORG_STATIC

2021-01-08 Thread Matt Turner
Statically linking X libraries into your program is an extremely bad
idea.

Signed-off-by: Matt Turner 
---
 eclass/xorg-2.eclass | 23 +--
 1 file changed, 1 insertion(+), 22 deletions(-)

diff --git a/eclass/xorg-2.eclass b/eclass/xorg-2.eclass
index f3b282e1a11..f9a18b8ec26 100644
--- a/eclass/xorg-2.eclass
+++ b/eclass/xorg-2.eclass
@@ -1,4 +1,4 @@
-# Copyright 1999-2020 Gentoo Authors
+# Copyright 1999-2021 Gentoo Authors
 # Distributed under the terms of the GNU General Public License v2
 
 # @ECLASS: xorg-2.eclass
@@ -168,27 +168,6 @@ fi
 # If we're a driver package, then enable DRIVER case
 [[ ${PN} == xf86-video-* || ${PN} == xf86-input-* ]] && DRIVER="yes"
 
-# @ECLASS-VARIABLE: XORG_STATIC
-# @DESCRIPTION:
-# Enables static-libs useflag. Set to no, if your package gets:
-#
-# QA: configure: WARNING: unrecognized options: --disable-static
-: ${XORG_STATIC:="yes"}
-
-# Add static-libs useflag where useful.
-if [[ ${XORG_STATIC} == yes \
-   && ${FONT} != yes \
-   && ${CATEGORY} != app-doc \
-   && ${CATEGORY} != x11-apps \
-   && ${CATEGORY} != x11-drivers \
-   && ${CATEGORY} != media-fonts \
-   && ${PN} != util-macros \
-   && ${PN} != xbitmaps \
-   && ${PN} != xorg-cf-files \
-   && ${PN/xcursor} = ${PN} ]]; then
-   IUSE+=" static-libs"
-fi
-
 DEPEND+=" virtual/pkgconfig"
 
 # @ECLASS-VARIABLE: XORG_DRI
-- 
2.26.2




[gentoo-dev] [PATCH 1/2] xorg-3.eclass: Remove XORG_STATIC

2021-01-08 Thread Matt Turner
Statically linking X libraries into your program is an extremely bad
idea.

Signed-off-by: Matt Turner 
---
 eclass/xorg-3.eclass | 22 --
 1 file changed, 22 deletions(-)

diff --git a/eclass/xorg-3.eclass b/eclass/xorg-3.eclass
index ece4d97b433..399fc8661f4 100644
--- a/eclass/xorg-3.eclass
+++ b/eclass/xorg-3.eclass
@@ -169,28 +169,6 @@ if [[ ${FONT} == yes ]]; then
FONT_DIR=${FONT_DIR/type1/Type1}
FONT_DIR=${FONT_DIR/speedo/Speedo}
 fi
-
-# @ECLASS-VARIABLE: XORG_STATIC
-# @DESCRIPTION:
-# Enables static-libs useflag. Set to no, if your package gets:
-#
-# QA: configure: WARNING: unrecognized options: --disable-static
-: ${XORG_STATIC:="yes"}
-
-# Add static-libs useflag where useful.
-if [[ ${XORG_STATIC} == yes \
-   && ${FONT} != yes \
-   && ${CATEGORY} != app-doc \
-   && ${CATEGORY} != x11-apps \
-   && ${CATEGORY} != x11-drivers \
-   && ${CATEGORY} != media-fonts \
-   && ${PN} != util-macros \
-   && ${PN} != xbitmaps \
-   && ${PN} != xorg-cf-files \
-   && ${PN/xcursor} = ${PN} ]]; then
-   IUSE+=" static-libs"
-fi
-
 BDEPEND+=" virtual/pkgconfig"
 
 # @ECLASS-VARIABLE: XORG_DRI
-- 
2.26.2




[gentoo-dev] [PATCH v3] acct-user.eclass: allow opt-out of user modification

2021-01-08 Thread Thomas Deutschmann
In some setups where users are changed/managed not only via ebuilds,
for example through configuration management systems, it could be
problematic if acct-user.eclass will restore user/group settings
to values set in ebuild.

Setting ACCT_USER_NO_MODIFY to a non-zero value will allow system
administrator to disable modification of any existing user.

Note: Lock/unlock when acct-* package will be installed/removed
  will still happen.

Signed-off-by: Thomas Deutschmann 
---

 v3: 
   - Fixed eclass documentation
   - Honor 80 chars limit
   - Prefixed internal variable ACCT_USER_ALREADY_EXISTS

 eclass/acct-user.eclass | 27 +++
 1 file changed, 27 insertions(+)

diff --git a/eclass/acct-user.eclass b/eclass/acct-user.eclass
index 47890e48409a..dcda661d39ea 100644
--- a/eclass/acct-user.eclass
+++ b/eclass/acct-user.eclass
@@ -72,6 +72,11 @@ readonly ACCT_USER_NAME
 # Overlays should set this to -1 to dynamically allocate UID.  Using -1
 # in ::gentoo is prohibited by policy.
 
+# @ECLASS-VARIABLE: _ACCT_USER_ALREADY_EXISTS
+# @INTERNAL
+# @DESCRIPTION:
+# Status variable which indicates if user already exists.
+
 # @ECLASS-VARIABLE: ACCT_USER_ENFORCE_ID
 # @DESCRIPTION:
 # If set to a non-null value, the eclass will require the user to have
@@ -79,6 +84,13 @@ readonly ACCT_USER_NAME
 # the UID is taken by another user, the install will fail.
 : ${ACCT_USER_ENFORCE_ID:=}
 
+# @ECLASS-VARIABLE: ACCT_USER_NO_MODIFY
+# @DEFAULT_UNSET
+# @DESCRIPTION:
+# If set to a non-null value, the eclass will not make any changes
+# to an already existing user.
+: ${ACCT_USER_NO_MODIFY:=}
+
 # @ECLASS-VARIABLE: ACCT_USER_SHELL
 # @DESCRIPTION:
 # The shell to use for the user.  If not specified, a 'nologin' variant
@@ -344,6 +356,13 @@ acct-user_src_install() {
 acct-user_pkg_preinst() {
debug-print-function ${FUNCNAME} "${@}"
 
+   # check if user already exists
+   _ACCT_USER_ALREADY_EXISTS=
+   if [[ -n $(egetent passwd "${ACCT_USER_NAME}") ]]; then
+   _ACCT_USER_ALREADY_EXISTS=yes
+   fi
+   readonly _ACCT_USER_ALREADY_EXISTS
+
local groups=${ACCT_USER_GROUPS[*]}
enewuser ${ACCT_USER_ENFORCE_ID:+-F} -M "${ACCT_USER_NAME}" \
"${ACCT_USER_ID}" "${ACCT_USER_SHELL}" "${ACCT_USER_HOME}" \
@@ -379,6 +398,14 @@ acct-user_pkg_postinst() {
return 0
fi
 
+   if [[ -n ${ACCT_USER_NO_MODIFY} && -n ${_ACCT_USER_ALREADY_EXISTS} ]] ; 
then
+   eunlockuser "${ACCT_USER_NAME}"
+
+   ewarn "User ${ACCT_USER_NAME} already exists; Not touching 
existing user"
+   ewarn "due to set ACCT_USER_NO_MODIFY."
+   return 0
+   fi
+
# NB: eset* functions check current value
esethome "${ACCT_USER_NAME}" "${ACCT_USER_HOME}"
esetshell "${ACCT_USER_NAME}" "${ACCT_USER_SHELL}"
-- 
2.30.0




Re: [gentoo-dev] [PATCH v2] acct-user.eclass: allow opt-out of user modification

2021-01-08 Thread Michał Górny
On Fri, 2021-01-08 at 22:05 +0100, Thomas Deutschmann wrote:
> On 2021-01-08 21:58, Michał Górny wrote:
> > > +# @ECLASS-VARIABLE: ACCT_USER_ALREADY_EXISTS
> > > +# @INTERNAL
> > > +# @DESCRIPTION:
> > > +# Status variable which indicates if user already exists.
> > 
> > Please prefix internal variables with an underscore.
> 
> You mean renaming ACCT_USER_ALREADY_EXISTS to _ACCT_USER_ALREADY_EXISTS?

Yes.

> 
> Then _ACCT_USER_ALREADY_EXISTS would deviate from ACCT_USER_NAME which 
> has no underscore prefix and is also marked as internal variable.
> 
> Or should I fix both?

ACCT_USER_NAME is a 'visible' variable.  I probably shouldn't have
marked it internal.

-- 
Best regards,
Michał Górny





Re: [gentoo-dev] [PATCH v2] acct-user.eclass: allow opt-out of user modification

2021-01-08 Thread Thomas Deutschmann

On 2021-01-08 21:58, Michał Górny wrote:

+# @ECLASS-VARIABLE: ACCT_USER_ALREADY_EXISTS
+# @INTERNAL
+# @DESCRIPTION:
+# Status variable which indicates if user already exists.


Please prefix internal variables with an underscore.


You mean renaming ACCT_USER_ALREADY_EXISTS to _ACCT_USER_ALREADY_EXISTS?

Then _ACCT_USER_ALREADY_EXISTS would deviate from ACCT_USER_NAME which 
has no underscore prefix and is also marked as internal variable.


Or should I fix both?


--
Regards,
Thomas Deutschmann / Gentoo Linux Developer
fpr: C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5



OpenPGP_signature
Description: OpenPGP digital signature


Re: [gentoo-dev] [PATCH v2] acct-user.eclass: allow opt-out of user modification

2021-01-08 Thread Michał Górny
On Fri, 2021-01-08 at 21:19 +0100, Thomas Deutschmann wrote:
> In some setups where users are changed/managed not only via ebuilds,
> for example through configuration management systems, it could be
> problematic if acct-user.eclass will restore user/group settings
> to values set in ebuild.
> 
> Setting ACCT_USER_NO_MODIFY to a non-zero value will allow system
> administrator to disable modification of any existing user.
> 
> Note: Lock/unlock when acct-* package will be installed/removed
>   will still happen.
> 
> Signed-off-by: Thomas Deutschmann 
> ---
> 
>  v2: Keep current behavior; Add opt-out
> 
>  eclass/acct-user.eclass | 25 +
>  1 file changed, 25 insertions(+)
> 
> diff --git a/eclass/acct-user.eclass b/eclass/acct-user.eclass
> index 47890e48409a..560ae6b0ac90 100644
> --- a/eclass/acct-user.eclass
> +++ b/eclass/acct-user.eclass
> @@ -72,6 +72,11 @@ readonly ACCT_USER_NAME
>  # Overlays should set this to -1 to dynamically allocate UID.  Using -1
>  # in ::gentoo is prohibited by policy.
>  
> 
> 
> 
> +# @ECLASS-VARIABLE: ACCT_USER_ALREADY_EXISTS
> +# @INTERNAL
> +# @DESCRIPTION:
> +# Status variable which indicates if user already exists.

Please prefix internal variables with an underscore.

> +
>  # @ECLASS-VARIABLE: ACCT_USER_ENFORCE_ID
>  # @DESCRIPTION:
>  # If set to a non-null value, the eclass will require the user to have
> @@ -79,6 +84,12 @@ readonly ACCT_USER_NAME
>  # the UID is taken by another user, the install will fail.
>  : ${ACCT_USER_ENFORCE_ID:=}
>  
> 
> 
> 
> 
> 
> 
> 
> +# @ECLASS-VARIABLE: ACCT_USER_NO_MODIFY
> +# @DESCRIPTION:
> +# If set to a non-null value, the eclass will not make any changes
> +# to an already existing user.
> +: ${ACCT_USER_NO_MODIFY:=}

@DEFAULT_UNSET would be better.

> +
>  # @ECLASS-VARIABLE: ACCT_USER_SHELL
>  # @DESCRIPTION:
>  # The shell to use for the user.  If not specified, a 'nologin' variant
> @@ -344,6 +355,13 @@ acct-user_src_install() {
>  acct-user_pkg_preinst() {
>   debug-print-function ${FUNCNAME} "${@}"
>  
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> + # check if user already exists
> + ACCT_USER_ALREADY_EXISTS=
> + if [[ -n $(egetent passwd "${ACCT_USER_NAME}") ]]; then
> + ACCT_USER_ALREADY_EXISTS=yes
> + fi
> + readonly ACCT_USER_ALREADY_EXISTS
> +
>   local groups=${ACCT_USER_GROUPS[*]}
>   enewuser ${ACCT_USER_ENFORCE_ID:+-F} -M "${ACCT_USER_NAME}" \
>   "${ACCT_USER_ID}" "${ACCT_USER_SHELL}" "${ACCT_USER_HOME}" \
> @@ -379,6 +397,13 @@ acct-user_pkg_postinst() {
>   return 0
>   fi
>  
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> + if [[ -n ${ACCT_USER_NO_MODIFY} && -n ${ACCT_USER_ALREADY_EXISTS} ]] ; 
> then
> + eunlockuser "${ACCT_USER_NAME}"
> +
> + ewarn "User ${ACCT_USER_NAME} already exists; Not touching 
> existing user due to set ACCT_USER_NO_MODIFY."

I think you need to wrap the message, it seems to exceed 80 chars.

> + return 0
> + fi
> +
>   # NB: eset* functions check current value
>   esethome "${ACCT_USER_NAME}" "${ACCT_USER_HOME}"
>   esetshell "${ACCT_USER_NAME}" "${ACCT_USER_SHELL}"

-- 
Best regards,
Michał Górny





Re: [gentoo-dev] Suggestion: Trying to locate and remove unused dev- & media-libs?

2021-01-08 Thread Andreas K . Hüttel
Am Freitag, 8. Januar 2021, 14:26:32 EET schrieb Joonas Niilola:

> # Now my question is, does anyone find any of these packages useful?
> Should we go ahead and last-rite them, since it doesn't seem useful to
> carry these in Gentoo? The ones broken are heading towards last-riting
> nevertheless.

We have done such cleanups in the past. Libraries without consumers in the 
Gentoo tree make in general only limited sense.

That said, if they build and have an active maintainer, why not keep them for 
now.

This is more or less a cost/benefit question.

> 
> # So the final list of "useless" libs is:
> dev-libs/atcore
> dev-libs/bcm2835
> dev-libs/bitset
> dev-libs/boost-mpl-cartesian_product
> dev-libs/caliper
> dev-libs/clhpp
> dev-libs/distorm64
> dev-libs/editline
> dev-libs/faxpp
> dev-libs/go-usb
> dev-libs/gtx
> dev-libs/igraph
> dev-libs/ilbc-rfc3951
> dev-libs/injeqt
> dev-libs/jthread
> dev-libs/kqoauth
> dev-libs/libdivsufsort
> dev-libs/libdnsres
> dev-libs/libezV24
> dev-libs/libgcrypt-compat
> dev-libs/libpcre-debian
> dev-libs/libtomfloat
> dev-libs/libtompoly
> dev-libs/libtreadstone
> dev-libs/log4sh
> dev-libs/nss-pem
> dev-libs/OpenSRF
> dev-libs/pigpio
> dev-libs/processor-trace
> dev-libs/rapidxml
> dev-libs/redland-bindings
> dev-libs/rinutils
> dev-libs/rocm-hostcall
> dev-libs/smack
> dev-libs/squareball
> dev-libs/ustr
> dev-libs/vc-intrinsics
> dev-libs/xbyak
> dev-libs/zookeeper-c
> media-libs/cimg
> media-libs/elles_icc_profiles
> media-libs/esdl
> media-libs/fluidsynth-dssi
> media-libs/freeverb3
> media-libs/gmtk
> media-libs/gnonlin
> media-libs/guilib
> media-libs/intel-mediasdk
> media-libs/kodi-platform
> media-libs/libggigcp
> media-libs/libggimisc
> media-libs/libgroove
> media-libs/liblingoteach
> media-libs/libyami
> media-libs/memphis
> media-libs/noise-suppression-for-voice
> media-libs/raul
> media-libs/sdl-terminal
> media-libs/volpack
> 
> 
> -- juippis


-- 
Andreas K. Hüttel
dilfri...@gentoo.org
Gentoo Linux developer 
(council, qa, toolchain, base-system, perl, libreoffice)

signature.asc
Description: This is a digitally signed message part.


[gentoo-dev] [PATCH v2] acct-user.eclass: allow opt-out of user modification

2021-01-08 Thread Thomas Deutschmann
In some setups where users are changed/managed not only via ebuilds,
for example through configuration management systems, it could be
problematic if acct-user.eclass will restore user/group settings
to values set in ebuild.

Setting ACCT_USER_NO_MODIFY to a non-zero value will allow system
administrator to disable modification of any existing user.

Note: Lock/unlock when acct-* package will be installed/removed
  will still happen.

Signed-off-by: Thomas Deutschmann 
---

 v2: Keep current behavior; Add opt-out

 eclass/acct-user.eclass | 25 +
 1 file changed, 25 insertions(+)

diff --git a/eclass/acct-user.eclass b/eclass/acct-user.eclass
index 47890e48409a..560ae6b0ac90 100644
--- a/eclass/acct-user.eclass
+++ b/eclass/acct-user.eclass
@@ -72,6 +72,11 @@ readonly ACCT_USER_NAME
 # Overlays should set this to -1 to dynamically allocate UID.  Using -1
 # in ::gentoo is prohibited by policy.
 
+# @ECLASS-VARIABLE: ACCT_USER_ALREADY_EXISTS
+# @INTERNAL
+# @DESCRIPTION:
+# Status variable which indicates if user already exists.
+
 # @ECLASS-VARIABLE: ACCT_USER_ENFORCE_ID
 # @DESCRIPTION:
 # If set to a non-null value, the eclass will require the user to have
@@ -79,6 +84,12 @@ readonly ACCT_USER_NAME
 # the UID is taken by another user, the install will fail.
 : ${ACCT_USER_ENFORCE_ID:=}
 
+# @ECLASS-VARIABLE: ACCT_USER_NO_MODIFY
+# @DESCRIPTION:
+# If set to a non-null value, the eclass will not make any changes
+# to an already existing user.
+: ${ACCT_USER_NO_MODIFY:=}
+
 # @ECLASS-VARIABLE: ACCT_USER_SHELL
 # @DESCRIPTION:
 # The shell to use for the user.  If not specified, a 'nologin' variant
@@ -344,6 +355,13 @@ acct-user_src_install() {
 acct-user_pkg_preinst() {
debug-print-function ${FUNCNAME} "${@}"
 
+   # check if user already exists
+   ACCT_USER_ALREADY_EXISTS=
+   if [[ -n $(egetent passwd "${ACCT_USER_NAME}") ]]; then
+   ACCT_USER_ALREADY_EXISTS=yes
+   fi
+   readonly ACCT_USER_ALREADY_EXISTS
+
local groups=${ACCT_USER_GROUPS[*]}
enewuser ${ACCT_USER_ENFORCE_ID:+-F} -M "${ACCT_USER_NAME}" \
"${ACCT_USER_ID}" "${ACCT_USER_SHELL}" "${ACCT_USER_HOME}" \
@@ -379,6 +397,13 @@ acct-user_pkg_postinst() {
return 0
fi
 
+   if [[ -n ${ACCT_USER_NO_MODIFY} && -n ${ACCT_USER_ALREADY_EXISTS} ]] ; 
then
+   eunlockuser "${ACCT_USER_NAME}"
+
+   ewarn "User ${ACCT_USER_NAME} already exists; Not touching 
existing user due to set ACCT_USER_NO_MODIFY."
+   return 0
+   fi
+
# NB: eset* functions check current value
esethome "${ACCT_USER_NAME}" "${ACCT_USER_HOME}"
esetshell "${ACCT_USER_NAME}" "${ACCT_USER_SHELL}"
-- 
2.30.0




Re: [gentoo-dev] Last-rites: sys-power/pm-utils, sys-power/pm-quirks, app-admin/cgmanager and sys-libs/libnih

2021-01-08 Thread Alexey Mishustin
Hi,

Here is a forum thread that I started for this topic:

https://forums.gentoo.org/viewtopic-p-8557255.html#8557255

-- 
Best regards,
Alex



Re: [gentoo-dev] [PATCH] acct-user.eclass: don't modify existing user by default

2021-01-08 Thread Mike Gilbert
On Fri, Jan 8, 2021 at 1:31 PM Michał Górny  wrote:
> Again, I don't understand why you continue escalating this.  I have
> already indicated that I'm fine with adding an option to disable this,
> given that 1) the current behavior remains the default, and 2) people
> are given big fat warning that they are now responsible for updating
> their users (and ideally 3) the eclass tells user how to update
> the user).  I've just asked for the option to override values via
> make.conf goes first since that is the preferred solution that doesn't
> destroy the foundations of GLEP 81.
>
> floppym has indicated an interest in this, so I've presumed he's going
> to submit an updated patch to the ml.

Sorry, I didn't mean to give that impression. I do not have any plans
to submit patches myself. I asked if you would accept a similar patch
to clarify your position for others (including Whissi) who may want to
contribute.



Re: [gentoo-dev] [PATCH] vala.eclass: make has_version aware of ROOT for EAPI 7

2021-01-08 Thread David Michael
On Thu, Jan 7, 2021 at 3:42 AM Mart Raudsepp  wrote:
> Ühel kenal päeval, K, 06.01.2021 kell 19:27, kirjutas Matt Turner:
> > From: David Michael 
> > The vala dependencies are declared in BDEPEND since EAPI 7 so that
> > the valac command is natively executable.  With no arguments, the
> > has_version function would look for a cross-compiled vala package
> > in the target ROOT and always fail.
>
> I'm not exactly convinced that vapi stuff is arch independent and
> belongs in BDEPEND over DEPEND. Vala ships a lot of .vapi files along
> with valac that get used on compilation. Though the difference might be
> only when different endianness or size_of int

If there are target-specific files that need to be installed via
DEPEND, vala would still need to be installed in BDEPEND so that there
is an executable valac command, right?

In practice, I don't think DEPEND usage matters yet because vala
support seems to require gobject-introspection, which is virtually
impossible to cross-compile.  (I plan to implement something like
Void[0] locally to try it some time.)

This patch is to fix packages like ibus[1] that depend on vala
regardless of my disabling the USE flag, where the current eclass
behavior unconditionally fails.

Thanks.

David

[0] https://maxice8.github.io/8-cross-the-gir
[1] 
https://github.com/gentoo/gentoo/blob/master/app-i18n/ibus/ibus-1.5.23.ebuild#L80



Re: [gentoo-dev] [PATCH] acct-user.eclass: don't modify existing user by default

2021-01-08 Thread Michał Górny
On Fri, 2021-01-08 at 19:23 +0100, Thomas Deutschmann wrote:
> On 2021-01-08 19:14, Michał Górny wrote:
> > The one floppym suggested, i.e. the same as sent patch but with
> > the default staying on the current behavior.
> 
> Do I understand correctly? You are willing to accept my patch but with
> 
>  > ACCT_USER_ALLOW_EXISTING_USER_TO_BE_MODIFIED
> 
> defaulting to a non-zero value to keep current behavior?
> 
> This would be an acceptable compromise for me like it would allow users 
> like me at least to opt-out. I would still try to convince Gentoo to 
> change the default later because I believe this is a bad default but of 
> course I would accept any voting results on this implementation detail.

In principle, yes.  However, when such a patch is sent I may have more
requests.  For a start, shorter variable name, say, ACCT_USER_NO_MODIFY
or ACCT_USER_NO_UPDATE.

-- 
Best regards,
Michał Górny





Re: [gentoo-dev] [PATCH] acct-user.eclass: don't modify existing user by default

2021-01-08 Thread Michał Górny
On Fri, 2021-01-08 at 19:10 +0100, Thomas Deutschmann wrote:
> On 2021-01-08 18:06, Mike Gilbert wrote:
> > I disagree with your premise: I argue that the eclass is not "broken",
> > and the code works as designed. You just don't like aspects of its
> > design.
> 
> Several people, not just me... *users*, other devs like robbat2 and 
> antarus, all with experience in maintaining multiple systems not just as 
> a hobby, have expressed that the current design has a flaw.

They did.  What you're neglecting to repeat is that they've also
indicated that your proposed design is flawed as well.  You're
conflating 'design A is flawed' into 'design B is better', while they
really said 'both design A and B are flawed'.

> I got feedback from other devs representing a large group in Gentoo and 
> they all agree on the problem. They haven't spoken up yet because they 
> don't care because the way how they use Gentoo is stateless.
> 
> So why the hell is it acceptable for a small group (you and mgorny, 
> Michael told me already last year that he will be fine with an opt-in 
> change and I assume his opinion hasn't changed) to cause problems for 
> another group just because you don't want to acknowledge the problem?

So what's you're basically saying is that there are people who like
behavior A, people who like behavior B and people who don't care. 
Somehow you manage -- without any hard evidence -- to claim that people
who dislike the current behavior are more numerous than the people who
like the current behavior, and also implicitly count people who don't
care towards them (why?).  Even if you managed to prove that (how?), is
this really a popularity contest?

The current behavior has been the default for 1.5 years.  There are
ebuilds that literally depend on it.  If you are going to change that,
then you need to prove that 1) your proposed solution is much better for
the vast majority of Gentoo users (again, how?), and 2) that the benefit
from the change in behavior outweighs its costs.  And given that you've
pretty much admitted that the majority probably 'does not care', then 2)
is not met.

> Even soap, not sure if he has spoken for himself or as QA lead, has 
> acknowledged in this thread that we need a mechanism to disable this 
> behavior.
> 
> Is it really not possible to solve this technical problem? Do we have to 
> escalate and need a vote or something to replace entire GLEP 81 with 
> something new just because a group believes there is no flaw and 
> everyone else having problems are doing things wrong so this group is 
> rejecting any attempts to address the problem?

Again, I don't understand why you continue escalating this.  I have
already indicated that I'm fine with adding an option to disable this,
given that 1) the current behavior remains the default, and 2) people
are given big fat warning that they are now responsible for updating
their users (and ideally 3) the eclass tells user how to update
the user).  I've just asked for the option to override values via
make.conf goes first since that is the preferred solution that doesn't
destroy the foundations of GLEP 81.

floppym has indicated an interest in this, so I've presumed he's going
to submit an updated patch to the ml.


-- 
Best regards,
Michał Górny





Re: [gentoo-dev] [PATCH] acct-user.eclass: don't modify existing user by default

2021-01-08 Thread Thomas Deutschmann

On 2021-01-08 19:14, Michał Górny wrote:

The one floppym suggested, i.e. the same as sent patch but with
the default staying on the current behavior.


Do I understand correctly? You are willing to accept my patch but with

> ACCT_USER_ALLOW_EXISTING_USER_TO_BE_MODIFIED

defaulting to a non-zero value to keep current behavior?

This would be an acceptable compromise for me like it would allow users 
like me at least to opt-out. I would still try to convince Gentoo to 
change the default later because I believe this is a bad default but of 
course I would accept any voting results on this implementation detail.



--
Regards,
Thomas Deutschmann / Gentoo Linux Developer
fpr: C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5



OpenPGP_signature
Description: OpenPGP digital signature


Re: [gentoo-dev] [PATCH] acct-user.eclass: don't modify existing user by default

2021-01-08 Thread Michał Górny
On Fri, 2021-01-08 at 19:11 +0100, Fabian Groffen wrote:
> On 04-01-2021 17:14:47 +0100, Michał Górny wrote:
> > Yes, I don't mind an option, as long as it spews a big fat ewarn that
> > the user loses the right to support.  However, that's still not
> > the right solution to the immediate problem, and I'm currently working
> > on a better patch, so I'd prefer if you waited with that to avoid merge
> > conflicts.
> 
> Could you please share your intended approach?

The one floppym suggested, i.e. the same as sent patch but with
the default staying on the current behavior.

-- 
Best regards,
Michał Górny





Re: [gentoo-dev] [PATCH] acct-user.eclass: don't modify existing user by default

2021-01-08 Thread Fabian Groffen
On 04-01-2021 17:14:47 +0100, Michał Górny wrote:
> Yes, I don't mind an option, as long as it spews a big fat ewarn that
> the user loses the right to support.  However, that's still not
> the right solution to the immediate problem, and I'm currently working
> on a better patch, so I'd prefer if you waited with that to avoid merge
> conflicts.

Could you please share your intended approach?

Thanks,
Fabian

-- 
Fabian Groffen
Gentoo on a different level


signature.asc
Description: PGP signature


Re: [gentoo-dev] [PATCH] acct-user.eclass: don't modify existing user by default

2021-01-08 Thread Thomas Deutschmann

On 2021-01-08 18:06, Mike Gilbert wrote:

I disagree with your premise: I argue that the eclass is not "broken",
and the code works as designed. You just don't like aspects of its
design.


Several people, not just me... *users*, other devs like robbat2 and 
antarus, all with experience in maintaining multiple systems not just as 
a hobby, have expressed that the current design has a flaw.


I got feedback from other devs representing a large group in Gentoo and 
they all agree on the problem. They haven't spoken up yet because they 
don't care because the way how they use Gentoo is stateless.


So why the hell is it acceptable for a small group (you and mgorny, 
Michael told me already last year that he will be fine with an opt-in 
change and I assume his opinion hasn't changed) to cause problems for 
another group just because you don't want to acknowledge the problem?


Even soap, not sure if he has spoken for himself or as QA lead, has 
acknowledged in this thread that we need a mechanism to disable this 
behavior.


Is it really not possible to solve this technical problem? Do we have to 
escalate and need a vote or something to replace entire GLEP 81 with 
something new just because a group believes there is no flaw and 
everyone else having problems are doing things wrong so this group is 
rejecting any attempts to address the problem?



--
Regards,
Thomas Deutschmann / Gentoo Linux Developer
fpr: C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5



OpenPGP_signature
Description: OpenPGP digital signature


Re: [gentoo-dev] Suggestion: Trying to locate and remove unused dev- & media-libs?

2021-01-08 Thread Andreas Sturmlechner
On Freitag, 8. Januar 2021 13:26:32 CET Joonas Niilola wrote:
> # So the final list of "useless" libs is:
> dev-libs/atcore

This has IUSE="gui", EAPI=7 and kde proj as maintainer. Please keep.

Regards

signature.asc
Description: This is a digitally signed message part.


Re: [gentoo-dev] Suggestion: Trying to locate and remove unused dev- & media-libs?

2021-01-08 Thread Joonas Niilola


On 1/8/21 5:42 PM, Thomas Deutschmann wrote:
> Hi,
>
> I wonder how you composed this list. If you just checked if there is
> any revdep, the check was probably useless:
>
> For example,
>
>> dev-libs/cyberjack
>
> is up-to-date, has an active dev as maintainer and is required for any
> ReinerSCT chipcard reader.
>
>
Hey,

I admit the motivation didn't come clear from the first post. I believe
majority of listed packages to be leftovers from previous removals, thus
being "useless" to us now. I also admit to checking git logs for only a
handful of packages, and left few active+useful ones out from the list
already. This is a genuine inquiry to find out if these libs are somehow
useful for someone, not a "last-rites call for action" post ;)

Although I probably will continue to look for the really outdated,
EAPI-5 etc ones after a certain period of time.

-- juippis



OpenPGP_signature
Description: OpenPGP digital signature


Re: [gentoo-dev] [PATCH] acct-user.eclass: don't modify existing user by default

2021-01-08 Thread Michał Górny
On Fri, 2021-01-08 at 17:29 +0100, Thomas Deutschmann wrote:
> On 2021-01-08 17:03, Mike Gilbert wrote:
> > I strongly object to you pushing this patch as-is. There have been
> > plenty of non-technical objections, including from the eclass
> > maintainer.
> 
> The eclass maintainer has disqualified himself going into a technical 
> debate with saying
> 
> > So, over my dead commit access.
> 
> in his first posting.

Please remind me, who granted your the power to disqualify maintainers?

> This is a technical mailing list. Currently, acct-* stuff is breaking 
> stuff. Nobody has challenged this yet.

No, it is not.  It is behaving as described.  What really happens is
that you rejected the design, deliberately broke your system and now are
trying to push your design over false arguments.

> It's not like we cannot address the other stuff later. It's about 
> getting the fix down to users who are currently affected by this. So why 
> take hostage when some user(s) ignore the problem for more than a year 
> and show that they are not interested in collaboration to find a 
> solution for a technical problem they created despite warnings before 
> this went live?

Yes, surely me abandoning other work to provide a patch on the same day
proves that I am 'not interested in collaboration to find a solution'.


-- 
Best regards,
Michał Górny





Re: [gentoo-dev] [PATCH] acct-user.eclass: don't modify existing user by default

2021-01-08 Thread Mike Gilbert
On Fri, Jan 8, 2021 at 11:29 AM Thomas Deutschmann  wrote:
> This is a technical mailing list. Currently, acct-* stuff is breaking
> stuff. Nobody has challenged this yet.
>
> Now I proposed a way how to unbreak stuff.
>
> Please tell me why we should keep broken stuff for non-technical reason
> and cause harm for those who are affected?

I disagree with your premise: I argue that the eclass is not "broken",
and the code works as designed. You just don't like aspects of its
design.

If you want to change the design, you need buy-in from the maintainer,
or you need to override him.



Re: [gentoo-dev] Suggestion: Trying to locate and remove unused dev- & media-libs?

2021-01-08 Thread Matt Turner
On Fri, Jan 8, 2021 at 7:27 AM Joonas Niilola  wrote:
> dev-libs/clhpp

We want to keep this, though I admit I don't recall why nothing depends on it.



Re: [gentoo-dev] [PATCH] acct-user.eclass: don't modify existing user by default

2021-01-08 Thread Mike Gilbert
On Fri, Jan 8, 2021 at 11:29 AM Thomas Deutschmann  wrote:
>
> On 2021-01-08 17:03, Mike Gilbert wrote:
> > I strongly object to you pushing this patch as-is. There have been
> > plenty of non-technical objections, including from the eclass
> > maintainer.
>
> The eclass maintainer has disqualified himself going into a technical
> debate with saying
>
> > So, over my dead commit access.
>
> in his first posting.
>
> This is a technical mailing list. Currently, acct-* stuff is breaking
> stuff. Nobody has challenged this yet.
>
> Now I proposed a way how to unbreak stuff.
>
> Please tell me why we should keep broken stuff for non-technical reason
> and cause harm for those who are affected?
>
> It's not like we cannot address the other stuff later. It's about
> getting the fix down to users who are currently affected by this. So why
> take hostage when some user(s) ignore the problem for more than a year
> and show that they are not interested in collaboration to find a
> solution for a technical problem they created despite warnings before
> this went live?
>
> Of course, if you are not affected by this problem it is very easy to
> relax and sit back. You have all the time in the world... but when you
> are affected by this at large scale it is not that funny anymore.

Let me put it this way: if you push this without agreement from the
maintainer, QA, or council, you can probably expect a swift revert.



Re: [gentoo-dev] Suggestion: Trying to locate and remove unused dev- & media-libs?

2021-01-08 Thread Thomas Deutschmann

Hi,

please forget my previous mail. I was informed that I misread your mail, 
sorry about that!



--
Regards,
Thomas Deutschmann / Gentoo Linux Developer
fpr: C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5



OpenPGP_signature
Description: OpenPGP digital signature


Re: [gentoo-dev] [PATCH] acct-user.eclass: don't modify existing user by default

2021-01-08 Thread Thomas Deutschmann

On 2021-01-08 17:03, Mike Gilbert wrote:

I strongly object to you pushing this patch as-is. There have been
plenty of non-technical objections, including from the eclass
maintainer.


The eclass maintainer has disqualified himself going into a technical 
debate with saying



So, over my dead commit access.


in his first posting.


This is a technical mailing list. Currently, acct-* stuff is breaking 
stuff. Nobody has challenged this yet.


Now I proposed a way how to unbreak stuff.

Please tell me why we should keep broken stuff for non-technical reason 
and cause harm for those who are affected?


It's not like we cannot address the other stuff later. It's about 
getting the fix down to users who are currently affected by this. So why 
take hostage when some user(s) ignore the problem for more than a year 
and show that they are not interested in collaboration to find a 
solution for a technical problem they created despite warnings before 
this went live?


Of course, if you are not affected by this problem it is very easy to 
relax and sit back. You have all the time in the world... but when you 
are affected by this at large scale it is not that funny anymore.



--
Regards,
Thomas Deutschmann / Gentoo Linux Developer
fpr: C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5



OpenPGP_signature
Description: OpenPGP digital signature


Re: [gentoo-dev] [PATCH] acct-user.eclass: don't modify existing user by default

2021-01-08 Thread Mike Gilbert
On Fri, Jan 8, 2021 at 10:48 AM Thomas Deutschmann  wrote:
>
> Hi,
>
> since nobody posted any technical objections, I am going to push the
> proposed patch on Saturday to address the current issue and allow any
> professional Gentoo user relying on usermod/configuration management
> tool to move on.

I strongly object to you pushing this patch as-is. There have been
plenty of non-technical objections, including from the eclass
maintainer.



Re: [gentoo-dev] [PATCH] acct-user.eclass: don't modify existing user by default

2021-01-08 Thread Thomas Deutschmann

Hi,

since nobody posted any technical objections, I am going to push the 
proposed patch on Saturday to address the current issue and allow any 
professional Gentoo user relying on usermod/configuration management 
tool to move on.


If someone will spend time on further improvements like implementing the 
idea outlined by Robin or what Michael said about /etc/users.d and 
user-update tool, this is highly appreciated but will probably not 
happen anytime soon.



--
Regards,
Thomas Deutschmann / Gentoo Linux Developer
fpr: C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5



OpenPGP_signature
Description: OpenPGP digital signature


Re: [gentoo-dev] Suggestion: Trying to locate and remove unused dev- & media-libs?

2021-01-08 Thread Thomas Deutschmann

Hi,

I wonder how you composed this list. If you just checked if there is any 
revdep, the check was probably useless:


For example,


dev-libs/cyberjack


is up-to-date, has an active dev as maintainer and is required for any 
ReinerSCT chipcard reader.



--
Regards,
Thomas Deutschmann / Gentoo Linux Developer
fpr: C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5



OpenPGP_signature
Description: OpenPGP digital signature


Re: [gentoo-dev] Last-rites: sys-power/pm-utils, sys-power/pm-quirks, app-admin/cgmanager and sys-libs/libnih

2021-01-08 Thread Jaco Kroon
Hi,

On 2021/01/08 15:39, Andreas Sturmlechner wrote:
> On Freitag, 8. Januar 2021 08:10:05 CET Jaco Kroon wrote:
>> Would it be possible to point at alternatives?  pm-utils worked well for
>> me until now, and I'm fairly certain this won't be abandoned unless
>> there are other (better?) alternatives available.
>>
> It is replaced by elogind or systemd builtin functions.

Thank you.

Kind Regards,
Jaco




Re: [gentoo-dev] Last-rites: sys-power/pm-utils, sys-power/pm-quirks, app-admin/cgmanager and sys-libs/libnih

2021-01-08 Thread Andreas Sturmlechner
On Freitag, 8. Januar 2021 08:10:05 CET Jaco Kroon wrote:
> Would it be possible to point at alternatives?  pm-utils worked well for
> me until now, and I'm fairly certain this won't be abandoned unless
> there are other (better?) alternatives available.
> 

It is replaced by elogind or systemd builtin functions.

Regards

signature.asc
Description: This is a digitally signed message part.


Re: [gentoo-dev] Suggestion: Trying to locate and remove unused dev- & media-libs?

2021-01-08 Thread James Le Cuirot
On Fri, 8 Jan 2021 14:26:32 +0200
Joonas Niilola  wrote:

> dev-libs/libgcrypt-compat
> dev-libs/libpcre-debian

These are maintained by me and I'd like to keep them. They can be
pulled in by running the esteam tool in steam-overlay for games that
need them. They could potentially be used for other old or
Debian-oriented binary packages too.

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer


pgp25epsm8vEo.pgp
Description: OpenPGP digital signature


[gentoo-dev] Suggestion: Trying to locate and remove unused dev- & media-libs?

2021-01-08 Thread Joonas Niilola
# With the help of jkroon I went through all dev-libs/* and media-libs/*
packages and located each one without reverse deps,
# List of dev-libs/* and media-libs/* without any revdeps:
dev-libs/atcore
dev-libs/bcm2835
dev-libs/bemenu
dev-libs/bitset
dev-libs/boost-mpl-cartesian_product
dev-libs/caliper
dev-libs/c-capnproto
dev-libs/cgilib
dev-libs/clhpp
dev-libs/cloog
dev-libs/cyberjack
dev-libs/distorm64
dev-libs/editline
dev-libs/faxpp
dev-libs/go-usb
dev-libs/granite
dev-libs/gtx
dev-libs/igraph
dev-libs/ilbc-rfc3951
dev-libs/injeqt
dev-libs/jthread
dev-libs/keystone
dev-libs/kqoauth
dev-libs/libdivecomputer
dev-libs/libdivsufsort
dev-libs/libdnsres
dev-libs/libdynd
dev-libs/libezV24
dev-libs/libgcrypt-compat
dev-libs/libgpiod
dev-libs/liblzw
dev-libs/libmelf
dev-libs/libpcre-debian
dev-libs/libtomfloat
dev-libs/libtompoly
dev-libs/libtreadstone
dev-libs/libusbhp
dev-libs/light
dev-libs/log4sh
dev-libs/nss-pem
dev-libs/OpenSRF
dev-libs/pigpio
dev-libs/processor-trace
dev-libs/qrosscore
dev-libs/rapidxml
dev-libs/redland-bindings
dev-libs/replicant
dev-libs/rinutils
dev-libs/rocm-hostcall
dev-libs/smack
dev-libs/squareball
dev-libs/stp
dev-libs/tvision
dev-libs/ucommon
dev-libs/ustr
dev-libs/vc-intrinsics
dev-libs/weston
dev-libs/xbyak
dev-libs/zlog
dev-libs/zookeeper-c
media-libs/cimg
media-libs/elles_icc_profiles
media-libs/esdl
media-libs/fluidsynth-dssi
media-libs/freeverb3
media-libs/gmtk
media-libs/gnonlin
media-libs/guilib
media-libs/icclib
media-libs/intel-mediasdk
media-libs/jbig2enc
media-libs/kodi-platform
media-libs/libbsb
media-libs/libggigcp
media-libs/libggimisc
media-libs/libgroove
media-libs/libicns
media-libs/liblingoteach
media-libs/libmpeg3
media-libs/libmpris2client
media-libs/libsixel
media-libs/libyami
media-libs/memphis
media-libs/noise-suppression-for-voice
media-libs/phat
media-libs/raul
media-libs/sdl-terminal
media-libs/taglib-extras
media-libs/tse3
media-libs/volpack

# Following packages did not compile:
dev-libs/caliper https://bugs.gentoo.org/737106 (dev-libs/papi, a
build-dep is broken)
dev-libs/zookeeper-c https://bugs.gentoo.org/747592
media-libs/intel-mediasdk https://bugs.gentoo.org/740070

# Already package.masked:
dev-libs/ilbc-rfc3951
dev-libs/OpenSRF
dev-libs/ustr

# Following packages appear in optfeature or elog otherwise:
(none)

# These packages install binaries, emerged with USE="tools":
dev-libs/bemenu
dev-libs/c-capnproto
dev-libs/cgilib
dev-libs/cloog
dev-libs/cyberjack
dev-libs/granite
dev-libs/keystone
dev-libs/libdivecomputer
dev-libs/libdynd
dev-libs/libgpiod
dev-libs/liblzw
dev-libs/libmelf
dev-libs/libusbhp (/usr/bin/hptest)
dev-libs/light
dev-libs/qrosscore
dev-libs/replicant
dev-libs/stp
dev-libs/tvision
dev-libs/ucommon
dev-libs/weston
dev-libs/zlog
media-libs/icclib
media-libs/jbig2enc
media-libs/libbsb
media-libs/libicns
media-libs/libmpeg3
media-libs/libmpris2client
media-libs/libsixel
media-libs/phat
media-libs/taglib-extras
media-libs/tse3

# So the final list of "useless" libs is:
dev-libs/atcore
dev-libs/bcm2835
dev-libs/bitset
dev-libs/boost-mpl-cartesian_product
dev-libs/caliper
dev-libs/clhpp
dev-libs/distorm64
dev-libs/editline
dev-libs/faxpp
dev-libs/go-usb
dev-libs/gtx
dev-libs/igraph
dev-libs/ilbc-rfc3951
dev-libs/injeqt
dev-libs/jthread
dev-libs/kqoauth
dev-libs/libdivsufsort
dev-libs/libdnsres
dev-libs/libezV24
dev-libs/libgcrypt-compat
dev-libs/libpcre-debian
dev-libs/libtomfloat
dev-libs/libtompoly
dev-libs/libtreadstone
dev-libs/log4sh
dev-libs/nss-pem
dev-libs/OpenSRF
dev-libs/pigpio
dev-libs/processor-trace
dev-libs/rapidxml
dev-libs/redland-bindings
dev-libs/rinutils
dev-libs/rocm-hostcall
dev-libs/smack
dev-libs/squareball
dev-libs/ustr
dev-libs/vc-intrinsics
dev-libs/xbyak
dev-libs/zookeeper-c
media-libs/cimg
media-libs/elles_icc_profiles
media-libs/esdl
media-libs/fluidsynth-dssi
media-libs/freeverb3
media-libs/gmtk
media-libs/gnonlin
media-libs/guilib
media-libs/intel-mediasdk
media-libs/kodi-platform
media-libs/libggigcp
media-libs/libggimisc
media-libs/libgroove
media-libs/liblingoteach
media-libs/libyami
media-libs/memphis
media-libs/noise-suppression-for-voice
media-libs/raul
media-libs/sdl-terminal
media-libs/volpack

# Now my question is, does anyone find any of these packages useful?
Should we go ahead and last-rite them, since it doesn't seem useful to
carry these in Gentoo? The ones broken are heading towards last-riting
nevertheless.

-- juippis



OpenPGP_signature
Description: OpenPGP digital signature