Re: [gentoo-dev] Switching default password hashes from sha512 to yescrypt
On Fri, Jul 22, 2022 at 3:10 PM Mikhail Koliada wrote: > > Hello! > > > > This idea has been fluctuating in my head for quite a while given that the > migration had happened > > a while ago [0] and some other major distributions have already adopted > yescrypt as their default algo > > by now [1]. For us switching is as easy as changing the default use flag in > pambase and rehashing the password > > with the ‘passwd’ call (a news item will be required). > > > > What do you think? Seems like a reasonable idea to me.
Re: [gentoo-dev] Last rites: large amount of unmaintained dev-haskell/* package
On 2022-07-23 23:23:38, Sam James wrote: > > The two people you refer to (solpeth and hololeap) both warmly > welcomed this move and endorse it. It'd be great to have them as developers > and I've offered to help mentor them, as have others. Ok, awesome. Thank you both.
Re: [gentoo-dev] Last rites: large amount of unmaintained dev-haskell/* package
> On 23 Jul 2022, at 13:34, Michael Orlitzky wrote: > > On Sat, 2022-07-23 at 02:49 +0100, Sam James wrote: >> # Sam James (2022-07-22) >> # Monolithic mask for dev-haskell/* packages which have no reverse >> dependencies, >> # are broken, or severely out of date. The aim is to have the Haskell overlay >> # (::haskell) be the place for development packages and only have packages >> # needed for end-user applications in ::gentoo, as the status who has >> # proven to be unsustainable. More up-to-date versions of these packages >> # are available in ::haskell. >> # Removal on 2022-08-22. >> ... >> dev-haskell/hakyll >> ... >> sci-mathematics/agda >> > > Those two are (relatively) popular end-user applications. > > I'm sure this came up already, but just in case it didn't: we largely > have two non-developers maintaining the ::haskell overlay, and they've > been doing so since slyfox's retirement. Since there's an ongoing > thread about recruitment... has anyone thought about letting them do > their work in ::gentoo instead? > > The two people you refer to (solpeth and hololeap) both warmly welcomed this move and endorse it. It'd be great to have them as developers and I've offered to help mentor them, as have others. This is a similar style cleanup to what we did with OCaml / dev-ml/*. If people want to keep some packages, we can talk about that, sure - but help would be needed to look after their dependencies. signature.asc Description: Message signed with OpenPGP
[gentoo-dev] [PATCH 8/8] java-pkg-simple.eclass: Inherit eqawarn instead of eutils
Signed-off-by: Ulrich Müller --- eclass/java-pkg-simple.eclass | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/eclass/java-pkg-simple.eclass b/eclass/java-pkg-simple.eclass index 34c044e2ba2d..09062d9ede68 100644 --- a/eclass/java-pkg-simple.eclass +++ b/eclass/java-pkg-simple.eclass @@ -17,7 +17,7 @@ # directory before calling the src_compile function of this eclass. case ${EAPI} in - 6) inherit eutils ;; # eutils for eqawarn + 6) inherit eqawarn ;; 7|8) ;; *) die "${ECLASS}: EAPI ${EAPI:-0} not supported" ;; esac -- 2.35.1
[gentoo-dev] [PATCH 7/8] java-pkg-simple.eclass: Drop support for EAPI 5
Signed-off-by: Ulrich Müller --- eclass/java-pkg-simple.eclass | 10 +++--- 1 file changed, 3 insertions(+), 7 deletions(-) diff --git a/eclass/java-pkg-simple.eclass b/eclass/java-pkg-simple.eclass index c0a6b4d21df9..34c044e2ba2d 100644 --- a/eclass/java-pkg-simple.eclass +++ b/eclass/java-pkg-simple.eclass @@ -6,7 +6,7 @@ # j...@gentoo.org # @AUTHOR: # Java maintainers -# @SUPPORTED_EAPIS: 5 6 7 8 +# @SUPPORTED_EAPIS: 6 7 8 # @BLURB: Eclass for packaging Java software with ease. # @DESCRIPTION: # This class is intended to build pure Java packages from Java sources @@ -16,8 +16,8 @@ # addressed by an ebuild by putting corresponding files into the target # directory before calling the src_compile function of this eclass. -case ${EAPI:-0} in - 5|6) inherit eutils ;; # eutils for eqawarn +case ${EAPI} in + 6) inherit eutils ;; # eutils for eqawarn 7|8) ;; *) die "${ECLASS}: EAPI ${EAPI:-0} not supported" ;; esac @@ -468,10 +468,6 @@ java-pkg-simple_src_install() { java-pkg_dosrc ${srcdirs} fi - if [[ ${EAPI} == 5 ]]; then - # einstalldocs is only available on EAPI >= 6. - return - fi einstalldocs } -- 2.35.1
[gentoo-dev] [PATCH 6/8] vcs-snapshot.eclass: Add missing inherit for eqawarn
Signed-off-by: Ulrich Müller --- eclass/vcs-snapshot.eclass | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/eclass/vcs-snapshot.eclass b/eclass/vcs-snapshot.eclass index 64bc1da040f4..1b7299b92a3b 100644 --- a/eclass/vcs-snapshot.eclass +++ b/eclass/vcs-snapshot.eclass @@ -43,7 +43,8 @@ # in ${WORKDIR}/${P} and ${WORKDIR}/${P}-otherstuff respectively. case ${EAPI} in - 6|7|8) ;; + 6) inherit eqawarn ;; + 7|8) ;; *) die "${ECLASS}: EAPI ${EAPI:-0} not supported" ;; esac -- 2.35.1
[gentoo-dev] [PATCH 5/8] ruby-ng.eclass: Add missing inherit for eqawarn
Signed-off-by: Ulrich Müller --- eclass/ruby-ng.eclass | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/eclass/ruby-ng.eclass b/eclass/ruby-ng.eclass index 167aab755f3a..06548392a501 100644 --- a/eclass/ruby-ng.eclass +++ b/eclass/ruby-ng.eclass @@ -68,7 +68,7 @@ case ${EAPI} in 6) - inherit estack toolchain-funcs + inherit eqawarn estack toolchain-funcs ;; *) inherit estack -- 2.35.1
[gentoo-dev] [PATCH 4/8] ruby-ng.eclass: Drop support for EAPI 5
Signed-off-by: Ulrich Müller --- eclass/ruby-ng.eclass | 38 +- 1 file changed, 9 insertions(+), 29 deletions(-) diff --git a/eclass/ruby-ng.eclass b/eclass/ruby-ng.eclass index c43d5b4d9826..167aab755f3a 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: 5 6 7 8 +# @SUPPORTED_EAPIS: 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 @@ -67,9 +67,6 @@ # passed to "grep -E" to remove reporting of these shared objects. case ${EAPI} in - 5) - inherit eutils toolchain-funcs - ;; 6) inherit estack toolchain-funcs ;; @@ -86,7 +83,7 @@ EXPORT_FUNCTIONS src_unpack src_prepare src_configure src_compile src_test src_i S="${WORKDIR}" case ${EAPI} in - 5|6|7|8) ;; + 6|7|8) ;; *) die "${ECLASS}: EAPI ${EAPI:-0} not supported" ;; esac @@ -214,7 +211,7 @@ ruby_add_rdepend() { 1) ;; 2) case ${EAPI} in - 5|6) + 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 @@ -236,7 +233,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 - 5|6) DEPEND="${DEPEND} test? ( ${dependency} )" ;; + 6) DEPEND="${DEPEND} test? ( ${dependency} )" ;; *) BDEPEND="${BDEPEND} test? ( ${dependency} )" ;; esac if ! has test "$IUSE"; then @@ -261,7 +258,7 @@ ruby_add_bdepend() { 1) ;; 2) case ${EAPI} in - 5|6) + 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 @@ -279,7 +276,7 @@ ruby_add_bdepend() { local dependency=$(_ruby_atoms_samelib "$1") case ${EAPI} in - 5|6) DEPEND="${DEPEND} $dependency" ;; + 6) DEPEND="${DEPEND} $dependency" ;; *) BDEPEND="${BDEPEND} $dependency" ;; esac RDEPEND="${RDEPEND}" @@ -294,7 +291,7 @@ ruby_add_depend() { debug-print-function ${FUNCNAME} "${@}" case ${EAPI} in - 5|6) die "only available in EAPI 7 and newer" ;; + 6) die "only available in EAPI 7 and newer" ;; *) ;; esac @@ -368,7 +365,7 @@ if [[ ${RUBY_OPTIONAL} != yes ]]; then RDEPEND="${RDEPEND} $(ruby_implementations_depend)" REQUIRED_USE+=" || ( $(ruby_get_use_targets) )" case ${EAPI} in - 5|6) ;; + 6) ;; *) BDEPEND="${BDEPEND} $(ruby_implementations_depend)" ;; esac fi @@ -476,17 +473,6 @@ ruby-ng_src_unpack() { _ruby_apply_patches() { case ${EAPI} in - 5) - for patch in "${RUBY_PATCHES[@]}"; do - if [ -f "${patch}" ]; then - epatch "${patch}" - elif [ -f "${FILESDIR}/${patch}" ]; then - epatch "${FILESDIR}/${patch}" - else - die "Cannot find patch ${patch}" - fi - done - ;; 6) if [[ -n ${RUBY_PATCHES[@]} ]]; then eqawarn "RUBY_PATCHES is no longer supported, use PATCHES instead" @@ -525,13 +511,7 @@ ruby-ng_src_prepare() { find . -name '._*' -delete # Handle PATCHES and user supplied patches via the default phase - case ${EAPI} in - 5) - ;; - *) - _ruby_invoke_environment all default - ;; - esac + _ruby_invoke_environment all default _ruby_invoke_environment all _ruby_apply_patches -- 2.35.1
[gentoo-dev] [PATCH 3/8] python*-r1.eclass: Add missing inherit for eqawarn
Signed-off-by: Ulrich Müller --- eclass/python-r1.eclass | 1 + eclass/python-utils-r1.eclass | 1 + 2 files changed, 2 insertions(+) diff --git a/eclass/python-r1.eclass b/eclass/python-r1.eclass index 3471e17bdde6..2fd5c70120e9 100644 --- a/eclass/python-r1.eclass +++ b/eclass/python-r1.eclass @@ -49,6 +49,7 @@ elif [[ ${_PYTHON_ANY_R1} ]]; then die 'python-r1.eclass can not be used with python-any-r1.eclass.' fi +[[ ${EAPI} == 6 ]] && inherit eqawarn inherit multibuild python-utils-r1 fi diff --git a/eclass/python-utils-r1.eclass b/eclass/python-utils-r1.eclass index e54f943f94f6..b793a1f13e0f 100644 --- a/eclass/python-utils-r1.eclass +++ b/eclass/python-utils-r1.eclass @@ -35,6 +35,7 @@ fi if [[ ! ${_PYTHON_UTILS_R1} ]]; then [[ ${EAPI} == [67] ]] && inherit eapi8-dosym +[[ ${EAPI} == 6 ]] && inherit eqawarn inherit multiprocessing toolchain-funcs # @ECLASS_VARIABLE: _PYTHON_ALL_IMPLS -- 2.35.1
[gentoo-dev] [PATCH 2/8] eutils.eclass: Add @DEPRECATED tag
Signed-off-by: Ulrich Müller --- eclass/eutils.eclass | 13 + 1 file changed, 1 insertion(+), 12 deletions(-) diff --git a/eclass/eutils.eclass b/eclass/eutils.eclass index b1479d33049c..dedb5b1696c1 100644 --- a/eclass/eutils.eclass +++ b/eclass/eutils.eclass @@ -6,18 +6,7 @@ # base-sys...@gentoo.org # @SUPPORTED_EAPIS: 6 7 # @BLURB: many extra (but common) functions that are used in ebuilds -# @DESCRIPTION: -# The eutils eclass contains a suite of functions that complement -# the ones that ebuild.sh already contain. The idea is that the functions -# are not required in all ebuilds but enough utilize them to have a common -# home rather than having multiple ebuilds implementing the same thing. -# -# Due to the nature of this eclass, some functions may have maintainers -# different from the overall eclass! -# -# This eclass is DEPRECATED and must not be inherited by any new ebuilds -# or eclasses. Use the more specific split eclasses instead, or native -# package manager functions when available. +# @DEPRECATED native package manager functions, more specific eclasses if [[ -z ${_EUTILS_ECLASS} ]]; then _EUTILS_ECLASS=1 -- 2.35.1
[gentoo-dev] [PATCH 1/8] eqawarn.eclass: New eclass, split off from eutils
Signed-off-by: Ulrich Müller --- eclass/eqawarn.eclass | 26 ++ eclass/eutils.eclass | 15 +-- 2 files changed, 27 insertions(+), 14 deletions(-) create mode 100644 eclass/eqawarn.eclass diff --git a/eclass/eqawarn.eclass b/eclass/eqawarn.eclass new file mode 100644 index ..288976182fb3 --- /dev/null +++ b/eclass/eqawarn.eclass @@ -0,0 +1,26 @@ +# Copyright 1999-2022 Gentoo Authors +# Distributed under the terms of the GNU General Public License v2 + +# @ECLASS: eqawarn.eclass +# @MAINTAINER: +# base-sys...@gentoo.org +# @SUPPORTED_EAPIS: 6 +# @BLURB: output a QA warning + +case ${EAPI} in + 6) ;; + *) die "${ECLASS}: EAPI ${EAPI:-0} not supported" ;; +esac + +# @FUNCTION: eqawarn +# @USAGE: [message] +# @DESCRIPTION: +# Proxy to ewarn for package managers that don't provide eqawarn and +# use the PM implementation if available. Reuses PORTAGE_ELOG_CLASSES +# as set by the dev profile. +if ! declare -F eqawarn >/dev/null ; then + eqawarn() { + has qa ${PORTAGE_ELOG_CLASSES} && ewarn "$@" + : + } +fi diff --git a/eclass/eutils.eclass b/eclass/eutils.eclass index e7fae2c656c6..b1479d33049c 100644 --- a/eclass/eutils.eclass +++ b/eclass/eutils.eclass @@ -24,7 +24,7 @@ _EUTILS_ECLASS=1 # implicitly inherited (now split) eclasses case ${EAPI} in - 6) inherit desktop edos2unix epatch estack ltprune multilib \ + 6) inherit desktop edos2unix epatch eqawarn estack ltprune multilib \ preserve-libs strip-linguas toolchain-funcs vcs-clean wrapper ;; 7) inherit edos2unix strip-linguas wrapper ;; *) die "${ECLASS}: EAPI ${EAPI:-0} not supported" ;; @@ -50,17 +50,4 @@ use_if_iuse() { die "use_if_iuse is banned" } -# @FUNCTION: eqawarn -# @USAGE: [message] -# @DESCRIPTION: -# Proxy to ewarn for package managers that don't provide eqawarn and use the PM -# implementation if available. Reuses PORTAGE_ELOG_CLASSES as set by the dev -# profile. -if [[ ${EAPI} == 6 ]] && ! declare -F eqawarn >/dev/null ; then - eqawarn() { - has qa ${PORTAGE_ELOG_CLASSES} && ewarn "$@" - : - } -fi - fi -- 2.35.1
[gentoo-dev] [PATCH 0/8] Deprecate eutils.eclass
This series of patches splits off eqawarn in its own eclass, which will finally allow us to tag eutils.eclass as deprecated. Also, some eclasses call eqawarn in EAPI 6 without inheriting the function. Add a proper inherit statement to them, and drop EAPI 5 support while at it. Ulrich Müller (8): eqawarn.eclass: New eclass, split off from eutils eutils.eclass: Add @DEPRECATED tag python*-r1.eclass: Add missing inherit for eqawarn ruby-ng.eclass: Drop support for EAPI 5 ruby-ng.eclass: Add missing inherit for eqawarn vcs-snapshot.eclass: Add missing inherit for eqawarn java-pkg-simple.eclass: Drop support for EAPI 5 java-pkg-simple.eclass: Inherit eqawarn instead of eutils eclass/eqawarn.eclass | 26 +++ eclass/eutils.eclass | 28 ++-- eclass/java-pkg-simple.eclass | 10 +++-- eclass/python-r1.eclass | 1 + eclass/python-utils-r1.eclass | 1 + eclass/ruby-ng.eclass | 40 +-- eclass/vcs-snapshot.eclass| 3 ++- 7 files changed, 45 insertions(+), 64 deletions(-) create mode 100644 eclass/eqawarn.eclass -- 2.35.1
Re: [gentoo-dev] Last rites: large amount of unmaintained dev-haskell/* package
On Sat, Jul 23, 2022 at 08:34:26AM -0400, Michael Orlitzky wrote: > On Sat, 2022-07-23 at 02:49 +0100, Sam James wrote: > > # Sam James (2022-07-22) > > # Monolithic mask for dev-haskell/* packages which have no reverse > > dependencies, > > # are broken, or severely out of date. The aim is to have the Haskell > > overlay > > # (::haskell) be the place for development packages and only have packages > > # needed for end-user applications in ::gentoo, as the status who has > > # proven to be unsustainable. More up-to-date versions of these packages > > # are available in ::haskell. > > # Removal on 2022-08-22. > > ... > > dev-haskell/hakyll > > ... > > sci-mathematics/agda > > > > Those two are (relatively) popular end-user applications. > > I'm sure this came up already, but just in case it didn't: we largely > have two non-developers maintaining the ::haskell overlay, and they've > been doing so since slyfox's retirement. Since there's an ongoing > thread about recruitment... has anyone thought about letting them do > their work in ::gentoo instead? Yes, I (and others) have encouraged them to do the quiz and offered mentoring them. signature.asc Description: PGP signature
Re: [gentoo-dev] [PATCH] metadata.dtd: add sourcehut remote-id
On Sat, Jul 23, 2022 at 01:55:50PM +0500, A wrote: > On 2022-07-23 01:11, Sam James wrote: > > Signed-off-by: Sam James > > Bug: https://bugs.gentoo.org/808779 > > > --- > > metadata.dtd | 2 +- > > XSD needs to be updated too (and wiki, and soko, and pkgcheck...) sam added the list of what needs to be done himself on the wiki[1] :) And currently only the first step is listed for ML review. [1] https://wiki.gentoo.org/wiki/Project:Quality_Assurance/Upstream_remote-id_types > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/metadata.dtd b/metadata.dtd > > index 581943e..1297548 100644 > > --- a/metadata.dtd > > +++ b/metadata.dtd > > @@ -58,7 +58,7 @@ > > > > > > > > - > (bitbucket|cpan|cpan-module|cpe|cran|ctan|gentoo|github|gitlab|google-code|heptapod|launchpad|osdn|pear|pecl|pypi|rubygems|sourceforge|vim) > > #REQUIRED> > > + > (bitbucket|cpan|cpan-module|cpe|cran|ctan|gentoo|github|gitlab|google-code|heptapod|launchpad|osdn|pear|pecl|pypi|rubygems|sourceforge|sourcehut|vim) > > #REQUIRED> > > I'd use "srht" as it's the name of main instance. Everyone can run their > own instance of sourcehut. Same goes for gitlab, and I doubt someone else who would host their own sourcehut would call themselves "sourcehut", it'd be e.g. freedesktop's gitlab with likely a "freedesktop" remote-id. I'm fine with either, but the more readable+recognizable choice sounds fair to me. > > > > > -- > > 2.37.1 > > > > > -- ionen signature.asc Description: PGP signature
Re: [gentoo-dev] Last rites: large amount of unmaintained dev-haskell/* package
On Sat, 2022-07-23 at 02:49 +0100, Sam James wrote: > # Sam James (2022-07-22) > # Monolithic mask for dev-haskell/* packages which have no reverse > dependencies, > # are broken, or severely out of date. The aim is to have the Haskell overlay > # (::haskell) be the place for development packages and only have packages > # needed for end-user applications in ::gentoo, as the status who has > # proven to be unsustainable. More up-to-date versions of these packages > # are available in ::haskell. > # Removal on 2022-08-22. > ... > dev-haskell/hakyll > ... > sci-mathematics/agda > Those two are (relatively) popular end-user applications. I'm sure this came up already, but just in case it didn't: we largely have two non-developers maintaining the ::haskell overlay, and they've been doing so since slyfox's retirement. Since there's an ongoing thread about recruitment... has anyone thought about letting them do their work in ::gentoo instead?
[gentoo-dev] Re: [gentoo-project] RFC: "Trusted contributor model"
> Once again new council has been elected: congratulations to the chosen > members! And once again many nominees expressed their wishes to see more > non-developer contributors to become official developers. Yet, only very > few people (if any) are interested in mentoring them. I get it, the > relationship between a mentor and their mentee is very intimate, and > mentoring takes a lot of time. While the Github PRs are helping us > increase the user contributions merged, perhaps it's distancing us from > creating stronger bonds with the contributors? But more about this topic > later. Actually, we are doing quite well in terms of recruiting at the moment. I would love to see this continue. And yes, mentors are important for that. -- 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.
[gentoo-dev] Re: [gentoo-project] RFC: "Trusted contributor model"
> > 2nd RFC: Recruiting proven contributors without a mentor > > I'm aware recruiters don't really need to ask a permission here, but I > believe it's great to gauge the general feelings about this beforehand. > What would you say if recruiters started more actively approaching > potential developers? And currently I'm talking about people who have > been active for a very long time (+year or two), who keep up with > development-wise changes in Gentoo (eclasses, EAPI, virtuals...), > participate in the community, and always provide top-quality > contributions, but for some reason never got a mentor? I'd like to point > out that this method would only be for the very few ones and recruiting > through mentoring would still be the desired method. > Recruiting through > recruiters would still require the candidate to fill the > ebuild/developer quiz, and they'd have to pass it without a mentor. So > I'll emphasize: Currently only few special ones would qualify. These who would fit here are the people where mentoring takes literally no effort. So someone could be mentor in name - which would also have the advantage that the future developer has someone to talk to if there are any problems or questions. I dont think this actually brings an improvement. -- 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.