Re: [gentoo-dev] Changes made by acct-* ebuilds
On Thu, Feb 13, 2020 at 6:24 PM Michael 'veremitz' Everitt < gen...@veremit.xyz> wrote: > On 13/02/20 16:17, Mike Gilbert wrote: > > On Wed, Feb 12, 2020 at 8:32 PM Thomas Deutschmann > wrote: > >> In short: It was a very bad decision that acct-* stuff is *changing* > >> existing stuff. This must be turned of *by default*. Maybe provide a > >> setting a user can put into make.conf to opt into current, still new, > >> behavior but by default, a package should never ever make changes to > >> *existing* user (unless it knows for sure it was the only source > >> creating that user and nothing was changed since creation which isn't > >> easy to track). > > I think it would make sense to add some eclass variables that would > > turn user.eclass functions into no-ops. > > > > I don't agree that this should be happen by default. I suspect the > > majority of users do not wish to manage system users/groups > > themselves. > > > I would suggest anyone competent enough to build a kernel from scratch > (genkernel users, I'm ignoring you) should be equally at-home managing > system users and groups and associated permissions? Or am I perhaps > overestimating the average Genbuntu users here ... >,< > > I said nothing of capability. Most people don’t care to micromanage > accounts.
[gentoo-dev] pkgcheck/pkgcore indefinite hiatus
Hi all, Just wanted to note that pkgcheck and pkgcore (as well as snakeoil and pychroot) are effectively on an indefinite hiatus mainly due to my lack of free time for them. Since pkgcheck and pkgcore probably have more users (indirectly via CI) than when its main developer left last time I figured it would be worth mentioning this to the larger group as it could have effects down the road (e.g. EAPI 8 support). If you want more specifics, are inspired to take over or help with development, or have other pkgcore-specific questions feel free to contact me personally. Thanks, Tim
Re: [gentoo-dev] [PATCH 3/3] app-admin/kube-bench: convert to go-module go.sum
On Thu, Feb 13, 2020 at 4:12 AM Mike Pagano wrote: > > On Thu, Feb 13, 2020 at 06:46:43PM +1100, Sam Jorna (wraeth) wrote: > > On Thursday, 13 February 2020 5:40:46 AM AEDT Matt Turner wrote: > > > On Wed, Feb 12, 2020 at 9:59 AM William Hubbs wrote: > > > > On Wed, Feb 12, 2020 at 06:54:19PM +1100, Sam Jorna (wraeth) wrote: > > > > > On Monday, 10 February 2020 7:55:01 AM AEDT Michał Górny wrote: > > > > > > On Sun, 2020-02-09 at 20:38 +, Michael 'veremitz' Everitt wrote: > > > > > > > Hrm, pardon my ignorance, but do 'we' really need to review 232 > > > > > > > lines of > > > > > > > Manifest?! > > > > > > > > > > > > Pardon mine but do 'we' really need to read your useless comments > > > > > > everywhere, all the time and just get irritated for no benefit to > > > > > > Gentoo? > > > > > > > > > > Perhaps I'm the one being ignorant here, but why are we lambasting > > > > > someone for seeking clarification about an unusual inclusion on a > > > > > review thread?> > > > > I wasn't going to say anything, but I can't let this go by without > > > > commenting. > > > > > > > > Sam is correct. Maybe the tone is a bit off, (and that is debatable), > > > > but this definitely can be seen as a legit question, regardless of other > > > > things Michael has posted. > > > > > > Unfortunately it's not about a single issue or email. It's a > > > consistent pattern that multiple people have asked him to rein in over > > > a long period. :( > > > > Without going into specifics, veremit and I have certainly had our > > 'differences > > of opinion' in the past; but I don't believe this is one of those occasions. > > > > Calling out bad actors (not saying veremit is one, I just mean in the > > general > > sense) is an unfortunate but important task, but call them out on bad > > behaviour, not for what appears to be an impassioned but otherwise > > unremarkable query. > > > > I agree with this 100 percent. Not judging solely on the content of the > specific email in the thread does not allow people to grow and improve. Are we > all to be judged on our past behavior forever with no chance to overcome past > transgressions ? That's not what's going on.
[gentoo-dev] Changes made by acct-* ebuilds
On 13/02/20 16:17, Mike Gilbert wrote: > On Wed, Feb 12, 2020 at 8:32 PM Thomas Deutschmann wrote: >> In short: It was a very bad decision that acct-* stuff is *changing* >> existing stuff. This must be turned of *by default*. Maybe provide a >> setting a user can put into make.conf to opt into current, still new, >> behavior but by default, a package should never ever make changes to >> *existing* user (unless it knows for sure it was the only source >> creating that user and nothing was changed since creation which isn't >> easy to track). > I think it would make sense to add some eclass variables that would > turn user.eclass functions into no-ops. > > I don't agree that this should be happen by default. I suspect the > majority of users do not wish to manage system users/groups > themselves. > I would suggest anyone competent enough to build a kernel from scratch (genkernel users, I'm ignoring you) should be equally at-home managing system users and groups and associated permissions? Or am I perhaps overestimating the average Genbuntu users here ... >,< signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH] metadata/install-qa-check.d/60appdata-path: new check
On Thu, 13 Feb 2020 08:11:09 -0800 Christopher Head wrote: > On Wed, 12 Feb 2020 23:39:11 -0800 > Georgy Yakovlev wrote: > > > + eqawarn "For more details, please see the > > freedesktop Upstrem Metadate guidelines" > > Couple of typos here: s/Upstrem/Upstream/, s/Metadate/Metadata/. Thanks! Fixed and pushed now. Tracker bug is https://bugs.gentoo.org/709450 pgpaI8vnwCbLs.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH 1/3] eclass/go-module: add support for building based on go.sum
On Sun, 2020-02-09 at 12:31 -0800, Robin H. Johnson wrote:
> EGO_SUM mode now supplements the existing EGO_VENDOR mode.
>
> EGO_SUM should be populated by the maintainer, directly from the go.sum
> file of the root package. See eclass and conversion example
> (dev-go/go-tour & app-admin/kube-bench) for further details.
>
> The go-module_set_globals function performs validation of
> inputs and does die on fatal errors.
>
> Signed-off-by: Robin H. Johnson
> ---
> eclass/go-module.eclass| 328 +++--
> profiles/thirdpartymirrors | 1 +
> 2 files changed, 311 insertions(+), 18 deletions(-)
>
> diff --git eclass/go-module.eclass eclass/go-module.eclass
> index d5de5f60ccdf..b8a635d52de7 100644
> --- eclass/go-module.eclass
> +++ eclass/go-module.eclass
> @@ -4,22 +4,46 @@
> # @ECLASS: go-module.eclass
> # @MAINTAINER:
> # William Hubbs
> +# @AUTHOR:
> +# William Hubbs
> +# Robin H. Johnson
> # @SUPPORTED_EAPIS: 7
> # @BLURB: basic eclass for building software written as go modules
> # @DESCRIPTION:
> -# This eclass provides basic settings and functions
> -# needed by all software written in the go programming language that uses
> -# go modules.
> +# This eclass provides basic settings and functions needed by all software
> +# written in the go programming language that uses go modules.
> +#
> +# You might know the software you are packaging uses modules because
> +# it has files named go.sum and go.mod in its top-level source directory.
> +# If it does not have these files, try use the golang-* eclasses FIRST!
> +# There ARE legacy Golang packages that use external modules with none of
> +# go.mod, go.sum, vendor/ that can use this eclass regardless.
> +#
> +# Guidelines for usage:
> +# "go.mod" && "go.sum" && "vendor/":
> +# - pre-vendored package. Do NOT set EGO_SUM or EGO_VENDOR.
> +#
> +# "go.mod" && "go.sum":
> +# - Populate EGO_SUM with entries from go.sum
> +# - Do NOT include any lines that contain /go.mod
> +#
> +# "go.mod" only:
> +# - Populate EGO_VENDOR
> #
> -# You will know the software you are packaging uses modules because
> -# it will have files named go.sum and go.mod in its top-level source
> -# directory. If it does not have these files, use the golang-* eclasses.
> +# None of the above:
> +# - Did you try golang-* eclasses first? Upstream has undeclared dependencies
> +# (perhaps really old source). You can use either EGO_SUM or EGO_VENDOR.
> +
> #
> -# If it has these files and a directory named vendor in its top-level
> -# source directory, you only need to inherit the eclass since upstream
> -# is vendoring the dependencies.
> +# If it has these files AND a directory named "vendor" in its top-level
> source
> +# directory, you only need to inherit the eclass since upstream has already
> +# vendored the dependencies.
> +
> +# If it does not have a vendor directory, you should use the EGO_SUM
> +# variable and the go-module_gosum_uris function as shown in the
> +# example below to handle dependencies.
> #
> -# If it does not have a vendor directory, you should use the EGO_VENDOR
> +# Alternatively, older versions of this eclass used the EGO_VENDOR
> # variable and the go-module_vendor_uris function as shown in the
> # example below to handle dependencies.
> #
> @@ -28,6 +52,21 @@
> # dependencies. So please make sure it is accurate.
> #
> # @EXAMPLE:
> +# @CODE
> +#
> +# inherit go-module
> +#
> +# EGO_SUM=(
> +#"github.com/BurntSushi/toml v0.3.1
> h1:WXkYYl6Yr3qBf1K79EBnL4mak0OimBfB0XUf9Vl28OQ="
> +#"github.com/BurntSushi/toml v0.3.1/go.mod
> h1:WXkYYl6Yr3qBf1K79EBnL4mak0OimBfB0XUf9Vl28OQ="
Is it expected that the two entries would have the same hash?
> +# )
> +# S="${WORKDIR}/${MY_P}"
> +# go-module_set_globals
> +#
> +# SRC_URI="https://github.com/example/${PN}/archive/v${PV}.tar.gz ->
> ${P}.tar.gz
> +# ${EGO_SUM_SRC_URI}"
> +#
> +# @CODE
> #
> # @CODE
> #
> @@ -35,7 +74,7 @@
> #
> # EGO_VENDOR=(
> #"github.com/xenolf/lego 6cac0ea7d8b28c889f709ec7fa92e92b82f490dd"
> -# "golang.org/x/crypto 453249f01cfeb54c3d549ddb75ff152ca243f9d8
> github.com/golang/crypto"
> +#"golang.org/x/crypto 453249f01cfeb54c3d549ddb75ff152ca243f9d8
> github.com/golang/crypto"
> # )
> #
> # SRC_URI="https://github.com/example/${PN}/archive/v${PV}.tar.gz ->
> ${P}.tar.gz
> @@ -64,10 +103,12 @@ export GO111MODULE=on
> export GOCACHE="${T}/go-build"
>
> # The following go flags should be used for all builds.
> -# -mod=vendor stopps downloading of dependencies from the internet.
> # -v prints the names of packages as they are compiled
> # -x prints commands as they are executed
> -export GOFLAGS="-mod=vendor -v -x"
> +# -mod=vendor use the vendor directory instead of downloading dependencies
> +# -mod=readonly do not update go.mod/go.sum but fail if updates are needed
> +export GOFLAGS="-v -x -mod=readonly"
> +[[ ${#EGO_VENDOR[@]} -gt 0 ]] && GOFLAGS+=" -mod=vendor"
>
> # Do not complain about CFLAGS etc since
Re: [gentoo-dev] Changes made by acct-* ebuilds
On Wed, Feb 12, 2020 at 8:32 PM Thomas Deutschmann wrote: > In short: It was a very bad decision that acct-* stuff is *changing* > existing stuff. This must be turned of *by default*. Maybe provide a > setting a user can put into make.conf to opt into current, still new, > behavior but by default, a package should never ever make changes to > *existing* user (unless it knows for sure it was the only source > creating that user and nothing was changed since creation which isn't > easy to track). I think it would make sense to add some eclass variables that would turn user.eclass functions into no-ops. I don't agree that this should be happen by default. I suspect the majority of users do not wish to manage system users/groups themselves.
[gentoo-dev] [PATCH] user.eclass: Use more verbose logging
Replace 'einfo' calls with either 'elog' or 'ewarn'. Practically all
messages printed by the eclass functions are important, in particular
regarding account changes and lack of permissions.
Signed-off-by: Michał Górny
---
eclass/user.eclass | 40
1 file changed, 20 insertions(+), 20 deletions(-)
diff --git a/eclass/user.eclass b/eclass/user.eclass
index 9bd0b607eab8..a33915e21192 100644
--- a/eclass/user.eclass
+++ b/eclass/user.eclass
@@ -68,7 +68,7 @@ user_get_nologin() {
# exist.
enewuser() {
if [[ ${EUID} != 0 ]] ; then
- einfo "Insufficient privileges to execute ${FUNCNAME[0]}"
+ ewarn "Insufficient privileges to execute ${FUNCNAME[0]}"
return 0
fi
_assert_pkg_ebuild_phase ${FUNCNAME}
@@ -94,7 +94,7 @@ enewuser() {
if [[ -n $(egetent passwd "${euser}") ]] ; then
return 0
fi
- einfo "Adding user '${euser}' to your system ..."
+ elog "Adding user '${euser}' to your system ..."
# options to pass to useradd
local opts=()
@@ -122,7 +122,7 @@ enewuser() {
[[ ${euid} -ge 101 ]] || die "${FUNCNAME}: no free UID found"
fi
opts+=( -u ${euid} )
- einfo " - Userid: ${euid}"
+ elog " - Userid: ${euid}"
# handle shell
local eshell=$1; shift
@@ -138,7 +138,7 @@ enewuser() {
else
eshell=$(user_get_nologin)
fi
- einfo " - Shell: ${eshell}"
+ elog " - Shell: ${eshell}"
opts+=( -s "${eshell}" )
# handle homedir
@@ -146,7 +146,7 @@ enewuser() {
if [[ -z ${ehome} ]] || [[ ${ehome} == "-1" ]] ; then
ehome="/dev/null"
fi
- einfo " - Home: ${ehome}"
+ elog " - Home: ${ehome}"
opts+=( -d "${ehome}" )
# handle groups
@@ -171,7 +171,7 @@ enewuser() {
opts+=( -G "${exgroups:1}" )
fi
fi
- einfo " - Groups: ${egroups:-(none)}"
+ elog " - Groups: ${egroups:-(none)}"
# handle extra args
if [[ $# -gt 0 ]] ; then
@@ -179,7 +179,7 @@ enewuser() {
else
local comment="added by portage for ${PN}"
opts+=( -c "${comment}" )
- einfo " - GECOS: ${comment}"
+ elog " - GECOS: ${comment}"
fi
# add the user
@@ -204,7 +204,7 @@ enewuser() {
esac
if [[ -n ${create_home} && ! -e ${ROOT}/${ehome} ]] ; then
- einfo " - Creating ${ehome} in ${ROOT}"
+ elog " - Creating ${ehome} in ${ROOT}"
mkdir -p "${ROOT}/${ehome}"
chown "${euser}" "${ROOT}/${ehome}"
chmod 755 "${ROOT}/${ehome}"
@@ -223,7 +223,7 @@ enewuser() {
# can not be assigned.
enewgroup() {
if [[ ${EUID} != 0 ]] ; then
- einfo "Insufficient privileges to execute ${FUNCNAME[0]}"
+ ewarn "Insufficient privileges to execute ${FUNCNAME[0]}"
return 0
fi
_assert_pkg_ebuild_phase ${FUNCNAME}
@@ -248,7 +248,7 @@ enewgroup() {
if [[ -n $(egetent group "${egroup}") ]] ; then
return 0
fi
- einfo "Adding group '${egroup}' to your system ..."
+ elog "Adding group '${egroup}' to your system ..."
# handle gid
local egid=$1; shift
@@ -266,7 +266,7 @@ enewgroup() {
[[ -n ${force_gid} ]] && die "${FUNCNAME}: -F with gid==-1
makes no sense"
egid="next available"
fi
- einfo " - Groupid: ${egid}"
+ elog " - Groupid: ${egid}"
# handle extra
if [[ $# -gt 0 ]] ; then
@@ -351,12 +351,12 @@ esethome() {
return 0
fi
- einfo "Updating home for user '${euser}' ..."
- einfo " - Home: ${ehome}"
+ elog "Updating home for user '${euser}' ..."
+ elog " - Home: ${ehome}"
# ensure home directory exists, otherwise update will fail
if [[ ! -e ${ROOT}/${ehome} ]] ; then
- einfo " - Creating ${ehome} in ${ROOT}"
+ elog " - Creating ${ehome} in ${ROOT}"
mkdir -p "${ROOT}/${ehome}"
chown "${euser}" "${ROOT}/${ehome}"
chmod 755 "${ROOT}/${ehome}"
@@ -420,8 +420,8 @@ esetshell() {
return 0
fi
- einfo "Updating shell for user '${euser}' ..."
- einfo " - Shell: ${eshell}"
+ elog "Updating shell for user '${euser}' ..."
+ elog " - Shell: ${eshell}"
# update the shell
case ${CHOST} in
@@ -476,8 +476,8 @@ esetcomment() {
return 0
fi
- einfo "Updating comment for user '${euser}' ..."
- einfo " - Comment: ${ecomment}"
+ elog "Updating comment for user '${euser}' ..."
+ elog " - Comment: ${ecomment}"
# update the comment
case ${CHOST} in
@@ -546,8 +546,8 @@
Re: [gentoo-dev] Changes made by acct-* ebuilds
On Thu, 2020-02-13 at 08:09 -0800, Christopher Head wrote: > On Wed, 12 Feb 2020 19:14:45 +0100 > Michał Górny wrote: > > > I'm pretty sure user.eclass does print whatever changes it is doing. > > It isn't elog-ged though, I admit. This is probably worth fixing. > > Yes, I meant elog; sorry about the unclear wording. I generally don’t > even see ordinary print output—most of my machines run emerge -jN where > it isn’t shown at all, and even on the serial ones, there’s so much > build output from a few dozen packages that I’m not going to scroll up > looking for specific things which may have been lost from scrollback > anyway. Just sent a patch to -dev. -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [PATCH] metadata/install-qa-check.d/60appdata-path: new check
On Wed, 12 Feb 2020 23:39:11 -0800 Georgy Yakovlev wrote: > + eqawarn "For more details, please see the > freedesktop Upstrem Metadate guidelines" Couple of typos here: s/Upstrem/Upstream/, s/Metadate/Metadata/. -- Christopher Head pgp6oJDIFyQwY.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] Changes made by acct-* ebuilds
On Wed, 12 Feb 2020 19:14:45 +0100 Michał Górny wrote: > I'm pretty sure user.eclass does print whatever changes it is doing. > It isn't elog-ged though, I admit. This is probably worth fixing. Yes, I meant elog; sorry about the unclear wording. I generally don’t even see ordinary print output—most of my machines run emerge -jN where it isn’t shown at all, and even on the serial ones, there’s so much build output from a few dozen packages that I’m not going to scroll up looking for specific things which may have been lost from scrollback anyway. -- Christopher Head pgpRLsOnQ3l5k.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH 3/3] app-admin/kube-bench: convert to go-module go.sum
On Thu, Feb 13, 2020 at 06:46:43PM +1100, Sam Jorna (wraeth) wrote: > On Thursday, 13 February 2020 5:40:46 AM AEDT Matt Turner wrote: > > On Wed, Feb 12, 2020 at 9:59 AM William Hubbs wrote: > > > On Wed, Feb 12, 2020 at 06:54:19PM +1100, Sam Jorna (wraeth) wrote: > > > > On Monday, 10 February 2020 7:55:01 AM AEDT Michał Górny wrote: > > > > > On Sun, 2020-02-09 at 20:38 +, Michael 'veremitz' Everitt wrote: > > > > > > Hrm, pardon my ignorance, but do 'we' really need to review 232 > > > > > > lines of > > > > > > Manifest?! > > > > > > > > > > Pardon mine but do 'we' really need to read your useless comments > > > > > everywhere, all the time and just get irritated for no benefit to > > > > > Gentoo? > > > > > > > > Perhaps I'm the one being ignorant here, but why are we lambasting > > > > someone for seeking clarification about an unusual inclusion on a > > > > review thread?> > > > I wasn't going to say anything, but I can't let this go by without > > > commenting. > > > > > > Sam is correct. Maybe the tone is a bit off, (and that is debatable), > > > but this definitely can be seen as a legit question, regardless of other > > > things Michael has posted. > > > > Unfortunately it's not about a single issue or email. It's a > > consistent pattern that multiple people have asked him to rein in over > > a long period. :( > > Without going into specifics, veremit and I have certainly had our > 'differences > of opinion' in the past; but I don't believe this is one of those occasions. > > Calling out bad actors (not saying veremit is one, I just mean in the general > sense) is an unfortunate but important task, but call them out on bad > behaviour, not for what appears to be an impassioned but otherwise > unremarkable query. > I agree with this 100 percent. Not judging solely on the content of the specific email in the thread does not allow people to grow and improve. Are we all to be judged on our past behavior forever with no chance to overcome past transgressions ? > -- > Sam Jorna (wraeth) > GnuPG ID: 0xD6180C26 > -- Mike Pagano Gentoo Developer - Kernel Project Gentoo Sources - Member E-Mail : mpag...@gentoo.org GnuPG FP : EEE2 601D 0763 B60F 848C 9E14 3C33 C650 B576 E4E3 Public Key : http://pgp.mit.edu:11371/pks/lookup?search=0xB576E4E3=index
Re: [gentoo-dev] Changes made by acct-* ebuilds
On Wed, 2020-02-12 at 23:03 -0800, Alec Warner wrote: > On Wed, Feb 12, 2020 at 9:59 PM Michał Górny wrote: > > > On Thu, 2020-02-13 at 02:32 +0100, Thomas Deutschmann wrote: > > > Hi, > > > > > > thank you for bringing this to the list. > > > > > > I have the same experience which is the reason why I haven't migrated > > > most of my packages yet (which is not a good move because I also didn't > > > post the problem to the list like I wanted *yet*, I only talked to > > > people via private mail, chat or at FOSDEM about that and was working on > > > a proposal I wanted to show next week when I am hopefully healthy again). > > > > > > > In other words, instead of bringing the problem up to the person who > > created the GLEP and the eclasses and/or community at large, you've been > > conspiring behind their back. Yes, that's really the procommunity > > attitude we expect from Council members. Thanks for showing it again. > > > > This is a bit of a double standard. Either people are 'conspiring behind > your back' or they 'are gathering data for a counterproposal.' There is no > need to paint a negative narrative here. > Yes, I certainly do have a reason to assume positive from someone who apparently mounts a counterproposal without bothering to consider the original reasons. -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
