Re: [gentoo-dev] [PATCH] acct-user.eclass: don't modify existing user by default
Whissi's patch in itself is a good step forward, but I don't feel it goes far enough, nor promotes better defaults for the unmodified cases. On Mon, Jan 04, 2021 at 02:35:58AM +0100, Thomas Deutschmann wrote: > Modifying an existing user is a bad default and makes Gentoo > special because it is common for system administrators to make > modifications to user (i.e. putting an user into another service's > group to allow that user to access service in question) and it > would be unexpected to see these changes reverted during normal > world upgrade (which could break services). > > This commit will make Gentoo behave like any other Linux distribution > by respecting any user modifications by default. However, we will retain > the functionality to reset system user and groups and users interested > in this feature can opt-in by setting > ACCT_USER_ALLOW_EXISTING_USER_TO_BE_MODIFIED to a non-zero value in > their make.conf. No default is good, and that's the mess here. The problem has started to happen in other distros as well, not just Gentoo. usermod/gpasswd in RPM specfiles, as well as Debian controls. As a sysadmin, I don't want stuff messing with the system users I have in place; but if upstream requirements change on a package impacting user/group layout, I also expect packaging to track it. Many years ago, qmail did this, introducing an additional user to further separate privileges. Unfortunately, these two things are in conflict, and I don't feel there is an easy answer. It's NOT the binary decision of: - let packagers change system user - force sysadmins to always change users manually Nor a single knob that selects between that binary. We need a compromise. The best I can come up with at the moment, is that any packaging should detect if there are user modifications, and provide control to users based on that fact. - if unmodified: interactive, or auto-accept, or deny - if modified: interactive, or auto-accept, or deny These are two distinct config knobs (I'm ok with a default value that populates both of them). This leads to secondary parts: - what if the packaging change regarding users/groups is absolutely mandatory for the new version of a package to work correctly? - what about conflicting user requirements? Antarus raised the HOMEDIR of the git user for gitolite vs gitea. I think in this case, the packages should detect the problematic conditions and abort, in pkg_pretend and/or pkg_setup (thinking about binpkgs here, pkg_pretend might be too early if acct-user/X needs to merged before the check is expected to succeed). These checks MUST be in the package that consumes/depends on acct-user or acct-group packages. Yes, this means constants are likely to be duplicated, but I'm ok with that, because they are also likely to be specifically versioned. -- Robin Hugh Johnson Gentoo Linux: Dev, Infra Lead, Foundation Treasurer E-Mail : robb...@gentoo.org GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85 GnuPG FP : 7D0B3CEB E9B85B1F 825BCECF EE05E6F6 A48F6136 signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] New go.gentoo.org url shortener
On 12/8/20 3:55 PM, Max Magorsch wrote: > Hi all, > > the tl;dr is that I've set up a new url shortener which is available > on https://go.gentoo.org/ currently. It can generate short links like > 'go.gentoo.org/XXX' or you can create custom persistent links like > 'go.gentoo.org/arzano/tyrian' or 'go.gentoo.org/infra/hashicorp'. > Basically, I'm looking for some quick feedback whether you consider > this as useful or don't think you would use it much, to decide whether > it's worth offering this service. > > As mentioned the url-shortener is deployed on https://go.gentoo.org > currently. The source code is available at [0]. It's only accessible > by Gentoo developers using Gentoo SSO for the authentication. You can > log in using your nickname and your ldap password. Basically two use > cases are supported: > > 1) Just paste a link and get an automatically shortened url like > 'go.gentoo.org/XXX'. This is pretty much the normal url shortener > functionality. > > 2) You can paste a link and create a custom persistent link using a > prefix like 'go.gentoo.org/$prefix/$custom'. Allowed prefixes are the > nickname of the developer that is logged in or a project the developer > is part of. Thus I for one could create links like > 'go.gentoo.org/arzano/tyrian' or 'go.gentoo.org/infra/hashicorp'. > However, I would e.g. not be able to create > 'go.gentoo.org/qa/policy-guide' as I am not part of the qa project. > Only members of the QA team could create that link. That's also the > reason I've been coming up with this, as this way every developer / > every project would be able to create custom persistent, nice / short > links. > > However, please note that this is just a first beta version yet and > it's not meant to be production-ready yet. Please feel free to test it > though. In general, I'm looking for some feedback on whether you would > be interested in the two functionalities to get a feeling whether it's > worth spending time on this / offering this service at all. > Also I would be especially interested whether you consider the second > functionality as useful. Because if we just want the first > functionality, we can simplify this and just use any of the > url-shorteners that are already out there, instead of using the > solution I have built. > > /M > > [0] https://gitweb.gentoo.org/sites/go-gentoo.git/ > Hi, well my first impressions are that there are few major issues why I wouldn't use this: - for an URL shortener the final URL isn't really that short (there are multiple alternatives), - not a CLI tool to handle this (yet at least), - login would be REQUIRED so people won't spread malicious links with "gentoo.org" in it, or at least the accounts can be disabled. Although I do like the idea of team-specific links, in the end I fear there'd be many dead links and no one to clean/check those. So in the documents we're better at referring to the original source. -- juippis OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH] acct-user.eclass: don't modify existing user by default
On 1/3/21 8:35 PM, Thomas Deutschmann wrote:
Modifying an existing user is a bad default and makes Gentoo
special because it is common for system administrators to make
modifications to user (i.e. putting an user into another service's
group to allow that user to access service in question) and it
would be unexpected to see these changes reverted during normal
world upgrade (which could break services).
It would be nice if this was well-supported by the official way of
modifying system users/groups; that is, by using an overlay with
modified user/group ebuilds.
Right now it's awkward to do because of the way the eclasses are
structured. For example, some of our servers allow the "postfix" user to
write to OpenDKIM's socket, but only on our *outgoing* mail servers (not
on the incoming MX, where no signing takes place.) This is accomplished
by creating an acct-group/dkimsocket ebuild (ok so far), and then by
overriding the acct-user/postfix ebuild:
EAPI=7
inherit acct-user
DESCRIPTION="user for postfix daemon"
IUSE="dkimsocket"
ACCT_USER_ID=207
ACCT_USER_GROUPS=( postfix mail )
acct-user_add_deps
# This needs to be done outside of acct-user_add_deps because we can't
# test use flags in global scope, and therefore we can't add groups
# to ACCT_USER_GROUPS before calling acct-user_add_deps.
RDEPEND+=" dkimsocket? ( acct-group/dkimsocket )"
pkg_setup() {
# https://wiki.gentoo.org/wiki/OpenDKIM
#
# Even though we added the group to RDEPEND manually, we still
# need to add it to the array.
if use dkimsocket; then
ACCT_USER_GROUPS+=( dkimsocket )
fi
}
That's the common case of adding a system user to a group, and it's
pretty ugly, so it's no wonder that people want to use "usermod" and
then ignore subsequent changes by the PM.
And there's probably a backwards-compatible way we could support
USE-conditional supplementary groups.
Re: [gentoo-dev] [PATCH] acct-user.eclass: don't modify existing user by default
On Sun, Jan 3, 2021 at 6:42 PM Mike Gilbert wrote:
>
> On Sun, Jan 3, 2021 at 8:35 PM Thomas Deutschmann wrote:
> >
> > Modifying an existing user is a bad default and makes Gentoo
> > special because it is common for system administrators to make
> > modifications to user (i.e. putting an user into another service's
> > group to allow that user to access service in question) and it
> > would be unexpected to see these changes reverted during normal
> > world upgrade (which could break services).
> >
> > This commit will make Gentoo behave like any other Linux distribution
> > by respecting any user modifications by default. However, we will retain
> > the functionality to reset system user and groups and users interested
> > in this feature can opt-in by setting
> > ACCT_USER_ALLOW_EXISTING_USER_TO_BE_MODIFIED to a non-zero value in
> > their make.conf.
>
> So the main problem I see with doing this is that it becomes
> impossible to reliably make changes to a user in later ebuild
> revisions. Developers may want/need to deploy changes to user
> attributes. Changing group memberships seems like the best example,
> but I could foresee a want/need to change DESCRIPTION, HOME, or SHELL
> as well.
I think the TL;DR is I don't believe changes in HOME, or SHELL are
safe to do in later revisions. This means developers:
- Need to be careful when picking em!
- Can use later revisions to set sane defaults for fresh installs.
- Can't touch existing installs because changing HOME and SHELL can
cause user-facing breakage.
Often if HOME points somewhere that isn't /dev/null, you have to do
some kind of migration. I'd rather not enable that sort of breakage by
default because it's a per-app / per-user migration pain.
To pick an example:
The git user has a HOME in either /var/lib/gitea or /var/lib/gitolite.
If you change it, you will break whatever service is running.
This is the same for any service account whose $HOME stores
state...which is most of them with a HOME set.
-A
>
> Because of this, I think the new behavior should be opt-in, and people
> who use it should be aware that they will need to pay attention if any
> account changes are rolled out in new ebuild versions.
>
> > diff --git a/eclass/acct-user.eclass b/eclass/acct-user.eclass
> > index 22b0038fbff7..d60b1e53b4bb 100644
> > --- a/eclass/acct-user.eclass
> > +++ b/eclass/acct-user.eclass
> > @@ -309,6 +321,20 @@ acct-user_pkg_pretend() {
> > fi
> > }
> >
> > +# @FUNCTION: acct-user_pkg_setup
> > +# @DESCRIPTION:
> > +# Initialize internal environment variable(s).
> > +acct-user_pkg_setup() {
> > + 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
> > +}
>
> I don't think this pkg_setup function is necessary; you could do this
> in pkg_preinst instead, before enewuser gets called.
>
Re: [gentoo-dev] [PATCH] acct-user.eclass: don't modify existing user by default
On Sun, Jan 3, 2021 at 8:35 PM Thomas Deutschmann wrote:
>
> Modifying an existing user is a bad default and makes Gentoo
> special because it is common for system administrators to make
> modifications to user (i.e. putting an user into another service's
> group to allow that user to access service in question) and it
> would be unexpected to see these changes reverted during normal
> world upgrade (which could break services).
>
> This commit will make Gentoo behave like any other Linux distribution
> by respecting any user modifications by default. However, we will retain
> the functionality to reset system user and groups and users interested
> in this feature can opt-in by setting
> ACCT_USER_ALLOW_EXISTING_USER_TO_BE_MODIFIED to a non-zero value in
> their make.conf.
So the main problem I see with doing this is that it becomes
impossible to reliably make changes to a user in later ebuild
revisions. Developers may want/need to deploy changes to user
attributes. Changing group memberships seems like the best example,
but I could foresee a want/need to change DESCRIPTION, HOME, or SHELL
as well.
Because of this, I think the new behavior should be opt-in, and people
who use it should be aware that they will need to pay attention if any
account changes are rolled out in new ebuild versions.
> diff --git a/eclass/acct-user.eclass b/eclass/acct-user.eclass
> index 22b0038fbff7..d60b1e53b4bb 100644
> --- a/eclass/acct-user.eclass
> +++ b/eclass/acct-user.eclass
> @@ -309,6 +321,20 @@ acct-user_pkg_pretend() {
> fi
> }
>
> +# @FUNCTION: acct-user_pkg_setup
> +# @DESCRIPTION:
> +# Initialize internal environment variable(s).
> +acct-user_pkg_setup() {
> + 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
> +}
I don't think this pkg_setup function is necessary; you could do this
in pkg_preinst instead, before enewuser gets called.
[gentoo-dev] [PATCH] acct-user.eclass: don't modify existing user by default
Modifying an existing user is a bad default and makes Gentoo
special because it is common for system administrators to make
modifications to user (i.e. putting an user into another service's
group to allow that user to access service in question) and it
would be unexpected to see these changes reverted during normal
world upgrade (which could break services).
This commit will make Gentoo behave like any other Linux distribution
by respecting any user modifications by default. However, we will retain
the functionality to reset system user and groups and users interested
in this feature can opt-in by setting
ACCT_USER_ALLOW_EXISTING_USER_TO_BE_MODIFIED to a non-zero value in
their make.conf.
Signed-off-by: Thomas Deutschmann
---
eclass/acct-user.eclass | 40 ++--
1 file changed, 38 insertions(+), 2 deletions(-)
diff --git a/eclass/acct-user.eclass b/eclass/acct-user.eclass
index 22b0038fbff7..d60b1e53b4bb 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_ALLOW_EXISTING_USER_TO_BE_MODIFIED
+# @DESCRIPTION:
+# If set to a non-null value, the eclass is allowed to make changes
+# to an already existing user which will include overriding any
+# changes made by system administrator.
+: ${ACCT_USER_ALLOW_EXISTING_USER_TO_BE_MODIFIED:=}
+
# @ECLASS-VARIABLE: ACCT_USER_SHELL
# @DESCRIPTION:
# The shell to use for the user. If not specified, a 'nologin' variant
@@ -266,8 +278,8 @@ eunlockuser() {
# << Phase functions >>
-EXPORT_FUNCTIONS pkg_pretend src_install pkg_preinst pkg_postinst \
- pkg_prerm
+EXPORT_FUNCTIONS pkg_pretend pkg_setup src_install pkg_preinst \
+ pkg_postinst pkg_prerm
# @FUNCTION: acct-user_pkg_pretend
# @DESCRIPTION:
@@ -309,6 +321,20 @@ acct-user_pkg_pretend() {
fi
}
+# @FUNCTION: acct-user_pkg_setup
+# @DESCRIPTION:
+# Initialize internal environment variable(s).
+acct-user_pkg_setup() {
+ 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
+}
+
# @FUNCTION: acct-user_src_install
# @DESCRIPTION:
# Installs a keep-file into the user's home directory to ensure it is
@@ -379,6 +405,16 @@ acct-user_pkg_postinst() {
return 0
fi
+ if [[ -z ${ACCT_USER_ALLOW_EXISTING_USER_TO_BE_MODIFIED} && -n
${ACCT_USER_ALREADY_EXISTS} ]] ; then
+ eunlockuser "${ACCT_USER_NAME}"
+
+ einfo "User ${ACCT_USER_NAME} already exists; Not touching
existing user."
+ einfo "NOTE: If you want to allow package manager to reset user
settings"
+ einfo " like home, shell, groups... set
ACCT_USER_ALLOW_EXISTING_USER_TO_BE_MODIFIED"
+ einfo " to a non-null value in your make.conf."
+ 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
[gentoo-dev] [News review] LibreSSL support discontinued
Hello, Please review the news item inlined below. This is based on what I discussed with blueness (LibreSSL team lead). The news item is kinda long-ish because I wanted to include the full rationale since I believe our users will find it desirable to know it. If it's ok, I'd like to push it soonish. This will give people around 4 weeks to prepare and/or migrate their systems manually before being hit by the masks. Afterwards, we'll mask libressl with a prolonged removal date. I'm thinking of 3 months since I suspect that our packages will start strongly requiring OpenSSL by then. I'm mentioning the LibreSSL overlay since one of our users is interested in maintaining it. It will probably be the best alternative for users who want to continue fighting the lost cause without causing major problems for Gentoo mainline. --- Title: LibreSSL support discontinued Author: Michał Górny Posted: 202x-xx-xx Revision: 1 News-Item-Format: 2.0 Display-If-Installed: dev-libs/libressl Starting 2021-02-01, Gentoo will no longer actively pursue supporting dev-libs/libressl as an alternative to dev-libs/openssl. While it will still be possible for expert users to use LibreSSL on their systems, we are only going to provide support for OpenSSL-based systems. Most importantly, we are no longer going to maintain downstream patches for LibreSSL support -- it will rely on either package upstreams merging such patches themselves, or LibreSSL upstream finally working towards better OpenSSL compatibility. On 2021-02-01, we will mask the relevant USE flags and packages. If you wish to continue using LibreSSL, you will be able to undo these masks for the time being. However, as packages drop patching for LibreSSL and the library is eventually removed from ::gentoo, it will become necessary to use the user-maintained LibreSSL overlay [1]. As long-term support for LibreSSL is not guaranteed, we recommend switching to OpenSSL instead. The more information on removal can be found on the relevant bug [2]. To switch before the aforementioned date, remove 'libressl' from your USE flags and CURL_SSL targets. Afterwards, it is recommended to prefetch all the necessary distfiles before proceeding with the system upgrade, in case wget(1) becomes broken in the process: emerge --fetchonly dev-libs/openssl net-misc/wget emerge --fetchonly --changed-use @world A --changed-use @world upgrade should automatically cause LibreSSL to be replaced by OpenSSL, and all affected packages to be rebuilt: emerge --changed-use @world LibreSSL has been forked off OpenSSL in 2014 to address a number of problems with the original package. However, since then OpenSSL development gained speed and the original reasons for the fork no longer apply. Furthermore, LibreSSL started to repeatedly fall behind and cause growing compatibility problems. While initially these problems were related to packages using old/insecure OpenSSL APIs, today they are mostly related to LibreSSL missing newer OpenSSL APIs (yet declaring false compatibility with newer OpenSSL versions). With the little testing it gets, our developers and users had to put a significant effort into fixing upstream packages. In some cases (e.g. Qt), the upstream has explicitly refused to support LibreSSL, requiring us to maintain the patches forever. This in turn means that security fixes, regular version bumps or end-user system upgrades are often delayed because of necessary LibreSSL patching. What is even worse, major runtime issues managed to sneak in that broke production systems running LibreSSL in the past. To the best of our knowledge, the only benefit LibreSSL has over OpenSSL right now is the additional libtls library. For this reason, we have packaged dev-libs/libretls which is a port of this library that links to OpenSSL. All these issued considered, we came to the conclusion that OpenSSL should remain the only supported production option for Gentoo systems. While the flexibility of Gentoo should make it possible to keep using LibreSSL going forward, the effort necessary to provide a first-class official support for LibreSSL has proven to outweigh the benefit. [1] https://gitweb.gentoo.org/repo/proj/libressl.git/tree/README.md [2] https://bugs.gentoo.org/762847 --- -- Best regards, Michał Górny
[gentoo-dev] [PATCH 3/3] udev.eclass: copy sysroot/prefix logic from systemd.eclass
Signed-off-by: Mike Gilbert
---
eclass/udev.eclass | 18 --
1 file changed, 16 insertions(+), 2 deletions(-)
diff --git a/eclass/udev.eclass b/eclass/udev.eclass
index 9a65b080f171..8e256385f8ef 100644
--- a/eclass/udev.eclass
+++ b/eclass/udev.eclass
@@ -50,11 +50,25 @@ fi
# @DESCRIPTION:
# Get unprefixed udevdir.
_udev_get_udevdir() {
- local udevdir="/lib/udev"
+ local udevdir="/lib/udev" eprefix
+
+ if [[ ${EAPI:-0} == [0123456] ]]; then
+ eprefix=${EPREFIX}
+ else
+ # Derive from ESYSROOT due to weird PMS logic.
+ eprefix=${ESYSROOT#${SYSROOT}}
+ fi
+
if $(tc-getPKG_CONFIG) --exists udev; then
udevdir="$($(tc-getPKG_CONFIG) --variable=udevdir udev)" || die
- udevdir="${udevdir#${EPREFIX}}"
+
+ # Remove SYSROOT in case PKG_CONFIG_SYSROOT_DIR is set by
cross-pkg-config.
+ d=${udevdir#${SYSROOT}}
+
+ # Remove any offset prefix.
+ d=${udevdir#${eprefix}}
fi
+
echo "${udevdir}"
}
--
2.30.0
[gentoo-dev] [PATCH 2/3] systemd.eclass: rework prefix logic for EAPI 7
Signed-off-by: Mike Gilbert
---
eclass/systemd.eclass | 15 +--
1 file changed, 13 insertions(+), 2 deletions(-)
diff --git a/eclass/systemd.eclass b/eclass/systemd.eclass
index f6d1fa2d92d6..9f439238fe6c 100644
--- a/eclass/systemd.eclass
+++ b/eclass/systemd.eclass
@@ -46,12 +46,23 @@ fi
# instead.
_systemd_get_dir() {
[[ ${#} -eq 2 ]] || die "Usage: ${FUNCNAME}
"
- local variable=${1} fallback=${2} d
+ local variable=${1} fallback=${2} d eprefix
+
+ if [[ ${EAPI:-0} == [0123456] ]]; then
+ eprefix=${EPREFIX}
+ else
+ # Derive from ESYSROOT due to weird PMS logic.
+ eprefix=${ESYSROOT#${SYSROOT}}
+ fi
if $(tc-getPKG_CONFIG) --exists systemd; then
d=$($(tc-getPKG_CONFIG) --variable="${variable}" systemd) || die
+
+ # Remove SYSROOT in case PKG_CONFIG_SYSROOT_DIR is set by
cross-pkg-config.
d=${d#${SYSROOT}}
- d=${d#${EPREFIX}}
+
+ # Remove any offset prefix.
+ d=${d#${eprefix}}
else
d=${fallback}
fi
--
2.30.0
[gentoo-dev] [PATCH 1/3] udev.eclass: rework _udev_get_udevdir
Rewrite logic to resemble _systemd_get_dir from systemd.eclass.
Remove incorrect command substitution: pkg-config --exists does not
write to stdout.
Die when pkg-config --variable fails.
Signed-off-by: Mike Gilbert
---
eclass/udev.eclass | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/eclass/udev.eclass b/eclass/udev.eclass
index 2873ae9a92c3..9a65b080f171 100644
--- a/eclass/udev.eclass
+++ b/eclass/udev.eclass
@@ -50,12 +50,12 @@ fi
# @DESCRIPTION:
# Get unprefixed udevdir.
_udev_get_udevdir() {
- if $($(tc-getPKG_CONFIG) --exists udev); then
- local udevdir="$($(tc-getPKG_CONFIG) --variable=udevdir udev)"
- echo "${udevdir#${EPREFIX%/}}"
- else
- echo /lib/udev
+ local udevdir="/lib/udev"
+ if $(tc-getPKG_CONFIG) --exists udev; then
+ udevdir="$($(tc-getPKG_CONFIG) --variable=udevdir udev)" || die
+ udevdir="${udevdir#${EPREFIX}}"
fi
+ echo "${udevdir}"
}
# @FUNCTION: udev_get_udevdir
--
2.30.0
[gentoo-dev] Packages up for grabs: dev-db/percona-xtrabackup
Dear all the following packages are up for grabs after retirement of the proxied maintainer: dev-db/percona-xtrabackup https://packages.gentoo.org/packages/dev-db/percona-xtrabackup There are open bugs: https://bugs.gentoo.org/729696 dev-db/percona-xtrabackup fails to compile with clang Please fix this package to prevent that it will be dropped from the tree. There is also dev-db/percona-xtrabackup-bin without maintainer. -- Best, Jonas OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] Dissolving project desktop-misc
On Sun, Nov 29, 2020 at 05:48:41PM +0200, Andreas wrote in <20350427.4csPzL39Zc@farino>: List of packages, please adopt: app-misc/remind I'd like to adopt this one please. https://github.com/gentoo/gentoo/pull/18929
Re: [gentoo-dev] [PATCH] systemd.eclass: remove SYSROOT from pkg-config output
On Sun, Jan 3, 2021 at 7:52 AM James Le Cuirot wrote:
>
> On Sat, 2 Jan 2021 20:09:04 -0500
> Mike Gilbert wrote:
>
> > When cross-compiling, users will typically have
> > PKG_CONFIG_SYSROOT=${SYSROOT} defined via pkg-config wrapper.
> >
> > When PKG_CONFIG_SYSROOT is set, all paths included in pkg-config
> > output get prefixed with this value.
> >
> > Signed-off-by: Mike Gilbert
> > ---
> >
> > This patch has already been pushed, but I figured I would send it for
> > review in case someone else can think of a failure case, or has a better
> > solution.
> >
> > eclass/systemd.eclass | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/eclass/systemd.eclass b/eclass/systemd.eclass
> > index 81065a0af79a..f6d1fa2d92d6 100644
> > --- a/eclass/systemd.eclass
> > +++ b/eclass/systemd.eclass
> > @@ -50,6 +50,7 @@ _systemd_get_dir() {
> >
> > if $(tc-getPKG_CONFIG) --exists systemd; then
> > d=$($(tc-getPKG_CONFIG) --variable="${variable}" systemd) ||
> > die
> > + d=${d#${SYSROOT}}
> > d=${d#${EPREFIX}}
> > else
> > d=${fallback}
>
> I was going to say this is not the best approach as it would be better
> to tell pkg-config to not add the SYSROOT in the first place. I now
> realise we have shot ourselves in the foot with cross-pkg-config as it
> uses SYSROOT to set both PKG_CONFIG_SYSROOT_DIR to control the output
> and PKG_CONFIG_LIBDIR to find the .pc files in the first place. I have
> had prefix-related fixes for cross-pkg-config lined up for over a year
> but unfortunately they do not address this. Trying to accommodate this
> use case would probably just make it more confusing though so maybe
> your approach is best after all.
It would be cleaner overall if we could prevent SYSROOT from being
added to the paths in the first place.
> The EPREFIX line is (sometimes) wrong in EAPI 7 though and the same goes
> for udev.eclass. It took a while to get this agreed and corrected in
> PMS but if SYSROOT points to / then the effective prefix is BROOT, not
> EPREFIX; they may not be the same.
Ugh, that "corrected" logic in PMS head is nasty.
> If you just strip ESYSROOT then
> it will always do the right thing but you'll need this fall back for
> older EAPIs. I'm not sure why you didn't do it in one line?
I was trying to accommodate older EAPIs that do not define ESYSROOT.
This seemed like the simplest approach. It also allows for the case
where someone is not using cross-pkg-config, and
PKG_CONFIG_SYSROOT_DIR is unset. Since SYSROOT and EPREFIX are removed
separately, if one of them is already missing, it will just be
skipped.
> I forget if EPREFIX is normalised to be / rather thank blank.
>
> d=${d#${SYSROOT%/}/${EPREFIX#/}}
SYSROOT never ends with a / in modern versions of portage (regardless
of EAPI), so there's currently no need to remove a trailing slash.
https://gitweb.gentoo.org/proj/portage.git/commit/?id=1b5110557d1dd725f7c12bbed4b7ceaaec29f2a3
I have never seen EPREFIX equal to "/", or end with a trailing slash.
Given it is most commonly used as "${EPREFIX}/usr", this would result
in double-slashes everywhere.
Re: [gentoo-dev] [PATCH] systemd.eclass: remove SYSROOT from pkg-config output
On Sun, 3 Jan 2021 12:52:08 +
James Le Cuirot wrote:
> On Sat, 2 Jan 2021 20:09:04 -0500
> Mike Gilbert wrote:
>
> > When cross-compiling, users will typically have
> > PKG_CONFIG_SYSROOT=${SYSROOT} defined via pkg-config wrapper.
> >
> > When PKG_CONFIG_SYSROOT is set, all paths included in pkg-config
> > output get prefixed with this value.
> >
> > Signed-off-by: Mike Gilbert
> > ---
> >
> > This patch has already been pushed, but I figured I would send it for
> > review in case someone else can think of a failure case, or has a better
> > solution.
> >
> > eclass/systemd.eclass | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/eclass/systemd.eclass b/eclass/systemd.eclass
> > index 81065a0af79a..f6d1fa2d92d6 100644
> > --- a/eclass/systemd.eclass
> > +++ b/eclass/systemd.eclass
> > @@ -50,6 +50,7 @@ _systemd_get_dir() {
> >
> > if $(tc-getPKG_CONFIG) --exists systemd; then
> > d=$($(tc-getPKG_CONFIG) --variable="${variable}" systemd) || die
> > + d=${d#${SYSROOT}}
> > d=${d#${EPREFIX}}
> > else
> > d=${fallback}
>
> I was going to say this is not the best approach as it would be better
> to tell pkg-config to not add the SYSROOT in the first place. I now
> realise we have shot ourselves in the foot with cross-pkg-config as it
> uses SYSROOT to set both PKG_CONFIG_SYSROOT_DIR to control the output
> and PKG_CONFIG_LIBDIR to find the .pc files in the first place. I have
> had prefix-related fixes for cross-pkg-config lined up for over a year
> but unfortunately they do not address this. Trying to accommodate this
> use case would probably just make it more confusing though so maybe
> your approach is best after all.
>
> The EPREFIX line is (sometimes) wrong in EAPI 7 though and the same goes
> for udev.eclass. It took a while to get this agreed and corrected in
> PMS but if SYSROOT points to / then the effective prefix is BROOT, not
> EPREFIX; they may not be the same. If you just strip ESYSROOT then
> it will always do the right thing but you'll need this fall back for
> older EAPIs. I'm not sure why you didn't do it in one line? I forget if
> EPREFIX is normalised to be / rather thank blank.
>
> d=${d#${SYSROOT%/}/${EPREFIX#/}}
Had another minute to think. EPREFIX always strips the trailing slash
so it would be blank.
d=${d#${SYSROOT%/}${EPREFIX}}
--
James Le Cuirot (chewi)
Gentoo Linux Developer
pgp0JKYoJYsgE.pgp
Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH] systemd.eclass: remove SYSROOT from pkg-config output
On Sat, 2 Jan 2021 20:09:04 -0500
Mike Gilbert wrote:
> When cross-compiling, users will typically have
> PKG_CONFIG_SYSROOT=${SYSROOT} defined via pkg-config wrapper.
>
> When PKG_CONFIG_SYSROOT is set, all paths included in pkg-config
> output get prefixed with this value.
>
> Signed-off-by: Mike Gilbert
> ---
>
> This patch has already been pushed, but I figured I would send it for
> review in case someone else can think of a failure case, or has a better
> solution.
>
> eclass/systemd.eclass | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/eclass/systemd.eclass b/eclass/systemd.eclass
> index 81065a0af79a..f6d1fa2d92d6 100644
> --- a/eclass/systemd.eclass
> +++ b/eclass/systemd.eclass
> @@ -50,6 +50,7 @@ _systemd_get_dir() {
>
> if $(tc-getPKG_CONFIG) --exists systemd; then
> d=$($(tc-getPKG_CONFIG) --variable="${variable}" systemd) || die
> + d=${d#${SYSROOT}}
> d=${d#${EPREFIX}}
> else
> d=${fallback}
I was going to say this is not the best approach as it would be better
to tell pkg-config to not add the SYSROOT in the first place. I now
realise we have shot ourselves in the foot with cross-pkg-config as it
uses SYSROOT to set both PKG_CONFIG_SYSROOT_DIR to control the output
and PKG_CONFIG_LIBDIR to find the .pc files in the first place. I have
had prefix-related fixes for cross-pkg-config lined up for over a year
but unfortunately they do not address this. Trying to accommodate this
use case would probably just make it more confusing though so maybe
your approach is best after all.
The EPREFIX line is (sometimes) wrong in EAPI 7 though and the same goes
for udev.eclass. It took a while to get this agreed and corrected in
PMS but if SYSROOT points to / then the effective prefix is BROOT, not
EPREFIX; they may not be the same. If you just strip ESYSROOT then
it will always do the right thing but you'll need this fall back for
older EAPIs. I'm not sure why you didn't do it in one line? I forget if
EPREFIX is normalised to be / rather thank blank.
d=${d#${SYSROOT%/}/${EPREFIX#/}}
--
James Le Cuirot (chewi)
Gentoo Linux Developer
pgpTmn9Lvd_4Y.pgp
Description: OpenPGP digital signature
