Re: [gentoo-dev] rfc: allow -1 for ACCT_USER_ID and ACCT_GROUP_ID in ::gentoo
Hi, On 2021/12/01 08:45, Alec Warner wrote: > On Tue, Nov 30, 2021 at 10:16 PM Jaco Kroon wrote: >> Hi, >> >> On 2021/12/01 03:32, William Hubbs wrote: >>> This is the part of this that I don't understand. If we aren't enforcing >>> an ID, why do we care which ID to try first? It seems to be an >>> unnecessary step since users can pick the IDs they want by putting >>> settings in make.conf. >> Because when running clusters of hosts it's useful to have the UIDs for >> "system" users match. Yes, I know this won't match in a multi-distro >> setup, but at least for those of us with clusters consisting only of >> Gentoo hosts it will *usually* match. Changing these are possible, but >> a nuisance, so having it "just work" for the usual case is great IMHO. > So questions from my side are: > Does your cluster not have human users? In this case none. So no need for centralized database otherwise. > Do the userids for the human users also not have to match between > hosts in the cluster? In certain environments we do need that, which is where nss_ldap and friends come in. In those environments the system ids doesn't matter though, because only /home is shared :). Kind Regards, Jaco
Re: [gentoo-dev] rfc: allow -1 for ACCT_USER_ID and ACCT_GROUP_ID in ::gentoo
On Tue, Nov 30, 2021 at 10:16 PM Jaco Kroon wrote: > > Hi, > > On 2021/12/01 03:32, William Hubbs wrote: > > This is the part of this that I don't understand. If we aren't enforcing > > an ID, why do we care which ID to try first? It seems to be an > > unnecessary step since users can pick the IDs they want by putting > > settings in make.conf. > > Because when running clusters of hosts it's useful to have the UIDs for > "system" users match. Yes, I know this won't match in a multi-distro > setup, but at least for those of us with clusters consisting only of > Gentoo hosts it will *usually* match. Changing these are possible, but > a nuisance, so having it "just work" for the usual case is great IMHO. So questions from my side are: Does your cluster not have human users? Do the userids for the human users also not have to match between hosts in the cluster? -A > > If I'm not mistaken there is a setting to REQUIRE the ID, and that could > even be set from make.conf, or env/ so for those packages that we care > about that (eg, mailman running on top of glusterfs) we use that. > > Kind Regards, > Jaco > >
Re: [gentoo-dev] rfc: allow -1 for ACCT_USER_ID and ACCT_GROUP_ID in ::gentoo
Hi, On 2021/12/01 03:32, William Hubbs wrote: > This is the part of this that I don't understand. If we aren't enforcing > an ID, why do we care which ID to try first? It seems to be an > unnecessary step since users can pick the IDs they want by putting > settings in make.conf. Because when running clusters of hosts it's useful to have the UIDs for "system" users match. Yes, I know this won't match in a multi-distro setup, but at least for those of us with clusters consisting only of Gentoo hosts it will *usually* match. Changing these are possible, but a nuisance, so having it "just work" for the usual case is great IMHO. If I'm not mistaken there is a setting to REQUIRE the ID, and that could even be set from make.conf, or env/ so for those packages that we care about that (eg, mailman running on top of glusterfs) we use that. Kind Regards, Jaco
Re: [gentoo-dev] rfc: allow -1 for ACCT_USER_ID and ACCT_GROUP_ID in ::gentoo
On Tue, 2021-11-30 at 19:32 -0600, William Hubbs wrote: > > This is the part of this that I don't understand. If we aren't enforcing > an ID, why do we care which ID to try first? It seems to be an > unnecessary step since users can pick the IDs they want by putting > settings in make.conf. > This way, all new installs have consistent IDs by default. Users having to manually specify every ID on every system to have them be consistent is exactly what we are trying to avoid.
Re: [gentoo-dev] rfc: allow -1 for ACCT_USER_ID and ACCT_GROUP_ID in ::gentoo
On Tue, Nov 30, 2021 at 12:59:18PM +0100, Ulrich Mueller wrote: > > On Tue, 30 Nov 2021, James Cloos wrote: > > > "UM" == Ulrich Mueller writes: > UM> Also, why would one allocate UIDs in the 500..999 range (1000 is fine, > UM> actually)? Gentoo always had UID_MIN=1000 and SYS_UID_MAX=999. > > > why do you thing gentoo is everyone's first or only dist on their > > network? > > > or even on any given box? > > I was specifically asking about Gentoo infra there. > > > forcing existing boxen to change just because a new dist is added > > is also unacceptable. > > > for me though, it would be enough if there is something i can add to > > make.conf to ensure that the acct-user and acct-group builds avoid the > > ranges i already use. > > > that may also work for others. > > UIDs in the range SYS_UID_MIN..SYS_UID_MAX (i.e. 101..999) were always > used for dynamic allocation of system accounts. GLEP 81 hasn't really > changed anything there, except that the ebuild will now suggest an ID to > try first. This is the part of this that I don't understand. If we aren't enforcing an ID, why do we care which ID to try first? It seems to be an unnecessary step since users can pick the IDs they want by putting settings in make.conf. William signature.asc Description: PGP signature
[gentoo-dev] [PATCH] tmpfiles.eclass: add eapi 8 support
Signed-off-by: William Hubbs
---
eclass/tmpfiles.eclass | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/eclass/tmpfiles.eclass b/eclass/tmpfiles.eclass
index b9238a6434a..7a0e2cb7265 100644
--- a/eclass/tmpfiles.eclass
+++ b/eclass/tmpfiles.eclass
@@ -8,7 +8,7 @@
# @AUTHOR:
# Mike Gilbert
# William Hubbs
-# @SUPPORTED_EAPIS: 5 6 7
+# @SUPPORTED_EAPIS: 5 6 7 8
# @BLURB: Functions related to tmpfiles.d files
# @DESCRIPTION:
# This eclass provides functionality related to installing and
@@ -56,7 +56,7 @@ if [[ -z ${TMPFILES_ECLASS} ]]; then
TMPFILES_ECLASS=1
case "${EAPI}" in
-5|6|7) ;;
+5|6|7|8) ;;
*) die "API is undefined for EAPI ${EAPI}" ;;
esac
--
2.32.0
Re: [gentoo-dev] rfc: allow -1 for ACCT_USER_ID and ACCT_GROUP_ID in ::gentoo
> "UM" == Ulrich Mueller writes: UM> I was specifically asking about Gentoo infra there. ah; i completely missed that bit. sorry for the misunderstanding. -JimC -- James Cloos OpenPGP: 0x997A9F17ED7DAEA6
[gentoo-dev] [RFC] dissolving project netmon
Dear all, the project netmon is openly discussed as "dead" since years. We should not blame its members, but the fact that the packages in netmon are very different and should not be clustered in one project. Thanks to everyone who helped out with bugs assigned to netmon. I suggest to reassign the netmon packages to m-n. This will motivate others to grab the packages and reflect the real status. Are there any objections to dissolving netmon? -- Best, Jonas
Re: [gentoo-dev] [PATCH 1/2] pam.eclass: Support EAPI-8, add missing || die
On 30.11.2021 18:01, Andreas Sturmlechner wrote:
Closes: https://bugs.gentoo.org/811363
---
eclass/pam.eclass | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/eclass/pam.eclass b/eclass/pam.eclass
index 0b3421b5e7c..effd17ad55d 100644
--- a/eclass/pam.eclass
+++ b/eclass/pam.eclass
@@ -6,14 +6,14 @@
# Mikle Kolyada
# @AUTHOR:
# Diego Pettenò
-# @SUPPORTED_EAPIS: 5 6 7
+# @SUPPORTED_EAPIS: 5 6 7 8
# @BLURB: Handles pam related tasks
# @DESCRIPTION:
# This eclass contains functions to install pamd configuration files and
# pam modules.
case ${EAPI:-0} in
- [567]) ;;
+ [5678]) ;;
*) die "${ECLASS}: EAPI ${EAPI:-0} not supported" ;;
esac
@@ -209,7 +209,7 @@ pamd_mimic() {
cleanpamd() {
while [[ -n $1 ]]; do
if ! has_version sys-libs/pam; then
- sed -i -e '/pam_shells\|pam_console/s:^:#:' "${D}/etc/
pam.d/$1"
+ sed -i -e '/pam_shells\|pam_console/s:^:#:' "${D}/etc/
pam.d/$1" || die
fi
shift
Actually there are few more modifications that need to be made to the
current code, I have this in my TODO until the end of December.
[gentoo-dev] last rites: net-vpn/badvpn
# William Hubbs (2021-11-30) # Dead upstream, no releases since 2015 # Bug #770619; masked for removal on 2021-12-30. net-vpn/badvpn Thanks, William signature.asc Description: PGP signature
[gentoo-dev] [PATCH 2/2] pam.eclass: Drop EAPI-5 support
No more consumers for some time.
---
eclass/pam.eclass | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/eclass/pam.eclass b/eclass/pam.eclass
index effd17ad55d..38326682b3f 100644
--- a/eclass/pam.eclass
+++ b/eclass/pam.eclass
@@ -6,14 +6,14 @@
# Mikle Kolyada
# @AUTHOR:
# Diego Pettenò
-# @SUPPORTED_EAPIS: 5 6 7 8
+# @SUPPORTED_EAPIS: 6 7 8
# @BLURB: Handles pam related tasks
# @DESCRIPTION:
# This eclass contains functions to install pamd configuration files and
# pam modules.
case ${EAPI:-0} in
- [5678]) ;;
+ [678]) ;;
*) die "${ECLASS}: EAPI ${EAPI:-0} not supported" ;;
esac
--
2.34.1
signature.asc
Description: This is a digitally signed message part.
[gentoo-dev] [PATCH 1/2] pam.eclass: Support EAPI-8, add missing || die
Closes: https://bugs.gentoo.org/811363
---
eclass/pam.eclass | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/eclass/pam.eclass b/eclass/pam.eclass
index 0b3421b5e7c..effd17ad55d 100644
--- a/eclass/pam.eclass
+++ b/eclass/pam.eclass
@@ -6,14 +6,14 @@
# Mikle Kolyada
# @AUTHOR:
# Diego Pettenò
-# @SUPPORTED_EAPIS: 5 6 7
+# @SUPPORTED_EAPIS: 5 6 7 8
# @BLURB: Handles pam related tasks
# @DESCRIPTION:
# This eclass contains functions to install pamd configuration files and
# pam modules.
case ${EAPI:-0} in
- [567]) ;;
+ [5678]) ;;
*) die "${ECLASS}: EAPI ${EAPI:-0} not supported" ;;
esac
@@ -209,7 +209,7 @@ pamd_mimic() {
cleanpamd() {
while [[ -n $1 ]]; do
if ! has_version sys-libs/pam; then
- sed -i -e '/pam_shells\|pam_console/s:^:#:' "${D}/etc/
pam.d/$1"
+ sed -i -e '/pam_shells\|pam_console/s:^:#:' "${D}/etc/
pam.d/$1" || die
fi
shift
--
2.34.1
signature.asc
Description: This is a digitally signed message part.
[gentoo-dev] Last-rites: dev-python/python-fcl
# Andreas Sturmlechner (2021-11-30) # Blocks cleanup of sci-libs/fcl-0.5.0, unmaintained in Gentoo. # Upstream master claims to target sci-libs/fcl-0.6.1, but that # requires someone adopting the package. # Bug #770589; masked for removal on 2021-12-30. dev-python/python-fcl signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] rfc: allow -1 for ACCT_USER_ID and ACCT_GROUP_ID in ::gentoo
> On Tue, 30 Nov 2021, James Cloos wrote: > "UM" == Ulrich Mueller writes: UM> Also, why would one allocate UIDs in the 500..999 range (1000 is fine, UM> actually)? Gentoo always had UID_MIN=1000 and SYS_UID_MAX=999. > why do you thing gentoo is everyone's first or only dist on their > network? > or even on any given box? I was specifically asking about Gentoo infra there. > forcing existing boxen to change just because a new dist is added > is also unacceptable. > for me though, it would be enough if there is something i can add to > make.conf to ensure that the acct-user and acct-group builds avoid the > ranges i already use. > that may also work for others. UIDs in the range SYS_UID_MIN..SYS_UID_MAX (i.e. 101..999) were always used for dynamic allocation of system accounts. GLEP 81 hasn't really changed anything there, except that the ebuild will now suggest an ID to try first. Ulrich signature.asc Description: PGP signature
Re: [gentoo-dev] Python packages up for grabs
Hi!
On Mon, 29 Nov 2021, Michał Górny wrote:
> On Mon, 2021-11-29 at 14:44 +0100, Tobias Klausmann wrote:
> > I don't really use any of these anymore, so I'd love for someone else to
> > maintain them:
> >
> > dev-python/pockets
> > dev-python/pycodestyle
> > dev-python/pynacl
>
> Please reassign them to python@, we've been taking care of them anyway.
All done, thanks!
Best,
Tobias
--
panic("Alas, I survived.\n");
linux-2.6.6/arch/ppc64/kernel/rtas.c
[gentoo-dev] Last-rites: dev-libs/qrosscore
# Andreas Sturmlechner (2021-11-30) # No revdeps, bug #774498; masked for removal on 2021-12-30. dev-libs/qrosscore signature.asc Description: This is a digitally signed message part.
