Re: [gentoo-dev] dynamic groups and users
Hi Michał, On 2019/08/07 17:48, Michał Górny wrote: > On Tue, 2019-08-06 at 13:41 +0200, Jaco Kroon wrote: >> Hi Guys, >> >> > Attaching. It seems for some reason if I inline the patches they don't >> come through. If I mail to myself only it works just fine. >> > > Actually, I think it should be changed the other way around. I don't > see any reason to prohibit having a user/group package for root. Hmm, ie, remove root from baselayout? Honestly, that's a mind stretch. And since it makes no sense to have any other package create a uid of gid =0 I think the change is right. No objection to do it the other way around, but since the value won't make any sense it'll effectively become a "please allocate dynamically" value - which goes against what you stated earlier of everything in ::gentoo should be "static". Please confirm. Kind Regards, Jaco
Re: [gentoo-dev] [PATCH] glep-0081: prohibit KEYWORDS altering
On 8/7/19 11:20 AM, Mikle Kolyada wrote:
> Signed-off-by: Mikle Kolyada
> ---
> As discussed with mgorny at #gentoo-qa
> glep-0081.rst | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/glep-0081.rst b/glep-0081.rst
> index 082e705..e5a4db2 100644
> --- a/glep-0081.rst
> +++ b/glep-0081.rst
> @@ -107,6 +107,9 @@ a build time dependency (``DEPEND``) must be used. If
> the user is
> needed at install and/or run time, a run time dependency (``RDEPEND``)
> must be used.
>
> +Both ``acct-group`` and ``acct-user`` eclasses have the ``KEYWORDS``
> +variable predefined, keywords must not be altered locally via ebuilds.
> +
>
> Maintaining users/groups
>
>
Maybe I'm not making myself clear (A bad habit of mine).
I want to keep this out such that maintainers can decide the best
keywords and when it is inappropriate to include a keyword.
For example with my acct-{group,user}/mysql ebuilds, I want to remove
the prefix keywords and only have those which match the virtual and
server implementations. The rare occasion when a keyword is added is no
more a maintenance task like changing the virtual. Having other ebuilds
outside the project use this package is not the right thing to do.
The packages in question treat prefix differently so why shouldn't it be
reflected here?
Brian
signature.asc
Description: OpenPGP digital signature
[gentoo-dev] [PATCH v2 3/3] savedconfig.eclass: Only check config file candidate once
Due to the injection of $CTARGET and $CHOST in file path
we could end up with an already checked config file candidate
if $CTARGET or $CHOST isn't used.
This commit will make sure that we don't check the same file twice.
Signed-off-by: Thomas Deutschmann
---
eclass/savedconfig.eclass | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/eclass/savedconfig.eclass b/eclass/savedconfig.eclass
index 1ea464271aff..b2be715630af 100644
--- a/eclass/savedconfig.eclass
+++ b/eclass/savedconfig.eclass
@@ -113,20 +113,24 @@ restore_config() {
use savedconfig || return
- local found check configfile
+ local found check checked configfile
local base=${PORTAGE_CONFIGROOT%/}/etc/portage/savedconfig
for check in {${CATEGORY}/${PF},${CATEGORY}/${P},${CATEGORY}/${PN}}; do
- configfile=${base}/${CTARGET}/${check}
- [[ -r ${configfile} ]] || configfile=${base}/${CHOST}/${check}
+ configfile=${base}/${CTARGET:+"${CTARGET}/"}${check}
+ [[ -r ${configfile} ]] ||
configfile=${base}/${CHOST:+"${CHOST}/"}${check}
[[ -r ${configfile} ]] || configfile=${base}/${check}
- einfo "Checking existence of ${configfile} ..."
+ [[ "${checked}" == *"${configfile} "* ]] && continue
+ einfo "Checking existence of \"${configfile}\" ..."
if [[ -r "${configfile}" ]] ; then
einfo "Found \"${configfile}\""
found=${configfile}
_SAVEDCONFIG_CONFIGURATION_FILE=${configfile#${base}/}
break
fi
+
+ checked+="${configfile} "
done
+
if [[ -f ${found} ]]; then
elog "Building using saved configfile \"${found}\""
if [ $# -gt 0 ]; then
--
2.22.0
[gentoo-dev] [PATCH v2 2/3] savedconfig.eclass: Always quote filename in output
Signed-off-by: Thomas Deutschmann
---
eclass/savedconfig.eclass | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/eclass/savedconfig.eclass b/eclass/savedconfig.eclass
index f62a6055ffdb..1ea464271aff 100644
--- a/eclass/savedconfig.eclass
+++ b/eclass/savedconfig.eclass
@@ -128,14 +128,14 @@ restore_config() {
fi
done
if [[ -f ${found} ]]; then
- elog "Building using saved configfile ${found}"
+ elog "Building using saved configfile \"${found}\""
if [ $# -gt 0 ]; then
cp -pPR "${found}" "$1" || die "Failed to restore
${found} to $1"
else
die "need to know the restoration filename"
fi
elif [[ -d ${found} ]]; then
- elog "Building using saved config directory ${found}"
+ elog "Building using saved config directory \"${found}\""
local dest=${PWD}
pushd "${found}" > /dev/null
treecopy . "${dest}" || die "Failed to restore ${found} to $1"
@@ -147,7 +147,7 @@ restore_config() {
die "Reading config files failed"
fi
ewarn "No saved config to restore - please remove
USE=savedconfig or"
- ewarn "provide a configuration file in
${PORTAGE_CONFIGROOT}/etc/portage/savedconfig/${CATEGORY}/${PN}"
+ ewarn "provide a configuration file in
${PORTAGE_CONFIGROOT%/}/etc/portage/savedconfig/${CATEGORY}/${PN}"
ewarn "Your config file(s) will not be used this time"
fi
}
--
2.22.0
[gentoo-dev] [PATCH v2 1/3] savedconfig.eclass: Re-use configuration file scheme
From: Arfrever Frehtes Taifersar Arahesis
Make save_config() re-use configuration file scheme used
by restore_config().
Fixes: https://bugs.gentoo.org/686348
Signed-off-by: Arfrever Frehtes Taifersar Arahesis
Signed-off-by: Thomas Deutschmann
---
eclass/savedconfig.eclass | 40 ++-
1 file changed, 27 insertions(+), 13 deletions(-)
diff --git a/eclass/savedconfig.eclass b/eclass/savedconfig.eclass
index e0b1953d56d0..f62a6055ffdb 100644
--- a/eclass/savedconfig.eclass
+++ b/eclass/savedconfig.eclass
@@ -38,6 +38,13 @@ case ${EAPI} in
*) die "EAPI=${EAPI:-0} is not supported" ;;
esac
+# @ECLASS-VARIABLE: _SAVEDCONFIG_CONFIGURATION_FILE
+# @DEFAULT_UNSET
+# @INTERNAL
+# @DESCRIPTION:
+# Path of configuration file, relative to /etc/portage/savedconfig,
+# restored by restore_config() and saved by save_config().
+
# @FUNCTION: save_config
# @USAGE:
# @DESCRIPTION:
@@ -51,20 +58,26 @@ save_config() {
fi
[[ $# -eq 0 ]] && die "Usage: save_config "
- local dest="/etc/portage/savedconfig/${CATEGORY}"
+ local configfile
+ if [[ -n ${_SAVEDCONFIG_CONFIGURATION_FILE} ]] ; then
+
configfile="/etc/portage/savedconfig/${_SAVEDCONFIG_CONFIGURATION_FILE}"
+ else
+ configfile="/etc/portage/savedconfig/${CATEGORY}/${PF}"
+ fi
+
if [[ $# -eq 1 && -f $1 ]] ; then
- # Just one file, so have the ${PF} be that config file
- dodir "${dest}"
- cp "$@" "${ED%/}/${dest}/${PF}" || die "failed to save $*"
+ # Just one file, so have the ${configfile} be that config file
+ dodir "${configfile%/*}"
+ cp "$@" "${ED%/}/${configfile}" || die "failed to save $*"
else
- # A dir, or multiple files, so have the ${PF} be a dir
+ # A dir, or multiple files, so have the ${configfile} be a dir
# with all the saved stuff below it
- dodir "${dest}/${PF}"
- treecopy "$@" "${ED%/}/${dest}/${PF}" || die "failed to save $*"
+ dodir "${configfile}"
+ treecopy "$@" "${ED%/}/${configfile}" || die "failed to save $*"
fi
elog "Your configuration for ${CATEGORY}/${PF} has been saved in "
- elog "/etc/portage/savedconfig/${CATEGORY}/${PF} for your editing
pleasure."
+ elog "\"${configfile}\" for your editing pleasure."
elog "You can edit these files by hand and remerge this package with"
elog "USE=savedconfig to customise the configuration."
elog "You can rename this file/directory to one of the following for"
@@ -76,7 +89,7 @@ save_config() {
# @FUNCTION: restore_config
# @USAGE:
# @DESCRIPTION:
-# Restores the configuation saved ebuild previously potentially with user
edits.
+# Restores the package's configuration file probably with user edits.
# You can restore a single file or a whole bunch, just make sure you call
# restore_config with all of the files to restore at the same time.
#
@@ -107,10 +120,11 @@ restore_config() {
[[ -r ${configfile} ]] || configfile=${base}/${CHOST}/${check}
[[ -r ${configfile} ]] || configfile=${base}/${check}
einfo "Checking existence of ${configfile} ..."
- if [[ -r "${configfile}" ]]; then
- einfo "found ${configfile}"
- found=${configfile};
- break;
+ if [[ -r "${configfile}" ]] ; then
+ einfo "Found \"${configfile}\""
+ found=${configfile}
+ _SAVEDCONFIG_CONFIGURATION_FILE=${configfile#${base}/}
+ break
fi
done
if [[ -f ${found} ]]; then
--
2.22.0
Re: [gentoo-dev] [PATCH 1/3] savedconfig.eclass: Make save_config() re-use configuration file scheme used by restore_config()
On 2019-08-03 18:20, Ulrich Mueller wrote:
>> On Sat, 03 Aug 2019, Thomas Deutschmann wrote:
>
>> +# @ECLASS-VARIABLE: _SAVEDCONFIG_CONFIGURATION_FILE
>
> 31 chars? Seems excessive for a name of a private variable.
And? I'll keep that name for readability instead of finding an
abbreviation.
>> +# Restores the configuration saved ebuild previously potentially with user
>> edits.
>
> If have trouble understanding this sentence.
v2 will contain a better sentence.
>> +if [[ -r "${configfile}" ]] ; then
>
> Quotes are not necessary here.
Not necessary but it won't hurt. I'd like to keep them for style. I.e. I
think it's better to always quote so you won't forget when it will
become critical.
--
Regards,
Thomas Deutschmann / Gentoo Linux Developer
C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5
signature.asc
Description: OpenPGP digital signature
[gentoo-dev] Re: [PATCH 1/3] savedconfig.eclass: Make save_config() re-use configuration file scheme used by restore_config()
On 2019-08-03 15:31, Mike Gilbert wrote: > The summary line on this patch is too long. GLEP 66 states it must be > no longer than 69 characters. v2 will have summary line <=69 characters, thanks. -- Regards, Thomas Deutschmann / Gentoo Linux Developer C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH] glep-0081: prohibit KEYWORDS altering
On Wed, Aug 7, 2019 at 12:02 PM Kent Fredric wrote:
>
> On Wed, 07 Aug 2019 17:55:21 +0200
> Ulrich Mueller wrote:
>
> > Plus, the eclasses explicitly allow KEYWORDS to be overridden by the
> > ebuild:
> >
> > : ${KEYWORDS:=alpha amd64 arm arm64 hppa ia64 m68k ~mips ppc ppc64 ~riscv
> > s390 sh sparc x86 ~ppc-aix ~x64-cygwin ~amd64-fbsd ~x86-fbsd ~amd64-linux
> > ~x86-linux ~ppc-macos ~x64-macos ~x86-macos ~m68k-mint ~sparc-solaris
> > ~sparc64-solaris ~x64-solaris ~x86-solaris}
>
> I guess the clear limitation that the proposed policy would create, is
> that it would be illegal for a package on say, riscv, to be stabilized,
> if it depended on any acct-* packages.
>
> Because the eclass would say "riscv ain't stable", and policy would say
> "you can't change keywords on acct-*", which would necessitate that all
> acct-* be marked stable for riscv via changing the eclass, in order for
> the riscv package to be marked stable.
But that's exactly what we would want to happen: the value in the
eclass should be updated, not individual ebuilds.
Re: [gentoo-dev] [PATCH] acct-*.eclass: Allow dynamic UID/GID assignment via -1
On Wed, 2019-08-07 at 13:29 -0400, Michael Orlitzky wrote: > On 8/7/19 1:10 PM, Michał Górny wrote: > > Using '999' was also suggested (as the first dynamic > > UID/GID) but it would cause issues for people enabling > > ACCT_*_ENFORCE_ID. To avoid this, '-1' does not trigger collision > > checks. > > > > Feel free to proceed with this, I'm just curious: what's the problem > with 999 and enforced IDs? They will fail once the first package allocates 999 ;-). > > > > +# > > +# Overlays should set this to -1 to dynamically allocate GID. Using -1 > > +# in ::gentoo is prohibited by policy. > > > > Should say "UID" in the user eclass. > Fixed, thanks. -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [PATCH] acct-*.eclass: Allow dynamic UID/GID assignment via -1
On 8/7/19 1:10 PM, Michał Górny wrote: > > Using '999' was also suggested (as the first dynamic > UID/GID) but it would cause issues for people enabling > ACCT_*_ENFORCE_ID. To avoid this, '-1' does not trigger collision > checks. > Feel free to proceed with this, I'm just curious: what's the problem with 999 and enforced IDs? > +# > +# Overlays should set this to -1 to dynamically allocate GID. Using -1 > +# in ::gentoo is prohibited by policy. > Should say "UID" in the user eclass.
[gentoo-dev] [PATCH] acct-*.eclass: Allow dynamic UID/GID assignment via -1
Allow a special value of '-1' to dynamically assign UID/GID for the user
or group. This is intended to be used in overlays where proper
assignment does not take place but whose owners wish to switch to acct-*
packages.
While technically it is possible to choose a free UID/GID, it could be
taken afterwards by some Gentoo package and unnecessarily introduce
a conflict. Using '999' was also suggested (as the first dynamic
UID/GID) but it would cause issues for people enabling
ACCT_*_ENFORCE_ID. To avoid this, '-1' does not trigger collision
checks.
Signed-off-by: Michał Górny
---
eclass/acct-group.eclass | 4
eclass/acct-user.eclass | 4
2 files changed, 8 insertions(+)
diff --git a/eclass/acct-group.eclass b/eclass/acct-group.eclass
index 9eab00db690f..d5ccd209c9e3 100644
--- a/eclass/acct-group.eclass
+++ b/eclass/acct-group.eclass
@@ -59,6 +59,9 @@ readonly ACCT_GROUP_NAME
# @DESCRIPTION:
# Preferred GID for the new group. This variable is obligatory, and its
# value must be unique across all group packages.
+#
+# Overlays should set this to -1 to dynamically allocate GID. Using -1
+# in ::gentoo is prohibited by policy.
# @ECLASS-VARIABLE: ACCT_GROUP_ENFORCE_ID
# @DESCRIPTION:
@@ -87,6 +90,7 @@ acct-group_pkg_pretend() {
# verify ACCT_GROUP_ID
[[ -n ${ACCT_GROUP_ID} ]] || die "Ebuild error: ACCT_GROUP_ID must be
set!"
+ [[ ${ACCT_GROUP_ID} -eq -1 ]] && return
[[ ${ACCT_GROUP_ID} -ge 0 ]] || die "Ebuild errors:
ACCT_GROUP_ID=${ACCT_GROUP_ID} invalid!"
# check for ACCT_GROUP_ID collisions early
diff --git a/eclass/acct-user.eclass b/eclass/acct-user.eclass
index 60009643c144..17a58e9126e4 100644
--- a/eclass/acct-user.eclass
+++ b/eclass/acct-user.eclass
@@ -67,6 +67,9 @@ readonly ACCT_USER_NAME
# @DESCRIPTION:
# Preferred UID for the new user. This variable is obligatory, and its
# value must be unique across all user packages.
+#
+# Overlays should set this to -1 to dynamically allocate GID. Using -1
+# in ::gentoo is prohibited by policy.
# @ECLASS-VARIABLE: ACCT_USER_ENFORCE_ID
# @DESCRIPTION:
@@ -279,6 +282,7 @@ acct-user_pkg_pretend() {
# verify ACCT_USER_ID
[[ -n ${ACCT_USER_ID} ]] || die "Ebuild error: ACCT_USER_ID must be
set!"
+ [[ ${ACCT_USER_ID} -eq -1 ]] && return
[[ ${ACCT_USER_ID} -ge 0 ]] || die "Ebuild errors:
ACCT_USER_ID=${ACCT_USER_ID} invalid!"
# check for ACCT_USER_ID collisions early
--
2.23.0.rc1
Re: [gentoo-dev] [PATCH] glep-0081: prohibit KEYWORDS altering
On Wed, 07 Aug 2019 17:55:21 +0200
Ulrich Mueller wrote:
> Plus, the eclasses explicitly allow KEYWORDS to be overridden by the
> ebuild:
>
> : ${KEYWORDS:=alpha amd64 arm arm64 hppa ia64 m68k ~mips ppc ppc64 ~riscv
> s390 sh sparc x86 ~ppc-aix ~x64-cygwin ~amd64-fbsd ~x86-fbsd ~amd64-linux
> ~x86-linux ~ppc-macos ~x64-macos ~x86-macos ~m68k-mint ~sparc-solaris
> ~sparc64-solaris ~x64-solaris ~x86-solaris}
I guess the clear limitation that the proposed policy would create, is
that it would be illegal for a package on say, riscv, to be stabilized,
if it depended on any acct-* packages.
Because the eclass would say "riscv ain't stable", and policy would say
"you can't change keywords on acct-*", which would necessitate that all
acct-* be marked stable for riscv via changing the eclass, in order for
the riscv package to be marked stable.
( Yes, this is not a risk now, but it would be an annoying situation
for anyone trying to promote riscv into being a stable arch )
pgp41wRXU3STR.pgp
Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH] glep-0081: prohibit KEYWORDS altering
On 07.08.2019 18:49, Michał Górny wrote: > On Wed, 2019-08-07 at 18:20 +0300, Mikle Kolyada wrote: >> Signed-off-by: Mikle Kolyada >> --- >> As discussed with mgorny at #gentoo-qa >> glep-0081.rst | 3 +++ >> 1 file changed, 3 insertions(+) >> >> diff --git a/glep-0081.rst b/glep-0081.rst >> index 082e705..e5a4db2 100644 >> --- a/glep-0081.rst >> +++ b/glep-0081.rst >> @@ -107,6 +107,9 @@ a build time dependency (``DEPEND``) must be used. If >> the user is >> needed at install and/or run time, a run time dependency (``RDEPEND``) >> must be used. >> >> +Both ``acct-group`` and ``acct-user`` eclasses have the ``KEYWORDS`` >> +variable predefined, keywords must not be altered locally via ebuilds. >> + >> >> Maintaining users/groups >> > I've told you I don't believe this belongs in the GLEP. It's > implementation detail, and if at all, it should go through tree policy. > We did not come to a conclusion about where this should be written down if you remember, in any way I am concerned about the fact, not about a place where we write it down, the main intention here is that all the developers must follow the same rules. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH] glep-0081: prohibit KEYWORDS altering
On Wed, 7 Aug 2019 11:32:43 -0400 Brian Evans wrote: > I object to this as I feel they can incorrect such as on prefix. > > Also, this goes against the established practice of committing directly > to stable. These are exactly the same as virtuals as "they install > nothing" and "just run a script" (to verify dependencies). I'll have to disagree: Installing/Upgrading virtuals can have radical impacts on your system via the dependency graph. Stabilizing a virtual before all its dependencies get stabilized will create hell. Virtuals can also impose USE flags onto other package via the dependency graph, and all hosts of similar things. If you wanted an equivalence, you'd need a virtual without dependencies, which would be a useless virtual. I think its better to think of the ebuilds in acct/ as more an obtusely defined text config-file, for which, the interpretation of that text file is defined by a shared blob of code, the eclass. The stability of the mechanics of interpreting those text files is what is in consideration here, not the text files themselves. And that mechanism is the eclass. By comparison, you could easily implement an alternative system, where nodes in acct/ were not .ebuilds, but, just literal text files instead of bash, with no provisions for keywords at all, and the interpretation of said files would be up to the package manager. Not only shouldn't you try to do keywording in such a situation, you _couldnt_ That said, I do think making this stipulation may be premature, but its something that I can't imagine we'll know for sure is wise until we've been employing this strategy for a good time, and we won't know we'll need the capacity until the first usecase where its needed arises. pgpuY1ILnYnKr.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH] glep-0081: prohibit KEYWORDS altering
> On Wed, 07 Aug 2019, Mikle Kolyada wrote:
> +Both ``acct-group`` and ``acct-user`` eclasses have the ``KEYWORDS``
> +variable predefined, keywords must not be altered locally via ebuilds.
> +
GLEP 81 doesn't specify anything about the implementation. In fact,
it neither requires that it is implemented via eclasses, nor does it
specify any ebuild or eclass variables. So, I'd say that keywording
is an implementation detail and doesn't belong in the GLEP.
Plus, the eclasses explicitly allow KEYWORDS to be overridden by the
ebuild:
: ${KEYWORDS:=alpha amd64 arm arm64 hppa ia64 m68k ~mips ppc ppc64 ~riscv s390
sh sparc x86 ~ppc-aix ~x64-cygwin ~amd64-fbsd ~x86-fbsd ~amd64-linux ~x86-linux
~ppc-macos ~x64-macos ~x86-macos ~m68k-mint ~sparc-solaris ~sparc64-solaris
~x64-solaris ~x86-solaris}
Ulrich
signature.asc
Description: PGP signature
Re: [gentoo-dev] [PATCH] glep-0081: prohibit KEYWORDS altering
On Wed, 2019-08-07 at 18:20 +0300, Mikle Kolyada wrote: > Signed-off-by: Mikle Kolyada > --- > As discussed with mgorny at #gentoo-qa > glep-0081.rst | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/glep-0081.rst b/glep-0081.rst > index 082e705..e5a4db2 100644 > --- a/glep-0081.rst > +++ b/glep-0081.rst > @@ -107,6 +107,9 @@ a build time dependency (``DEPEND``) must be used. If > the user is > needed at install and/or run time, a run time dependency (``RDEPEND``) > must be used. > > +Both ``acct-group`` and ``acct-user`` eclasses have the ``KEYWORDS`` > +variable predefined, keywords must not be altered locally via ebuilds. > + > > Maintaining users/groups > I've told you I don't believe this belongs in the GLEP. It's implementation detail, and if at all, it should go through tree policy. -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [PATCH] glep-0081: prohibit KEYWORDS altering
On Wed, 2019-08-07 at 11:32 -0400, Brian Evans wrote: > On 8/7/2019 11:20 AM, Mikle Kolyada wrote: > > Signed-off-by: Mikle Kolyada > > --- > > As discussed with mgorny at #gentoo-qa > > glep-0081.rst | 3 +++ > > 1 file changed, 3 insertions(+) > > > > diff --git a/glep-0081.rst b/glep-0081.rst > > index 082e705..e5a4db2 100644 > > --- a/glep-0081.rst > > +++ b/glep-0081.rst > > @@ -107,6 +107,9 @@ a build time dependency (``DEPEND``) must be used. If > > the user is > > needed at install and/or run time, a run time dependency (``RDEPEND``) > > must be used. > > > > +Both ``acct-group`` and ``acct-user`` eclasses have the ``KEYWORDS`` > > +variable predefined, keywords must not be altered locally via ebuilds. > > + > > > > Maintaining users/groups > > > > > > I object to this as I feel they can incorrect such as on prefix. > > Also, this goes against the established practice of committing directly > to stable. These are exactly the same as virtuals as "they install > nothing" and "just run a script" (to verify dependencies). > We don't do stabilization for virtuals. We set KEYWORDS to be the union of KEYWORDS of providers. -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] dynamic groups and users
On Tue, 2019-08-06 at 13:41 +0200, Jaco Kroon wrote: > Hi Guys, > > Attaching. It seems for some reason if I inline the patches they don't > come through. If I mail to myself only it works just fine. > Actually, I think it should be changed the other way around. I don't see any reason to prohibit having a user/group package for root. -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [PATCH] glep-0081: prohibit KEYWORDS altering
On 07.08.2019 18:32, Brian Evans wrote: > On 8/7/2019 11:20 AM, Mikle Kolyada wrote: >> Signed-off-by: Mikle Kolyada >> --- >> As discussed with mgorny at #gentoo-qa >> glep-0081.rst | 3 +++ >> 1 file changed, 3 insertions(+) >> >> diff --git a/glep-0081.rst b/glep-0081.rst >> index 082e705..e5a4db2 100644 >> --- a/glep-0081.rst >> +++ b/glep-0081.rst >> @@ -107,6 +107,9 @@ a build time dependency (``DEPEND``) must be used. If >> the user is >> needed at install and/or run time, a run time dependency (``RDEPEND``) >> must be used. >> >> +Both ``acct-group`` and ``acct-user`` eclasses have the ``KEYWORDS`` >> +variable predefined, keywords must not be altered locally via ebuilds. >> + >> >> Maintaining users/groups >> >> > I object to this as I feel they can incorrect such as on prefix. > > Also, this goes against the established practice of committing directly > to stable. These are exactly the same as virtuals as "they install > nothing" and "just run a script" (to verify dependencies). > > Brian They are not exactly the same as virtuals, ~arch keywords in virtuals make sense because they may have dependency providers that are also in ~arch status. These eclasses pull nothing, therefore keywords altering here meaningless by definition. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH 1/2] acct-user/gvm: Add 'gvm' user (UID 495)
2019-08-07 18:33, Michael Orlitzky yazmış: On 8/7/19 11:30 AM, Hasan ÇALIŞIR wrote: +ACCT_USER_ID=495 +ACCT_USER_HOME=/var/lib/gvm +ACCT_USER_HOME_OWNER=gvm:gvm +ACCT_USER_GROUPS=( gvm ) The HOME_OWNER is redundant, that's the eclass default. Will be fixed in PR. Michael, do i need to re-send patch e-mails? -- Best ~Hasan signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH 1/2] acct-user/gvm: Add 'gvm' user (UID 495)
On 8/7/19 11:30 AM, Hasan ÇALIŞIR wrote: > +ACCT_USER_ID=495 > +ACCT_USER_HOME=/var/lib/gvm > +ACCT_USER_HOME_OWNER=gvm:gvm > +ACCT_USER_GROUPS=( gvm ) The HOME_OWNER is redundant, that's the eclass default.
Re: [gentoo-dev] [PATCH] glep-0081: prohibit KEYWORDS altering
On 8/7/2019 11:20 AM, Mikle Kolyada wrote: > Signed-off-by: Mikle Kolyada > --- > As discussed with mgorny at #gentoo-qa > glep-0081.rst | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/glep-0081.rst b/glep-0081.rst > index 082e705..e5a4db2 100644 > --- a/glep-0081.rst > +++ b/glep-0081.rst > @@ -107,6 +107,9 @@ a build time dependency (``DEPEND``) must be used. If > the user is > needed at install and/or run time, a run time dependency (``RDEPEND``) > must be used. > > +Both ``acct-group`` and ``acct-user`` eclasses have the ``KEYWORDS`` > +variable predefined, keywords must not be altered locally via ebuilds. > + > > Maintaining users/groups > > I object to this as I feel they can incorrect such as on prefix. Also, this goes against the established practice of committing directly to stable. These are exactly the same as virtuals as "they install nothing" and "just run a script" (to verify dependencies). Brian signature.asc Description: OpenPGP digital signature
[gentoo-dev] [PATCH 0/2] Update-Request for acct-*/gvm (UID-GID 495)
As suggested by Michael Orlitzky, I am updating my previous request for 'gvm' UID-GID_495 with 'nologin' instead of 'bash' shell. PR -> https://github.com/gentoo/gentoo/pull/12609
[gentoo-dev] [PATCH 2/2] acct-group/gvm: Add 'gvm' group (GID 495)
--- acct-group/gvm/gvm-0.ebuild | 10 ++ acct-group/gvm/metadata.xml | 12 2 files changed, 22 insertions(+) create mode 100644 acct-group/gvm/gvm-0.ebuild create mode 100644 acct-group/gvm/metadata.xml diff --git a/acct-group/gvm/gvm-0.ebuild b/acct-group/gvm/gvm-0.ebuild new file mode 100644 index 00..8dd96661bb --- /dev/null +++ b/acct-group/gvm/gvm-0.ebuild @@ -0,0 +1,10 @@ +# Copyright 2019 Gentoo Authors +# Distributed under the terms of the GNU General Public License v2 + +EAPI=7 + +inherit acct-group + +DESCRIPTION="Greenbone vulnerability management program group" +ACCT_GROUP_ID=495 + diff --git a/acct-group/gvm/metadata.xml b/acct-group/gvm/metadata.xml new file mode 100644 index 00..c1c5013745 --- /dev/null +++ b/acct-group/gvm/metadata.xml @@ -0,0 +1,12 @@ + +http://www.gentoo.org/dtd/metadata.dtd";> + + + hasan.cali...@psauxit.com + Hasan ÇALIŞIR + + + proxy-ma...@gentoo.org + Proxy Maintainers + + -- 2.21.0
[gentoo-dev] [PATCH 1/2] acct-user/gvm: Add 'gvm' user (UID 495)
--- acct-user/gvm/gvm-0.ebuild | 14 ++ acct-user/gvm/metadata.xml | 12 2 files changed, 26 insertions(+) create mode 100644 acct-user/gvm/gvm-0.ebuild create mode 100644 acct-user/gvm/metadata.xml diff --git a/acct-user/gvm/gvm-0.ebuild b/acct-user/gvm/gvm-0.ebuild new file mode 100644 index 00..4c0e14b616 --- /dev/null +++ b/acct-user/gvm/gvm-0.ebuild @@ -0,0 +1,14 @@ +# Copyright 2019 Gentoo Authors +# Distributed under the terms of the GNU General Public License v2 + +EAPI=7 + +inherit acct-user + +DESCRIPTION="Greenbone vulnerability management program user" +ACCT_USER_ID=495 +ACCT_USER_HOME=/var/lib/gvm +ACCT_USER_HOME_OWNER=gvm:gvm +ACCT_USER_GROUPS=( gvm ) + +acct-user_add_deps diff --git a/acct-user/gvm/metadata.xml b/acct-user/gvm/metadata.xml new file mode 100644 index 00..b011cd5d77 --- /dev/null +++ b/acct-user/gvm/metadata.xml @@ -0,0 +1,12 @@ + +http://www.gentoo.org/dtd/metadata.dtd";> + + +hasan.cali...@psauxit.com +Hasan ÇALIŞIR + + +proxy-ma...@gentoo.org +Proxy Maintainers + + -- 2.21.0
[gentoo-dev] [PATCH] glep-0081: prohibit KEYWORDS altering
Signed-off-by: Mikle Kolyada --- As discussed with mgorny at #gentoo-qa glep-0081.rst | 3 +++ 1 file changed, 3 insertions(+) diff --git a/glep-0081.rst b/glep-0081.rst index 082e705..e5a4db2 100644 --- a/glep-0081.rst +++ b/glep-0081.rst @@ -107,6 +107,9 @@ a build time dependency (``DEPEND``) must be used. If the user is needed at install and/or run time, a run time dependency (``RDEPEND``) must be used. +Both ``acct-group`` and ``acct-user`` eclasses have the ``KEYWORDS`` +variable predefined, keywords must not be altered locally via ebuilds. + Maintaining users/groups -- 2.21.0
Re: [gentoo-dev] [PATCH 2/2] acct-user/amavis: new user (UID 333)
On 8/3/19 7:49 PM, Michael Orlitzky wrote: > > That makes me think that we should set > > ACCT_USER_HOME=/var/lib/amavis > We'll do this during the next version/revision bump, keeping everything else the same.
[gentoo-dev] [PATCH] ssl-cert.eclass: allow EAPI=7
---
eclass/ssl-cert.eclass | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/eclass/ssl-cert.eclass b/eclass/ssl-cert.eclass
index b5b4250ef22..01783b75848 100644
--- a/eclass/ssl-cert.eclass
+++ b/eclass/ssl-cert.eclass
@@ -18,7 +18,7 @@ case "${EAPI:-0}" in
0)
die "${ECLASS}.eclass: EAPI=0 is not supported. Please upgrade
to EAPI >= 1."
;;
- 1|2|3|4|5|6)
+ 1|2|3|4|5|6|7)
;;
*)
die "${ECLASS}.eclass: EAPI=${EAPI} is not supported yet."
--
2.21.0
[gentoo-dev] RFC: UID/GID assignment for dovenull (74)
I would like to reserve UID/GID 74 for dovenull (net-mail/dovecot). Arch also uses uid 74 for dovenull while Redhat uses next available. -- Eray signature.asc Description: PGP signature
[gentoo-dev] RFC: UID/GID assignment for dovecot (76)
I would like to reserve UID/GID 76 for dovecot (net-mail/dovecot) This id differs from what we have provided historically (97) but gid/97 is used by acct-group/input. So use 76 instead. This id is the same in Arch (76) but differs from Redhat (97). -- Eray signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: UID/GID assignment for dovecot (97)
On Wed, Aug 07, 2019 at 10:59:48AM +0200, Ulrich Mueller wrote: > Historically dovecot came first, but OTOH the ID was added to baselayout > five years ago, and changing baselayout requires some effort. So I'd > suggest to change dovecot. > > The UIDs and GIDs used by Arch might be good: >dovenull 74 >dovecot 76 Alright. I'll re-send the emails with the revized IDs Thanks -- Eray signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: UID/GID assignment for dovecot (97)
> On Wed, 07 Aug 2019, Eray Aslan wrote: > So do we ask acct-group/input to change their GID? why add an already > used fixed gid to baselayout in the first place (and one that is used on > other distros as well)? whats the thinking here? > or we can change dovecot uid/gid. I dont mind but how do we decide? Historically dovecot came first, but OTOH the ID was added to baselayout five years ago, and changing baselayout requires some effort. So I'd suggest to change dovecot. The UIDs and GIDs used by Arch might be good: dovenull 74 dovecot 76 Ulrich signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: UID/GID assignment for dovecot (97)
On Wed, Aug 07, 2019 at 11:32:48AM +0300, Alexander Tsoy wrote: > В Ср, 07/08/2019 в 09:29 +0300, Eray Aslan пишет: > > I would like to reserve UID/GID 97 for dovecot (net-mail/dovecot) > > This GID is currently used by the input group (sys-apps/baselayout and > acct-group/input). > > https://bugs.gentoo.org/688390 So do we ask acct-group/input to change their GID? why add an already used fixed gid to baselayout in the first place (and one that is used on other distros as well)? whats the thinking here? or we can change dovecot uid/gid. I dont mind but how do we decide? -- Eray signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: UID/GID assignment for dovecot (97)
В Ср, 07/08/2019 в 09:29 +0300, Eray Aslan пишет: > I would like to reserve UID/GID 97 for dovecot (net-mail/dovecot) This GID is currently used by the input group (sys-apps/baselayout and acct-group/input). https://bugs.gentoo.org/688390 > > This fixed ID is what we have provided historically and is the same > as > RedHat but differs from Arch (76). >
Re: [gentoo-dev] RFC: UID/GID assignment for dovenull (484)
> On Wed, 07 Aug 2019, Eray Aslan wrote: > I would like to reserve UID/GID 484 for dovenull (net-mail/dovecot). > Arch uses uid 74 for dovenull while Redhat uses next available. Wouldn't it make sense to keep dovecot and dovenull together, i.e. use 97 for dovecot and 98 for dovenull? (Fedora uses 98 for "ident" but we don't have any package asking for that user.) signature.asc Description: PGP signature
