Re: [gentoo-dev] [PATCH] Add 2021-06-30-libxcrypt-migration
On Sun, 2021-06-27 at 07:33 +0100, Sam James wrote: > Please note that the 2021-07-07 migration date is preliminary. > LGTM. -- Best regards, Michał Górny
[gentoo-dev] [PATCH] Add 2021-06-30-libxcrypt-migration
Please note that the 2021-07-07 migration date is preliminary. Bug: https://bugs.gentoo.org/699422 Signed-off-by: Sam James --- .../2021-06-30-libxcrypt-migration.en.txt | 46 +++ 1 file changed, 46 insertions(+) create mode 100644 2021-06-30-libxcrypt-migration/2021-06-30-libxcrypt-migration.en.txt diff --git a/2021-06-30-libxcrypt-migration/2021-06-30-libxcrypt-migration.en.txt b/2021-06-30-libxcrypt-migration/2021-06-30-libxcrypt-migration.en.txt new file mode 100644 index 000..2dd8b1c --- /dev/null +++ b/2021-06-30-libxcrypt-migration/2021-06-30-libxcrypt-migration.en.txt @@ -0,0 +1,46 @@ +Title: migrating from glibc[crypt] to libxcrypt in ~arch +Author: Andreas K. Hüttel +Author: Sam James +Posted: 2021-06-30 +Revision: 1 +News-Item-Format: 2.0 + +The implementation of libcrypt.so within glibc has been deprecated +for a long time and will be removed in the near future. + +For this reason, we are following other distributions (where +this has been tested for years already) and switching to the +external libxcrypt implementation, starting with ~arch +installations. + +This will be a regular update, and in nearly all cases you +will not have to take any action and not observe any problems. + +We do recommend, however, that your system is *fully* up +to date first. This is a standard recommendation but in this +specific case, it is useful to have a simplified depgraph +to ensure that Portage is able to smoothly calculate +an upgrade path. + +That is, please take the opportunity to fully upgrade your +systems now, before the migration occurs, to simplify matters. + +This change will occur on 2021-07-07 for ~arch users. Stable +users will update at a later date. + +If for whatever reason you do *not* wish to switch now - +which is only delaying the inevitable - you +need to take the following steps: +* unmask and enable the crypt USE flag of sys-libs/glibc +* mask the system USE flag of sys-libs/libxcrypt +* mask >=virtual/libcrypt-2 + +If you wish to manually migrate now, there are a series +of steps described on the wiki (see below), but the outline is: +* unforce the crypt USE flag of sys-libs/glibc and disable it +* unmask the system USE flag of sys-libs/libxcrypt and enable it +* unmask >=virtual/libcrypt-2 + +For more information, please see: +* https://wiki.gentoo.org/wiki/Project:Toolchain/libcrypt_implementation +* https://bugs.gentoo.org/699422 -- 2.32.0
[gentoo-dev] Package up for grabs: x11-plugins/purple-hangouts
x11-plugins/purple-hangouts - Hangouts Plugin for libpurple Doesn't need much work, but I don't use it anymore.
Re: [gentoo-dev] [PATCH] udev.eclass: EAPI 8 support
On Sat, Jun 26, 2021 at 03:24:58PM -0400, David Michael wrote: > # @ECLASS: udev.eclass > # @MAINTAINER: > # udev-b...@gentoo.org > -# @SUPPORTED_EAPIS: 0 1 2 3 4 5 6 7 > +# @SUPPORTED_EAPIS: 5 6 7 8 Wouldn't EAPI-8 be a good occasion to refactor _udev_get_udevdir into keeping EPREFIX? While udev rules don't make much sense on prefix, ebuilds are currently adding EPREFIX to it everywhere so it doesn't fail to install because of rules. signature.asc Description: PGP signature
[gentoo-dev] [PATCH] metadata/install-qa-check.d: add virtual/libcrypt dep check
Bug: https://bugs.gentoo.org/699422
Signed-off-by: Georgy Yakovlev
---
metadata/install-qa-check.d/60libcrypt-deps | 38 +
1 file changed, 38 insertions(+)
create mode 100644 metadata/install-qa-check.d/60libcrypt-deps
diff --git a/metadata/install-qa-check.d/60libcrypt-deps
b/metadata/install-qa-check.d/60libcrypt-deps
new file mode 100644
index ..fd915fb852d7
--- /dev/null
+++ b/metadata/install-qa-check.d/60libcrypt-deps
@@ -0,0 +1,38 @@
+# Copyright 2021 Gentoo Authors
+# Distributed under the terms of the GNU General Public License v2
+
+# QA check: ensure that package specifies a dependency on virtual/libcrypt
+# Author: Georgy Yakovlev
+# Maintainer Sam James
+
+libcrypt_check() {
+ if ! type -P scanelf >/dev/null || has binchecks ${PORTAGE_RESTRICT};
then
+ return
+ fi
+
+ # nothing to do here
+ if grep -q virtual/libcrypt <<<${RDEPEND}; then
+ return
+ fi
+
+ local libcrypt_consumers
+ # grep outputs newline separated list of files, so it's ok to skip
specifying delimiter
+ IFS= mapfile libcrypt_consumers < <(find "${ED}" -type f -executable \
+ -print0 | xargs -0 scanelf -qyRF '%F %n' | grep 'libcrypt.so'
2>/dev/null )
+
+ if [[ -n ${libcrypt_consumers[@]} ]]; then
+ eqawarn "Binary files linked to libcrypt.so found"
+ eqawarn "But dependency on virtual/libcrypt is not declared"
+ eqawarn
+ eqatag -v virtual-libcrypt.missing "${libcrypt_consumers[@]%%
*}"
+ eqawarn
+ eqawarn "Please add virtual/libcrypt dependency"
+ eqawarn "Gentoo Bug: https://bugs.gentoo.org/699422";
+ fi
+
+}
+
+libcrypt_check
+: # guarantee successful exit
+
+# vim:ft=sh
--
2.32.0
Re: [gentoo-dev] 'pax_kernel' USE flag
On Wed, 23 Jun 2021 10:46:00 +0100 Marek Szuba wrote: > On 2021-06-22 19:01, Sergei Trofimovich wrote: > > > One of the steps forward for libffi would be to add extra USE=pax-kernel > > with REQUIRED_USE="pax_kernel? ( pax-kernel )" or 'die' equivalent. > > Sounds like a good idea to me, that way people who don't pay attention > to news items will notice. It's now part of libffi-3.4_rc1: # If you are USE=pax_kernel user you really want USE=pax-kernel as well. # That's a flag rename: https://archives.gentoo.org/gentoo-dev/message/273f5ec9ebc8075f6ee8d8cdda9e759e REQUIRED_USE="pax_kernel? ( pax-kernel )" https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=0b2c89773e0df20c0c770b6d8620564b76468578 -- Sergei
[gentoo-dev] [PATCH] udev.eclass: EAPI 8 support
This also drops EAPIs < 5 to match toolchain-funcs.eclass.
Signed-off-by: David Michael
---
This probably could have been sent in a series with
https://archives.gentoo.org/gentoo-dev/message/22db5157cab5d6d173483fbc16377081
eclass/udev.eclass | 25 +++--
1 file changed, 11 insertions(+), 14 deletions(-)
diff --git a/eclass/udev.eclass b/eclass/udev.eclass
index 2873ae9a92c..7d5f59ab8d9 100644
--- a/eclass/udev.eclass
+++ b/eclass/udev.eclass
@@ -1,10 +1,10 @@
-# Copyright 1999-2018 Gentoo Authors
+# Copyright 1999-2021 Gentoo Authors
# Distributed under the terms of the GNU General Public License v2
# @ECLASS: udev.eclass
# @MAINTAINER:
# udev-b...@gentoo.org
-# @SUPPORTED_EAPIS: 0 1 2 3 4 5 6 7
+# @SUPPORTED_EAPIS: 5 6 7 8
# @BLURB: Default eclass for determining udev directories.
# @DESCRIPTION:
# Default eclass for determining udev directories.
@@ -28,18 +28,17 @@
# }
# @CODE
+case ${EAPI} in
+ 5|6|7|8) ;;
+ *) die "${ECLASS}: EAPI ${EAPI:-0} not supported" ;;
+esac
+
if [[ -z ${_UDEV_ECLASS} ]]; then
_UDEV_ECLASS=1
inherit toolchain-funcs
-case ${EAPI:-0} in
- 0|1|2|3|4|5|6|7) ;;
- *) die "${ECLASS}.eclass API in EAPI ${EAPI} not yet established."
-esac
-
-if [[ ${EAPI:-0} == [0123456] ]]; then
- RDEPEND=""
+if [[ ${EAPI} == [56] ]]; then
DEPEND="virtual/pkgconfig"
else
BDEPEND="virtual/pkgconfig"
@@ -82,8 +81,7 @@ get_udevdir() {
# @FUNCTION: udev_dorules
# @USAGE: [...]
# @DESCRIPTION:
-# Install udev rule(s). Uses doins, thus it is fatal in EAPI 4
-# and non-fatal in earlier EAPIs.
+# Install udev rule(s). Uses doins, thus it is fatal.
udev_dorules() {
debug-print-function ${FUNCNAME} "${@}"
@@ -97,8 +95,7 @@ udev_dorules() {
# @FUNCTION: udev_newrules
# @USAGE:
# @DESCRIPTION:
-# Install udev rule with a new name. Uses newins, thus it is fatal
-# in EAPI 4 and non-fatal in earlier EAPIs.
+# Install udev rule with a new name. Uses newins, thus it is fatal.
udev_newrules() {
debug-print-function ${FUNCNAME} "${@}"
@@ -113,7 +110,7 @@ udev_newrules() {
# @DESCRIPTION:
# Run udevadm control --reload to refresh rules and databases
udev_reload() {
- if [[ ${ROOT} != "" ]] && [[ ${ROOT} != "/" ]]; then
+ if [[ -n ${ROOT%/} ]]; then
return 0
fi
--
2.31.1
[gentoo-dev] [PATCH] autotools.eclass: EAPI 8 support
Signed-off-by: David Michael
---
Hi,
Here is a simple update that is blocking a lot of stuff. It moves the
EAPI check outside the inherit guard for bash future-proofing.
Thanks.
David
eclass/autotools.eclass | 22 +-
1 file changed, 9 insertions(+), 13 deletions(-)
diff --git a/eclass/autotools.eclass b/eclass/autotools.eclass
index b386654c832..214c90d06f9 100644
--- a/eclass/autotools.eclass
+++ b/eclass/autotools.eclass
@@ -4,7 +4,7 @@
# @ECLASS: autotools.eclass
# @MAINTAINER:
# base-sys...@gentoo.org
-# @SUPPORTED_EAPIS: 5 6 7
+# @SUPPORTED_EAPIS: 5 6 7 8
# @BLURB: Regenerates auto* build scripts
# @DESCRIPTION:
# This eclass is for safely handling autotooled software packages that need to
@@ -23,18 +23,15 @@ if [[ ${__AUTOTOOLS_AUTO_DEPEND+set} == "set" ]] ; then
fi
fi
-if [[ -z ${_AUTOTOOLS_ECLASS} ]] ; then
-_AUTOTOOLS_ECLASS=1
-
case ${EAPI} in
- 5|6)
- # Needed for eqawarn
- inherit eutils
- ;;
- 7) ;;
- *) die "${ECLASS}: EAPI ${EAPI} not supported" ;;
+ 5|6) inherit eutils ;; # Needed for eqawarn
+ 7|8) ;;
+ *) die "${ECLASS}: EAPI ${EAPI:-0} not supported" ;;
esac
+if [[ -z ${_AUTOTOOLS_ECLASS} ]] ; then
+_AUTOTOOLS_ECLASS=1
+
inherit gnuconfig libtool
# @ECLASS-VARIABLE: WANT_AUTOCONF
@@ -119,7 +116,6 @@ fi
AUTOTOOLS_DEPEND="${_automake_atom}
${_autoconf_atom}
${_libtool_atom}"
-RDEPEND=""
# @ECLASS-VARIABLE: AUTOTOOLS_AUTO_DEPEND
# @PRE_INHERIT
@@ -131,7 +127,7 @@ RDEPEND=""
if [[ ${AUTOTOOLS_AUTO_DEPEND} != "no" ]] ; then
case ${EAPI} in
5|6) DEPEND=${AUTOTOOLS_DEPEND} ;;
- 7) BDEPEND=${AUTOTOOLS_DEPEND} ;;
+ *) BDEPEND=${AUTOTOOLS_DEPEND} ;;
esac
fi
__AUTOTOOLS_AUTO_DEPEND=${AUTOTOOLS_AUTO_DEPEND} # See top of eclass
@@ -490,7 +486,7 @@ autotools_env_setup() {
5|6)
hv_args="--host-root"
;;
- 7)
+ *)
hv_args="-b"
;;
esac
--
2.31.1
Re: [gentoo-dev] [PATCH 3/4] distutils-r1.eclass: Use 'dosym -r' in EAPI 8
On Sat, 2021-06-26 at 09:58 +0200, Ulrich Mueller wrote:
> > > > > > On Fri, 25 Jun 2021, Michał Górny wrote:
>
> > + local dosym=dosym
> > + [[ ${EAPI} == [67] ]] && dosym=dosym8
> > + "${dosym}" -r /usr/lib/python-exec/python-
> > exec2 \
> > + "${bindir#${EPREFIX}}/${basename}"
>
> Shouldn't the eclass inherit eapi8-dosym in EAPIs 6 and 7?
It relies on python-utils-r1 taking care of that.
--
Best regards,
Michał Górny
Re: [gentoo-dev] [PATCH 3/4] distutils-r1.eclass: Use 'dosym -r' in EAPI 8
> On Fri, 25 Jun 2021, Michał Górny wrote:
> + local dosym=dosym
> + [[ ${EAPI} == [67] ]] && dosym=dosym8
> + "${dosym}" -r /usr/lib/python-exec/python-exec2 \
> + "${bindir#${EPREFIX}}/${basename}"
Shouldn't the eclass inherit eapi8-dosym in EAPIs 6 and 7?
Ulrich
signature.asc
Description: PGP signature
