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

2021-01-03 Thread Robin H. Johnson


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-portage-dev] [PATCH gentoolkit] eclean: Add --changed-iuse flag

2021-01-03 Thread Zac Medico
On 1/2/21 4:08 PM, Matt Turner wrote:
> Allows binpkgs to be deleted if they are not usable due to IUSE changes.
> ---
> Just kind of spitballing. I'm not sure about what USE flags we should
> ignore or whether it should be configurable, etc. On one hand, deleting
> binpkgs that don't have a newly added PYTHON_TARGET option might make
> sense if your binhost is configured to rebuild the package. On the
> other, you probably don't want to throw out amd64 binpkgs because
> abi_riscv_* was added.

The special case for abi_* flags is ugly. Why not do emerge emerge
--changed-use, and ignore changed IUSE for flags that aren't enabled?
-- 
Thanks,
Zac



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] [RFC] New go.gentoo.org url shortener

2021-01-03 Thread Joonas Niilola


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

2021-01-03 Thread Michael Orlitzky

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

2021-01-03 Thread Alec Warner
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

2021-01-03 Thread Mike Gilbert
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

2021-01-03 Thread Thomas Deutschmann
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

2021-01-03 Thread Michał Górny
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

2021-01-03 Thread Mike Gilbert
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

2021-01-03 Thread Mike Gilbert
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

2021-01-03 Thread Mike Gilbert
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

2021-01-03 Thread Jonas Stein

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

2021-01-03 Thread Remco Rijnders
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

2021-01-03 Thread Mike Gilbert
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

2021-01-03 Thread James Le Cuirot
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

2021-01-03 Thread James Le Cuirot
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