[gentoo-dev] [PATCH 4/4] eclass/ruby-fakegem.eclass: remove EAPI 4 support
Signed-off-by: Hans de Graaff
---
eclass/ruby-fakegem.eclass | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/eclass/ruby-fakegem.eclass b/eclass/ruby-fakegem.eclass
index 34eeff2fad96..76a80f6b9be2 100644
--- a/eclass/ruby-fakegem.eclass
+++ b/eclass/ruby-fakegem.eclass
@@ -60,7 +60,7 @@ RUBY_FAKEGEM_TASK_TEST="${RUBY_FAKEGEM_TASK_TEST-test}"
# - yard (calls `yard`, adds dev-ruby/yard to the dependencies);
# - none
case ${EAPI} in
- 4|5|6)
+ 5|6)
RUBY_FAKEGEM_RECIPE_DOC="${RUBY_FAKEGEM_RECIPE_DOC-rake}"
;;
*)
@@ -130,7 +130,7 @@ RUBY_FAKEGEM_BINDIR="${RUBY_FAKEGEM_BINDIR-bin}"
RUBY_FAKEGEM_EXTENSION_LIBDIR="${RUBY_FAKEGEM_EXTENSION_LIBDIR-lib}"
case ${EAPI} in
- 4|5|6|7|8) ;;
+ 5|6|7|8) ;;
*) die "${ECLASS}: EAPI ${EAPI:-0} not supported" ;;
esac
@@ -197,7 +197,7 @@
SRC_URI="https://rubygems.org/gems/${RUBY_FAKEGEM_NAME}-${RUBY_FAKEGEM_VERSION}$
ruby_add_bdepend "virtual/rubygems !!dev-ruby/psych"
ruby_add_rdepend virtual/rubygems
case ${EAPI} in
- 4|5|6)
+ 5|6)
;;
*)
ruby_add_depend virtual/rubygems
@@ -312,7 +312,7 @@ ruby_fakegem_metadata_gemspec() {
# See RUBY_FAKEGEM_REQUIRE_PATHS for setting extra require paths.
ruby_fakegem_genspec() {
case ${EAPI} in
- 4|5|6) ;;
+ 5|6) ;;
*)
eqawarn "Generating generic fallback gemspec *without*
dependencies"
eqawarn "This will only work when there are no runtime
dependencies"
--
2.31.1
[gentoo-dev] [PATCH 3/4] eclass/ruby-ng.eclass: remove EAPI 4 support
Signed-off-by: Hans de Graaff
---
eclass/ruby-ng.eclass | 22 +++---
1 file changed, 11 insertions(+), 11 deletions(-)
diff --git a/eclass/ruby-ng.eclass b/eclass/ruby-ng.eclass
index d8afa207661f..ac9c117c0c02 100644
--- a/eclass/ruby-ng.eclass
+++ b/eclass/ruby-ng.eclass
@@ -8,7 +8,7 @@
# Author: Diego E. Pettenò
# Author: Alex Legler
# Author: Hans de Graaff
-# @SUPPORTED_EAPIS: 4 5 6 7 8
+# @SUPPORTED_EAPIS: 5 6 7 8
# @BLURB: An eclass for installing Ruby packages with proper support for
multiple Ruby slots.
# @DESCRIPTION:
# The Ruby eclass is designed to allow an easier installation of Ruby packages
@@ -68,7 +68,7 @@
local inherits=""
case ${EAPI} in
- 4|5)
+ 5)
inherits="eutils toolchain-funcs"
;;
6)
@@ -87,7 +87,7 @@ EXPORT_FUNCTIONS src_unpack src_prepare src_configure
src_compile src_test src_i
S="${WORKDIR}"
case ${EAPI} in
- 4|5|6|7|8) ;;
+ 5|6|7|8) ;;
*) die "${ECLASS}: EAPI ${EAPI:-0} not supported" ;;
esac
@@ -207,7 +207,7 @@ ruby_add_rdepend() {
1) ;;
2)
case ${EAPI} in
- 4|5|6)
+ 5|6)
[[ "${GENTOO_DEV}" == "yes" ]] &&
eqawarn "You can now use the usual syntax in ruby_add_rdepend for $CATEGORY/$PF"
ruby_add_rdepend
"$(_ruby_wrap_conditions "$1" "$2")"
return
@@ -229,7 +229,7 @@ ruby_add_rdepend() {
# Add the dependency as a test-dependency since we're going to
# execute the code during test phase.
case ${EAPI} in
- 4|5|6) DEPEND="${DEPEND} test? ( ${dependency} )" ;;
+ 5|6) DEPEND="${DEPEND} test? ( ${dependency} )" ;;
*) BDEPEND="${BDEPEND} test? ( ${dependency} )" ;;
esac
if ! has test "$IUSE"; then
@@ -252,7 +252,7 @@ ruby_add_bdepend() {
1) ;;
2)
case ${EAPI} in
- 4|5|6)
+ 5|6)
[[ "${GENTOO_DEV}" == "yes" ]] &&
eqawarn "You can now use the usual syntax in ruby_add_bdepend for $CATEGORY/$PF"
ruby_add_bdepend
"$(_ruby_wrap_conditions "$1" "$2")"
return
@@ -270,7 +270,7 @@ ruby_add_bdepend() {
local dependency=$(_ruby_atoms_samelib "$1")
case ${EAPI} in
- 4|5|6) DEPEND="${DEPEND} $dependency" ;;
+ 5|6) DEPEND="${DEPEND} $dependency" ;;
*) BDEPEND="${BDEPEND} $dependency" ;;
esac
RDEPEND="${RDEPEND}"
@@ -283,7 +283,7 @@ ruby_add_bdepend() {
# ruby_add_bdepend.
ruby_add_depend() {
case ${EAPI} in
- 4|5|6) die "only available in EAPI 7 and newer" ;;
+ 5|6) die "only available in EAPI 7 and newer" ;;
*) ;;
esac
@@ -351,7 +351,7 @@ if [[ ${RUBY_OPTIONAL} != yes ]]; then
RDEPEND="${RDEPEND} $(ruby_implementations_depend)"
REQUIRED_USE+=" || ( $(ruby_get_use_targets) )"
case ${EAPI} in
- 4|5|6) ;;
+ 5|6) ;;
*) BDEPEND="${BDEPEND} $(ruby_implementations_depend)" ;;
esac
fi
@@ -455,7 +455,7 @@ ruby-ng_src_unpack() {
_ruby_apply_patches() {
case ${EAPI} in
- 4|5)
+ 5)
for patch in "${RUBY_PATCHES[@]}"; do
if [ -f "${patch}" ]; then
epatch "${patch}"
@@ -503,7 +503,7 @@ ruby-ng_src_prepare() {
# Handle PATCHES and user supplied patches via the default phase
case ${EAPI} in
- 4|5)
+ 5)
;;
*)
_ruby_invoke_environment all default
--
2.31.1
[gentoo-dev] [PATCH 2/4] eclass/ruby-fakegem.eclass: add EAPI 8 support
Signed-off-by: Hans de Graaff
---
eclass/ruby-fakegem.eclass | 14 --
1 file changed, 4 insertions(+), 10 deletions(-)
diff --git a/eclass/ruby-fakegem.eclass b/eclass/ruby-fakegem.eclass
index 9b2fd39ccf14..34eeff2fad96 100644
--- a/eclass/ruby-fakegem.eclass
+++ b/eclass/ruby-fakegem.eclass
@@ -8,7 +8,7 @@
# Author: Diego E. Pettenò
# Author: Alex Legler
# Author: Hans de Graaff
-# @SUPPORTED_EAPIS: 4 5 6 7
+# @SUPPORTED_EAPIS: 4 5 6 7 8
# @BLURB: An eclass for installing Ruby packages to behave like RubyGems.
# @DESCRIPTION:
# This eclass allows to install arbitrary Ruby libraries (including Gems),
@@ -129,17 +129,11 @@ RUBY_FAKEGEM_BINDIR="${RUBY_FAKEGEM_BINDIR-bin}"
# legacy way to install extensions for a long time.
RUBY_FAKEGEM_EXTENSION_LIBDIR="${RUBY_FAKEGEM_EXTENSION_LIBDIR-lib}"
-case "${EAPI:-0}" in
- 0|1|2|3)
- die "Unsupported EAPI=${EAPI} (too old) for
ruby-fakegem.eclass" ;;
- 4|5|6|7)
- ;;
- *)
- die "Unsupported EAPI=${EAPI} (unknown) for ${ECLASS}"
- ;;
+case ${EAPI} in
+ 4|5|6|7|8) ;;
+ *) die "${ECLASS}: EAPI ${EAPI:-0} not supported" ;;
esac
-
RUBY_FAKEGEM_SUFFIX="${RUBY_FAKEGEM_SUFFIX:-}"
--
2.31.1
[gentoo-dev] [PATCH 1/4] eclass/ruby-ng.eclass: add EAPI 8 support
Signed-off-by: Hans de Graaff
---
eclass/ruby-ng.eclass | 15 ++-
1 file changed, 6 insertions(+), 9 deletions(-)
diff --git a/eclass/ruby-ng.eclass b/eclass/ruby-ng.eclass
index 0c569bfcdcc6..d8afa207661f 100644
--- a/eclass/ruby-ng.eclass
+++ b/eclass/ruby-ng.eclass
@@ -8,7 +8,7 @@
# Author: Diego E. Pettenò
# Author: Alex Legler
# Author: Hans de Graaff
-# @SUPPORTED_EAPIS: 4 5 6 7
+# @SUPPORTED_EAPIS: 4 5 6 7 8
# @BLURB: An eclass for installing Ruby packages with proper support for
multiple Ruby slots.
# @DESCRIPTION:
# The Ruby eclass is designed to allow an easier installation of Ruby packages
@@ -83,15 +83,12 @@ inherit ${inherits} multilib ruby-utils
EXPORT_FUNCTIONS src_unpack src_prepare src_configure src_compile src_test
src_install pkg_setup
+# S is no longer automatically assigned when it doesn't exist.
+S="${WORKDIR}"
+
case ${EAPI} in
- 0|1|2|3)
- die "Unsupported EAPI=${EAPI} (too old) for ruby-ng.eclass" ;;
- 4|5|6|7)
- # S is no longer automatically assigned when it doesn't exist.
- S="${WORKDIR}"
- ;;
- *)
- die "Unknown EAPI=${EAPI} for ruby-ng.eclass"
+ 4|5|6|7|8) ;;
+ *) die "${ECLASS}: EAPI ${EAPI:-0} not supported" ;;
esac
# @FUNCTION: ruby_implementation_depend
--
2.31.1
[gentoo-dev] [PATCH 0/4] EAPI 8 support for ruby eclasses
Add support for EAPI 8 and remove support for EAPI 4. No real changes needed, but standardized the EAPI check to match the proposed default. Hans de Graaff (4): eclass/ruby-ng.eclass: add EAPI 8 support eclass/ruby-fakegem.eclass: add EAPI 8 support eclass/ruby-ng.eclass: remove EAPI 4 support eclass/ruby-fakegem.eclass: remove EAPI 4 support eclass/ruby-fakegem.eclass | 20 +++- eclass/ruby-ng.eclass | 33 +++-- 2 files changed, 22 insertions(+), 31 deletions(-) -- 2.31.1
Re: [gentoo-dev] [PATCH] cuda.eclass: EAPI support: add 8, drop 5 and 6
> On Thu, 15 Jul 2021, Marek Szuba wrote:
> case "${EAPI:-0}" in
> - 0|1|2|3|4)
> + [0-6])
> die "Unsupported EAPI=${EAPI:-0} (too old) for ${ECLASS}"
> ;;
> - 5|6|7)
> + 7|8)
> ;;
> *)
> die "Unsupported EAPI=${EAPI} (unknown) for ${ECLASS}"
In the latest bunch of updates, we have changed many eclasses to have
only a single error case, and also standardized the die message.
Maybe simplify this eclass as well?
case ${EAPI} in
7|8) ;;
*) die "${ECLASS}: EAPI ${EAPI:-0} not supported" ;;
esac
signature.asc
Description: PGP signature
[gentoo-dev] [PATCH] cuda.eclass: EAPI support: add 8, drop 5 and 6
Signed-off-by: Marek Szuba
---
eclass/cuda.eclass | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/eclass/cuda.eclass b/eclass/cuda.eclass
index b1da77c69dd..08d2302d55b 100644
--- a/eclass/cuda.eclass
+++ b/eclass/cuda.eclass
@@ -1,11 +1,11 @@
-# Copyright 1999-2020 Gentoo Authors
+# Copyright 1999-2021 Gentoo Authors
# Distributed under the terms of the GNU General Public License v2
case "${EAPI:-0}" in
- 0|1|2|3|4)
+ [0-6])
die "Unsupported EAPI=${EAPI:-0} (too old) for ${ECLASS}"
;;
- 5|6|7)
+ 7|8)
;;
*)
die "Unsupported EAPI=${EAPI} (unknown) for ${ECLASS}"
@@ -15,7 +15,7 @@ esac
# @ECLASS: cuda.eclass
# @MAINTAINER:
# Gentoo Science Project
-# @SUPPORTED_EAPIS: 5 6 7
+# @SUPPORTED_EAPIS: 7 8
# @BLURB: Common functions for cuda packages
# @DESCRIPTION:
# This eclass contains functions to be used with cuda package. Currently it is
--
2.31.1
[gentoo-dev] cuda.eclass EAPI-support shuffle
Like fortran-2 adding support for EAPI 8 appears to be trivial, unlike fortran-2 we have no longer got any deprecated-EAPI ebuilds in the tree inheriting it.
[gentoo-dev] Last rites: net-proxy/polipo
# John Helmert III (2021-07-14) # Dead upstream, unfixed security issue. # Removal on 2021-08-13. Bugs #755896, #781467. net-proxy/polipo signature.asc Description: PGP signature
Re: [gentoo-dev] [PATCH] 2021-07-09-systemd-tmpfiles: re-add news item
On Wed, Jul 14, 2021 at 10:49:34AM +0200, Andreas K. Huettel wrote: > > > > > > 1) either the severity assignment of this bug by the Security project as > > > B1 wrong (i.e. it should have been classified "harmless") > Well, over the last year or so every 2-3 months the (uninformed) discussion > came up, "don't use openrc stages because you are automatically rooted". That > leaves a rather bad impression of Gentoo, independent of whether it is true > or not. If noone from sec team noticed the discussions... Absolutely, that would leave a bad impression. Where were these discussions taking place? > > > > 2) or the entire classification of severity levels according to the > > > Security project pointless (i.e. you can't base any actions on them > > > because a mystery onion needs to be taken into account). > > > > > > > I am not sure if this is sarcasm, but every bug must be considered > > through the correct aperture. That is, based on your environment, > > protections in place, defense in depth, and other buzzwords... hence the > > onion analogy. > > It's not sarcasm. The point of the classification is to give clear rules (why > else would you list, e.g., required response times on the vulnerability > treatment page (no matter how illusory they are)). > > If you don't take all factors into account when *making* the classification, > then all gain you have from the classification is lost. > Let me explain differently. Gentoo has a vulnerability rating system that is indepedent of any other system. This system is used to classify bugs from a distro perspective and common usage of various applications. However, one cannot consider all possible attack vectors, impacts, and configuration scenarios being used by our users. So, it is not lost... we just can't possibly account for all the things. Yes, the response times are utter crap and as I mentioned the Gentoo system needs to be overhauled/adapted. -Aaron signature.asc Description: PGP signature
Re: [gentoo-dev] fortran-2.eclass EAPI-8 support
On 2021-07-14 13:02, Ulrich Mueller wrote: Shouldn't virtual/fortran go into BDEPEND in EAPIs 7 and 8? Good point! I've created https://bugs.gentoo.org/802153 so that we do not lose track of this, that said it is beyond the scope of the issue at hand (the eclass will not behave any differently here under EAPI 8 than it does under EAPI 7) so I'll leave my current patch as it is. -- Marecki OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] fortran-2.eclass EAPI-8 support
> On Wed, 14 Jul 2021, Marek Szuba wrote: > On the plus side, nothing in here that requires changing to work with > the new EAPI. On the minus side, we still got many EAPI-5 and 6 > consumers of this eclass in the tree so no chance of dropping support > for these two at this time. Shouldn't virtual/fortran go into BDEPEND in EAPIs 7 and 8? signature.asc Description: PGP signature
Re: [gentoo-dev] [PATCH] News item v2: media-sound/pulseeffects "renaming"
On 2021-07-13 18:54, Michał Górny wrote: +media-sound/easyeffects is already available in the tree, and the +remaining PipeWire-dependent ebuilds of media-sound/pulseeffects will s/ebuilds/versions/. Changed locally. +be removed in 7 days. Probably better to use an explicit date here. '7 days' sounds relative to 'now'. It was supposed to mean "7 days from the date of this news item having been published" - but you're right, an explicit date will be easier to parse. Changed locally to "on 2021-07-23". PS. Having thought about it some more, now that we do have instructions for users not wishing to switch to PipeWire in the news item I have locally removed the media-sound/pulseeffects version limit from Display-If-Installed. That way people who haven't thought about switching from plain PA to PW yet, or perhaps do not even know yet that PW can be used as a drop-in replacement for PA (I for one did not until just a few weeks ago; the fact the former resides in media-video doesn't help) will not be caught by surprise if/when they do decide to switch. -- Marecki OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH] lua*.eclass: standardize the guard variables
On 2021-07-13 18:35, William Hubbs wrote: >> are there any non-cosmetic reasons for doing this? Consistency with the rest of the tree. If you do a "git grep _R0" on the eclass directory, the lua eclasses are the only ones that have this in the names of the guard variables, and the eclasses themselves aren't named lua-r0.eclass etc. What will break if I do this? Nothing should, given that eclass guard variables should have no interactions with anything other than respective eclasses themselves. Of course that means this change *is* purely cosmetic... especially considering that while _FOO_ECLASS is currently the most common format in the tree it is by no means the only one, and that revision 0 is technically speaking a real thing that we just happen to treat as default and omit from names for brevity. I've got no preference either way as long as guard variables can easily be searched for in eclass code, so if you haven't got anything more important to work on in Gentoo go ahead. -- Marecki OpenPGP_signature Description: OpenPGP digital signature
[gentoo-dev] [PATCH] fortran-2.eclass: support EAPI 8
Signed-off-by: Marek Szuba
---
eclass/fortran-2.eclass | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/eclass/fortran-2.eclass b/eclass/fortran-2.eclass
index 0bb00f475a2..9d0c71703e4 100644
--- a/eclass/fortran-2.eclass
+++ b/eclass/fortran-2.eclass
@@ -7,7 +7,7 @@
# @AUTHOR:
# Author Justin Lecher
# Test functions provided by Sebastien Fabbro and Kacper Kowalik
-# @SUPPORTED_EAPIS: 5 6 7
+# @SUPPORTED_EAPIS: 5 6 7 8
# @BLURB: Simplify fortran compiler management
# @DESCRIPTION:
# If you need a fortran compiler, then you should be inheriting this eclass.
@@ -31,7 +31,7 @@ inherit toolchain-funcs
case ${EAPI:-0} in
# not used in the eclass, but left for backward compatibility with
legacy users
5|6) inherit eutils ;;
- 7) ;;
+ 7|8) ;;
*) die "EAPI=${EAPI} is not supported" ;;
esac
--
2.31.1
[gentoo-dev] fortran-2.eclass EAPI-8 support
On the plus side, nothing in here that requires changing to work with the new EAPI. On the minus side, we still got many EAPI-5 and 6 consumers of this eclass in the tree so no chance of dropping support for these two at this time.
Re: [gentoo-dev] [PATCH] 2021-07-09-systemd-tmpfiles: re-add news item
> > > > 1) either the severity assignment of this bug by the Security project as B1 > > wrong (i.e. it should have been classified "harmless") > > > > The Gentoo model is not perfect and should be overhauled. However, it > works for most things and sometimes bugs fall between the cracks. > > The package shouldn't have been masked either based on a bug that was > purposely ignored for many years simply because they want to disband the > package now and found a "security reason" to add to the mask. Well, over the last year or so every 2-3 months the (uninformed) discussion came up, "don't use openrc stages because you are automatically rooted". That leaves a rather bad impression of Gentoo, independent of whether it is true or not. If noone from sec team noticed the discussions... > > 2) or the entire classification of severity levels according to the > > Security project pointless (i.e. you can't base any actions on them because > > a mystery onion needs to be taken into account). > > > > I am not sure if this is sarcasm, but every bug must be considered > through the correct aperture. That is, based on your environment, > protections in place, defense in depth, and other buzzwords... hence the > onion analogy. It's not sarcasm. The point of the classification is to give clear rules (why else would you list, e.g., required response times on the vulnerability treatment page (no matter how illusory they are)). If you don't take all factors into account when *making* the classification, then all gain you have from the classification is lost. -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, toolchain, base-system, perl, libreoffice) signature.asc Description: This is a digitally signed message part.
